这是我参与「第四届青训营 」笔记创作活动的第10天
什么是 HBase ？
开源的 NoSQL 分布式数据库。参考 Google BigTable 的设计，对稀疏表提供更高的存储空间使用率和读写效率。
采用存储计算分离架构：
- 存储层基于 HDFS 存储数据，提供容错机制和高可靠性
- 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力
提供强一致性语义，在CAP理论(Consistency强一致性， Availability高可用性，Partition Tolerance高分区容错性)中属于CP系统。
HBase 数据模型
HBase以列族（column family）为单位存储数据，以行键（rowkey）索引数据。
- 列族需要在使用前预先创建，列名（column qualifier）不需要预先声明，因此支持半结构化数据模型。
- 支持保留多个版本的数据，(行键 + 列族 + 列名 + 版本号) 定位一个具体的值。
使用场景
- 电商订单数据（抖音电商每日交易订单数据基于 HBase 存储，通过多个列存储订单信息和处理进度，快速查询近期新增/待处理订单列表，同时也可将历史订单数据用于统计、用户行为分析等离线任务）
- 搜索推荐引擎（存储网络爬虫持续不断抓取并处理后的原始网页信息，通过 MapReduce、Flink、Spark 等大数据计算框架分析处理原始数据后产出网页索引集，再存储到 HBase 以提供近实时的随机查询能力，为上层的多个字节跳动应用提供通用的搜索和推荐能力）
- 大数据生态 （天生融入 Hadoop 大数据生态。对多种大数据组件、框架拥有良好的兼容性）
- 广告数据流 （存储广告触达、点击、转化等事件流）
- 用户交互数据 （Facebook 曾使用 HBase 存储用户交互产生的数据，例如聊天、评论、帖子、点赞等数据，并利用 HBase 构建用户内容搜索功能）
- 时序数据引擎 （基于 HBase 构建适用于时序数据的存储引擎，例如日志、监控数据存储。例如 OpenTSDB）
- 图存储引擎 （基于 HBase 设计图结构的数据模型，如节点、边、属性等概念，作为图存储系统的存储引擎。例如 JanusGraph 可以基于 HBase 存储图数据）
HBase 数据模型的缺点
- 每条数据都要冗余存储行列信息
- 不支持二级索引，只能通过 rowkey 索引，查询效率依赖 rowkey 设计
- column family 数量较多时可能引发性能衰退
- 不支持数据类型，一律按照字节数组存储
- 仅支持单行内的原子性操作，无跨行事务保障
HBase架构设计
主要组件
- HMaster：元数据管理，集群调度、保活
- RegionServer：提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
- ThriftServer：提供Thrift API读写的代理层
依赖组件
- ZooKeeper：分布式一致性共识协作管理，例如HMaster选主、任务分发、元数据变更管理等
- HDFS：分布式文件系统，HBase的数据存储底座
HBase对大数据的支撑
-
水平扩展能力
- 增加RegionServer 实例，分配部分region 到新实例。
- 扩展过程平滑，无需搬迁实际数据。
- 可用性影响时间很短，用户基本无感知。
-
Region热点切分(通过热点切分能够很好的缓解数据压力)
- 当某个region 数据量过多，切分成两个独立的子region分摊负载。
- RegionServer在特定时机（flush、compaction)检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition。
- 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。
-
碎片整合
- 当某些region数据量过小、碎片化，合并相邻 region 整合优化数据分布。
- AssignmentManager创建MergeTableRegionsProcedure执行整合操作。
- 不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据。
- *注意:只允许合并相邻region，否则会打破rowkey空间连续且不重合的约定。
-
负载均衡 通过定期巡检各个RegionServer上的Region数量，来保证region的数量均匀分布在各个RegionServer上。
-
HMaster高可用 HMaster通过多实例基于Zookeeper选主实现高可用。
