这是我参与「第四届青训营 」笔记创作活动的第11天

3. 大数据支撑

HBase针对海量数据场景的设计优化

• 水平扩展能力
• 负载均衡策略
• 故障恢复机制

3.1 HBase在大数据生态的定位

对TB、PB级海量数据支持一致，近实时的读写性能，支持快速的ad-hoc分析查询任务；

支持字典序批量扫描大量数据，支持只读取部分列族的数据，灵活支持不同查询模式，避免读取不必要的数据；

存储大规模任务（例如MapReduce，Spark，Flink）的中间/最终计算结果；

平滑快速的水平扩展能力，能够敏捷应对大数据场景高速增长的数据体量和大规模的并发访问；

精细化的资源成本控制，计算层和存储层分别按需扩展，避免资源浪费。

3.2 水平扩展能力

• 增加RegionServer实例，分配部分region到新实例
• 扩展过程平滑，无需搬迁实际数据
• 可用性影响时间很短，用户基本无感知

3.3 Region热点切分

• 当某个region数据量过多，切分成两个独立的字region分摊负载
• RegionServer在特定时机（flush、compaction）检查region是否应该切分，计算切分点并RPC上报HMaster，由AssignmentManager负责执行RegionStateTransition。
• 不搬迁实际数据，切分产生的新region数据目录下生成一个以原region文件信息命名的文件，内容是切分点对应的rowkey，以及标识新region是上/下半部分的数据。

3.3.1 切分点选取

HBase原生提供的多种切分策略使用相同的切分点选择策略

目标：优先把最大的数据文件均匀切分

切分点选择步骤：

• 1.找到该表中哪个region的数据大小最大
• 2.找到该region内哪个column family的数据大小最大
• 3.找到column family内哪个HFile的数据大小最大
• 4.找到HFile里处于最中间位置的Data Block
• 5.用这个Data Block的第一条KeyValue的Rowkey作为切分点

3.3.2 切分过程

所有column family都按照统一的切分数据

目的是优先均分最大的文件，不保证所有column family的所有文件都被均分

每个新region分别负责region的上/下半部分rowkey区间的数据。

3.3.3 流程数据

AssignmentManager检查cluster、table、region的状态后，创建SpillTableRegionProdure通过状态机实现执行切分过程。

3.4 Region碎片整合

当某型region数据量过小、碎片化，合并相邻region整合优化数据分布

AssignmentManager创建MergeTableRegionsProdure执行整合操作

不搬迁实际数据，通过reference file定位原region的文件，直到下次compaction时实际处理数据

3.5 负载均衡

定期巡检各RegionServer上的region数量，保持region的数量均匀分布在各个RegionServer上。

3.6 故障恢复机制-HMaster

HMaster通过多实例基于Zookeeper选主实现高可用性。

• 所有实例尝试向Zookeeper的/hbase/active-master临时节点CAS地写入自身信息
• 写入成功表示成为主实例，失败即为从实例，通过watch监听/hbase/active-master节点的变动
• 主实例不可用时临时节点被删除，此时出发其他从实例重新尝试选主

4 最佳实践

4.1 Rowkey设计策略

场景分类：

1.不需要顺序扫描批量连续rowkey

对原始rowkey做哈希（如MD5）,作为真实rowkey的前缀。建议取适当长度的子串，避免过多占用存储空间。

2.需要顺序扫描批量连续rowkey

首先用groupID/appID/userID前缀避免数据热点，然后加上定义顺序的信息（如时间戳）

3.rowkey长度尽量保持较短，因为会冗余存储到每个keyvalue中

4.2 Column Family设计策略

1.column family数量过多容易影响性能，建议不超过5个

2.需要同时读取的数据尽量放在相同的列族，反之尽量放在不同列族。读取时尽量只读取必须的列族，避免读不必要的列族。

3.列族（以及column qualifier）名称尽量短，因为会冗余存储到每个KeyValue中