在 HBase 中，为什么大合并（Major Compaction）会消耗大量的系统资源？在生产环境中应该如何规划...

知识点图片

在 HBase 中，大合并（Major Compaction）是指将一个 Region 下某个 Column Family（列族）内的所有 HFile（StoreFile）合并成一个单一的 HFile 的过程。

这是一个非常重型的操作，在生产环境中如果不加控制地触发，往往会导致严重的性能抖动甚至集群瘫痪。以下是关于为什么它会消耗大量资源，以及如何在生产环境中进行规划和配置的详细解答。

一、为什么大合并会消耗大量的系统资源？

大合并的资源消耗几乎涵盖了服务器的所有核心硬件资源（磁盘、网络、CPU、内存），具体原因如下：

1. 极高的磁盘 I/O（读写放大严重）

全量读写：大合并需要将该列族下的所有 HFile 数据全部从磁盘读入内存，进行合并处理后，再将合并后的全量数据重新写入磁盘。
数据量巨大：如果一个 Store 有数十 GB 甚至上百 GB 的数据，这意味着要在短时间内产生等量的连续读取和写入操作，极易打满磁盘的 IOPS 和带宽。

2. 惊人的网络带宽消耗（HDFS 副本机制）

HDFS 写入放大：HBase 的数据底层存储在 HDFS 上。当合并后的新 HFile 写入 HDFS 时，为了保证高可用，HDFS 默认会复制 3 个副本。
网络风暴：写一个 100GB 的 HFile，不仅意味着本地节点写入 100GB，还意味着通过网络向其他两个 DataNode 传输 200GB 的数据。整个集群并发进行大合并时，交换机带宽很容易被瞬间打满，导致正常的 RPC 请求（如客户端的读写请求）因网络阻塞而超时。

3. 密集的 CPU 计算（解压、排序、清理）

压缩与解压：HFile 通常会配置压缩算法（如 Snappy、GZ、LZO）。合并时需要将原文件解压，合并后又要重新压缩，这极其消耗 CPU 资源。
数据清洗与比较：在合并过程中，CPU 需要逐条比对数据，丢弃那些被标记为删除（Tombstone）、已过期（TTL 超时）或超出保留版本数（Max Versions）的数据。
归并排序：虽然原 HFile 是有序的，但多个文件合并时需要进行多路归并排序。

4. 内存及缓存污染

虽然 Compaction 过程本身不直接使用 BlockCache，但大量的 HDFS 读写会占用大量的系统 Page Cache，可能导致其他重要数据的缓存被置换出去，间接影响后续的读性能。

二、在生产环境中应该如何规划和配置大合并？

鉴于大合并的破坏力，生产环境的核心原则是：绝对不能让它在业务高峰期不可控地自动发生。应该将其变为一个可控的、计划性的、低峰期执行的运维操作。

1. 关闭自动大合并（最重要的一步）

HBase 默认每 7 天（加上一定的随机抖动防止雪崩）自动执行一次大合并。在生产环境中，必须将其关闭。

配置参数：
在 hbase-site.xml 中设置：

xml

<property>
    <name>hbase.hregion.majorcompaction</name>
    <value>0</value> <!-- 设置为0表示禁用自动大合并 -->
</property>

2. 在业务低峰期通过脚本手动/定时触发

关闭自动合并后，不能永远不合并（会导致 HFile 过多，读性能下降，且删除的数据无法真正回收空间）。

最佳实践：编写 Shell 脚本或使用任务调度系统（如 Airflow、DolphinScheduler、Crontab），在业务低峰期（如凌晨 2:00 - 5:00、周末）执行。
执行方式：
不要直接使用 major_compact 压缩整个集群，而是按表、甚至按 Region 逐个触发，控制并发度。
bash
```
# HBase Shell 中按表触发
major_compact 'my_table'
# 或者通过脚本按 Region 触发以分散压力
```

3. 限制 Compaction 的资源消耗（限流）

HBase 提供了针对 Compaction 的限流机制，防止合并过程吃光 RegionServer 的资源。

限制吞吐量：开启 PressureAwareCompactionThroughputController（吞吐量控制器）。

xml

<property>
    <name>hbase.regionserver.throughput.controller</name>
    <value>org.apache.hadoop.hbase.regionserver.throttle.PressureAwareCompactionThroughputController</value>
</property>
<property>
    <name>hbase.hstore.compaction.throughput.lower.bound</name>
    <value>10485760</value> <!-- 低峰期最小吞吐量限制 10MB/s -->
</property>
<property>
    <name>hbase.hstore.compaction.throughput.higher.bound</name>
    <value>20971520</value> <!-- 高峰期最大吞吐量限制 20MB/s -->
</property>

配置线程池：HBase 将 Compaction 线程池分为 large 和 small。大文件合并进入 large 池。可以适当控制 large 池的大小。

xml

<property>
    <name>hbase.regionserver.thread.compaction.large</name>
    <value>1</value> <!-- 建议设为 1 或 2，防止大合并并发过高 -->
</property>

4. 根据业务场景选择合适的 Compaction 策略

并非所有表都适合默认的合并策略。如果你的表是时序数据（日志、监控数据），特点是只追加、且通常只查最近的数据，强烈建议更改合并策略：

Date Tiered Compaction Policy (DTCP)：基于时间分层的压缩策略。它将相邻时间段的 HFile 合并，而不会将非常旧的数据和新数据混在一起合并。这大大减少了时序数据大合并时的 I/O 放大。
bash
```
# 在建表或修改表时设置
alter 'my_table', {NAME => 'cf', COMPACTION_POLICY => 'FIFO' 或 'DateTieredCompactionPolicy'}
```

5. 优化建表与日常设计，延缓大合并的需求

合理设置 TTL（Time To Live）：如果数据生命周期明确，设置 TTL。过期数据会在小合并（Minor Compaction）或大合并时自动删除。
预先分区（Pre-splitting）：防止数据写入集中在少数 Region 导致频繁 Split 和 Compaction。
控制列族数量：HBase 建议表的列族数量不要超过 2-3 个。因为同一个 Region 下的一个列族触发 flush，其他列族也会被迫 flush，产生大量小文件，从而加剧 Compaction 的频率。

6. 监控与告警

大合并进行时，系统处于高风险期。必须监控以下指标（通过 JMX 或 Grafana）：

compactionQueueLength：等待压缩的队列长度，如果持续堆积说明 IO 瓶颈。
网络出入带宽：观察 HDFS 的 replication 是否导致网络饱和。
RPC 延迟（Read/Write Latency）：监控合并对在线业务的影响。

总结

大合并本质上是用短时间的极高资源消耗换取长期的读取性能提升和存储空间释放。在生产环境中，变被动为主动（关闭自动、定时手动、控制并发、限制速度）是管理大合并的黄金法则。

右滑查看面试常问

播面