HBase 高并发写入场景下的性能优化实战
项目背景
Datastream 系统长期依赖 HBase 进行日志分流，日均数据量高达 80 亿条，存储规模约 10TB。对于这种海量数据、高写入要求且无复杂查询需求的日志系统，HBase 是理想的数据存储平台。
HBase 作为分布式系统，并发写入能力极强，但架构复杂，模块众多，运行中容易出现各类问题。在接手该集群后，我们发现虽然 HBase 本身经过 Facebook、淘宝等大厂验证，但在实际运维中仍暴露出不稳定的迹象。我们的目标就是找出这些不稳定因素，消除隐患。
集群现状
接手时，我们运维着多个 HBase 集群，这里主要介绍问题最突出的那个集群的调优情况：
| 名称 | 数量 | 备注 |
|---|---|---|
| 服务器数量 | 17 | 配置不同，HBase、HDFS 均部署在这些机器上 |
| 表数量 | 30+ | 仅部分表数据量大，其余基本无数据 |
| Region 数量 | 600+ | 大表划分的 Region 较多 |
| 请求量 | 50000+ | 服务器请求分布极其不均匀 |
应用端反馈经常间歇性出现写入缓慢，导致数据堆积。当时团队对 HBase 内部原理了解尚浅，初期排查耗时较长，往往需要深夜才能暂时稳住线上问题。随着摸索深入，我们逐渐掌握了使用限制与潜在坑点，并总结出几个关键改进点。
核心优化点
1. Rowkey 设计问题
现象 打开 HBase Web 监控界面，发现各 RegionServer 的请求负载差异巨大。部分 Region 请求量为 0，而部分则高达百万级，这是典型的热点问题。
原因 Rowkey 设计不合理是导致热点的主因。例如使用时间戳生成 Rowkey，由于时间连续，访问请求会集中在特定时间段内的几个 RegionServer 上。
解决 修改应用端的 Rowkey 规则，引入 hash 或 md5 前缀，使数据随机均匀分布。调整后，请求分布显著趋于平衡。
建议 设计 Rowkey 时，务必保证每段时间内的访问均匀。尽量以 hash 或 md5 开头组织 Rowkey，避免顺序递增导致的倾斜。
2. Region 重分布
现象 集群扩展过程中，新加入的机器配置通常优于旧机器，但分配到的 Region 却很少，导致资源利用不均，性能受损。
原因 资源分配不均导致部分机器压力大，部分负载低。同时部分 Region 过大过热，请求过于集中。
解决 手动迁移部分老 RegionServer 上的 Region 到新机器，并通过 Split 切分大 Region，将热点 Region 均匀分布到各个节点。对比调整前后，Region 总数增加，整体性能大幅提升。
建议 不要简单开启自动 Balance。HBase 的自动 Balance 仅依据 Region 数量，可能导致同张表的 Region 被集中迁移到同一台机器，失去分布式意义。新增机器后，建议手工调整，确保表的 Region 平均分配。此外，新机器配置最好与旧机器一致，否则无法充分利用资源。注意，Region 切分会触发 Major Compact，带来较大 I/O，请务必在业务低峰期进行。
3. HDFS 写入超时
现象
HBase 写入缓慢，日志中出现 responseTooSlow 警告，且伴有 HDFS 创建 block 异常。
WARN org.apache.hadoop.ipc.HBaseServer- (responseTooSlow): {"processingtimems":36096, "call":"multi...", ...}
INFO org.apache.hadoop.hdfs.DFSClient - Exception in createBlockOutputStream...
