播面

在 HBase（以及采用类似 LSM-Tree 架构的数据库，如 RocksDB、Cassandra）中，StoreFile Compaction（合并） 是一个至关重要的核心机制。

以下是关于 StoreFile Compaction 的详细解释，以及 Minor Compaction 和 Major Compaction 的区别。

---

一、 什么是 StoreFile 的 Compaction（合并）？

1. 背景与产生原因
HBase 的写入机制是先将数据写入内存（MemStore），当内存达到一定阈值时，会将数据 Flush（刷写）到磁盘上，形成一个 StoreFile（底层对应 HFile）。
随着时间的推移，不断的写入操作会产生大量零散的小 StoreFile。

2. 带来的问题

• 读性能下降（读放大）： 当用户查询数据时，HBase 需要遍历多个 StoreFile 来寻找所需的数据。文件越多，磁盘寻道次数越多，读取速度越慢。
• 磁盘空间浪费（空间放大）： HBase 的更新和删除是追加写（Append）操作。删除一条数据只是写入一个“墓碑标记（Tombstone）”，旧版本的数据依然存在于磁盘上，白白占用空间。

3. Compaction 的定义与目的
Compaction（合并） 就是在后台将多个较小的 StoreFile 按照一定算法合并成较少、较大的 StoreFile 的过程。
其核心目的有两个：

1. 减少文件数量，提升读取性能（减少跨文件的寻道时间）。
2. 清理无效数据，释放磁盘空间（清理被删除的、过期的或超出版本数量限制的数据）。

---

二、 Minor Compaction 和 Major Compaction 的区别

HBase 将 Compaction 分为两种类型：Minor Compaction（轻量级合并） 和 Major Compaction（重量级合并）。它们在范围、资源消耗和对数据的清理彻底程度上有着本质的区别。

1. Minor Compaction（轻量级合并 / 小合并）

• 合并范围： 选取少数几个相邻的、较小的 StoreFile，将它们合并成一个较大的 StoreFile。
• 触发频率： 非常频繁，系统在后台自动且持续地进行。
• 资源消耗： 较小，对系统的 I/O 和 CPU 影响相对较轻。
• 无效数据处理（关键区别）： 通常不会清理被删除的数据（Tombstone标记）、过期数据（TTL）和多余版本数据。
  • 为什么不清理？ 因为 Minor Compaction 只处理了部分文件。如果在这个过程中把“删除标记”清除了，但包含“旧数据”的那个较老的 StoreFile 没有参与这次合并，那么原本被删除的旧数据就会“复活”再次被读出来。

2. Major Compaction（重量级合并 / 大合并）

• 合并范围： 将一个 Region 下某一个 Column Family（列族）中的 所有 StoreFile 合并成 唯一的一个大 StoreFile。
• 触发频率： 较低。默认情况下系统会定期触发（例如每 7 天一次），但由于其破坏性，生产环境中通常会关闭自动触发。
• 资源消耗： 极其巨大。会消耗大量的 CPU、内存、磁盘 I/O 以及网络带宽（由于 HDFS 的多副本机制），极易造成系统的“读写停顿”（Stop-The-World 效应）或性能骤降。
• 无效数据处理（关键区别）： 会彻底清理无效数据。因为所有的 StoreFile 都参与了合并，系统可以绝对确信哪些数据已被删除、哪些数据已过期（TTL）、哪些版本是多余的（超过 MaxVersion），从而物理删除这些数据，真正释放磁盘空间。

---

三、 核心区别对比总结表

💡 生产环境的最佳实践 (Pro-Tip)

在企业级生产环境中，通常会关闭 HBase 的自动 Major Compaction（将 hbase.hregion.majorcompaction 设为 0）。
原因： 如果在白天业务高峰期自动触发了 Major Compaction，巨大的 I/O 占用会导致集群响应变得极慢，甚至拖垮整个集群。
做法： 运维人员通常会写定时脚本，在半夜业务低谷期（如凌晨 2:00），通过 API 或命令行工具手动触发 Major Compaction，以此来兼顾性能和磁盘空间的释放。