HBase 进阶
概述
掌握 HBase 的基础架构之后，进阶主题围绕"如何把集群用好、调优"展开：Region 的分裂与合并、集群负载均衡、二级索引的实现方案、Phoenix SQL 接入层，以及日常运维与性能调优手段。
一、Region 分裂与合并
1.1 分裂（Split）
当单个 Region 数据量超过阈值，RegionServer 会将其一分为二，新 Region 分配到其他节点。
| 触发方式 | 说明 |
|---|---|
| 自动分裂 | 按 hbase.hregion.max.filesize（默认 10GB）或 MemStore 大小触发 |
| 预分裂 | 建表时按 RowKey 范围预先切好 Region，规避后续自动分裂的 IO 抖动 |
| 手动分裂 | split 'table', 'rowKey' |
预分裂示例：按 RowKey 前缀 0-9 均匀分 10 个 Region。
create 'order', {NAME => 'info'}, {NUMREGIONS => 10, SPLITALGO => 'UniformSplit'}1.2 分裂流程
1. 达到阈值 → RegionServer 执行 split
2. 原 Region 下线，两个子 Region 上线
3. 子 Region 信息写回 hbase:meta
4. HMaster 感知后，可能把子 Region 迁移到其他 RegionServer 均衡注意：分裂本身是 RegionServer 本地操作，但分裂期间该 Region 短暂不可写，生产上尽量用预分裂。
1.3 合并（Merge）
Region 数量过多或数据稀疏时，可以把相邻 Region 合并：
merge_region 'regionA','regionB'合并减少 Region 数与元数据开销，适合小表或数据删除后稀疏的场景。
二、负载均衡
2.1 均衡策略
HMaster 周期运行 Balancer，按 hbase.balancer.period（默认 5 分钟）评估各 RegionServer 的 Region 数，把 Region 从负载高的节点迁往低的节点。
| 参数 | 默认 | 说明 |
|---|---|---|
hbase.balancer.period | 300000 | 均衡检查周期（毫秒） |
hbase.regions.slop | 0.001 | 允许的负载偏差比例，大于该值才迁移 |
balancer_switch | on | 可手动关闭，避免迁移期间 IO 波动 |
2.2 手动干预
# 查看 Region 分布
hbase hbck
# 手动均衡
balance
# 迁移指定 Region
move 'regionEncodedName', 'serverName'大数据量迁移会影响在线服务，生产环境建议在低峰期执行。
2.3 热点治理
Region 分布不均往往源于 RowKey 设计，配合第 1 周的加盐/预分区方案根治；临时可用 split 拆分热点 Region 缓解。
三、二级索引
HBase 只支持 RowKey 主索引，按非 RowKey 字段查询必须全表 Scan，成本极高。二级索引解决"按业务字段快速定位"的问题。
3.1 索引方案对比
| 方案 | 原理 | 优缺点 |
|---|---|---|
| Phoenix 索引 | 建索引表，写入时同步维护 | 成熟、SQL 透明，索引延迟略高 |
| 华为 HIndex | 同 RegionServer 本地索引 | 性能好但维护成本高、生态弱 |
| 自建索引表 | 业务代码双写主表 + 索引表 | 灵活可控，需要自己保证一致性 |
3.2 自建索引表设计
索引表把"被索引字段"放在 RowKey 前面，Value 存主表 RowKey：
主表 order: RowKey = orderId 列 info: userId, status
索引表 idx_uid: RowKey = userId_orderId（散列前缀加盐）
查询：先扫索引表得到 orderId 集合，再回查主表保证一致性的常用手段：
- 业务层使用同一事务逻辑：先写索引表再写主表，失败则补偿删除。
- 批量场景用异步队列 + 定时对账兜底。
3.3 全局索引 vs 本地索引（Phoenix）
| 类型 | 说明 | 适用 |
|---|---|---|
| 全局索引 | 索引表独立于主表，跨 RegionServer，读写放大 | 读多写少的查询加速 |
| 本地索引 | 索引数据与主表同 Region 存储，本地写入开销小 | 写多、要求低延迟 |
四、Phoenix SQL 层
4.1 定位
Phoenix 把 SQL 编译为 HBase 的 Scan/Put 操作，让团队无需手写 Java API。它内嵌在 RegionServer，通过协处理器执行聚合。
4.2 建表与查询
CREATE TABLE IF NOT EXISTS order (
id VARCHAR NOT NULL PRIMARY KEY,
user_id BIGINT,
amount DECIMAL(10,2),
status VARCHAR
);
-- 走 RowKey 点查，性能最佳
SELECT * FROM order WHERE id = '10001';
-- 二级索引支持后按字段查询
CREATE INDEX idx_uid ON order (user_id);
SELECT * FROM order WHERE user_id = 888;4.3 性能要点
- 点查 / 指定 RowKey 范围 Scan 才是高性能路径，全表聚合仍慢。
- 建索引后 SQL 自动改写为索引表访问，需评估写入放大。
- 大数据量聚合建议下推到 Spark/Flink 离线计算，Phoenix 只做在线小查询。
五、集群运维与调优
5.1 内存模型
RegionServer 堆内存分配：
| 区域 | 默认比例 | 说明 |
|---|---|---|
| BlockCache | 0.4 | 读缓存，缓存热数据块 |
| MemStore | 0.4 | 写缓冲，Flush 阈值 |
| 其他 | 0.2 | 索引、RPC 等 |
读多调大 BlockCache，写多调大 MemStore，二者此消彼长。
5.2 关键参数
| 参数 | 说明 |
|---|---|
hbase.hregion.memstore.flush.size | 单 Region MemStore Flush 阈值 |
hbase.hregion.majorcompaction | Major Compaction 周期，生产常调大到 0 手动触发 |
hbase.regionserver.handler.count | RPC 处理线程数，CPU 核多可调大 |
hbase.client.scanner.caching | Scan 每次 RPC 拉取行数，影响吞吐与内存 |
dfs.replication | HFile 副本数，重要数据 3 副本 |
5.3 日常运维清单
- 容量监控：RegionServer 磁盘、MemStore 使用率、Compaction 队列长度。
- GC 调优：RegionServer 堆大对象多，使用 G1，关注 Mixed GC 停顿。
- Compaction 治理：大集群用 Compaction 限流（
hbase.regionserver.thread.compaction.throttle）避免读写 IO 争抢。 - 快照与备份：
snapshot 'table'支持表级快照，用于数据恢复与迁移。 - 故障演练：定期 Kill RegionServer 验证 WAL 重放与 Region 转移流程。
5.4 常见故障排查
| 现象 | 排查方向 |
|---|---|
| 写入超时 | RegionServer GC 停顿、WAL 磁盘慢、Region 分裂 |
| 读放大严重 | StoreFile 过多，触发 Major Compaction |
| 节点间数据倾斜 | 检查 Region 分布与 RowKey 设计 |
| meta 不一致 | 跑 hbase hbck -details，按提示修复 |
六、与离线数仓的分工
| 场景 | 选择 |
|---|---|
| 高吞吐写入 + 行级点查 | HBase |
| 批量离线分析、复杂 Join | Hive / Spark on HDFS |
| 实时明细查询 | HBase + Phoenix（索引） |
| 海量明细聚合 | 导入 OLAP 引擎（ClickHouse/Doris） |
HBase 定位是"在线随机读写"，离线批量分析与实时大查询交给更合适的引擎，各司其职。