1、Compaction核心作用
1.1、合并小文件，减少文件数，稳定随机读写延迟
1.2、提高数据的本地化率
1.3、清除无效数据，减少数据存储量
2、Compaction分类
2.1、Minor Compaction：选取部分小的，相邻的HFile，将他们合并成一个更大的HFile
2.2、Major Compaction：将一个Store中所有的HFile合并成一个HFile，这个过程还会完全清理三类无意义的数据：
被删除的数据、TTL过期的数据、版本号超过设定版本的数据
2.3、Major Compaction持续事件会比较长，整个过程会消耗大量的系统资源，线上部分数据量较大的业务通常关闭自动触发Major Compaction功能。改为在业务低峰期手动触发（或设置为策略自动在低峰期触发）
2.3、Major Compaction可以把当前Region的本地化率提高到100%.这也是最常用的一种提高本地化率的方法
3、Compaction触发时机
3.1、MemStore Flush:每次执行完Flush后都会触发compact检查，Compaction是以Store为单位进行的，而在flush触发条件下，整个Region都会执行Compact检查，所以一个Region可能会有短时间内多次执行Compaction
3.2、后台线程周期性检查
3.2.1、RS会在后台启动一个线程，定期触发Store是否需要执行Compaction
3.2.2、检查周期：hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier
3.2.3、检查Store文件总数是否大于阈值hbase.hstore.compactionThreshold,大于就触发
3.2.4、文件总数没有达到阈值，检查当前Store中HFile的最早更新事件早于某个值mcTime;mcTime 默认属于∈[7-7*0.2,7+7*0.2]
7为hbase.hregion.majorcompaction
0.2为hbase.hregion.majorcompaction.jitter
可见默认7天左右就会执行一次Major Compaction.
3.2.5、如果向禁用Major Compaction 可以设置 hbase.hregion.majorcompaction 设为0
3.3、手动触发
手动触发原因通常有三：
1）担心Major Compaction影响业务性能，选择在低峰期间手动触发
2）在用在执行完alter之后希望立即生效
3）HBase管理员发现硬盘容量不够，触发删除大量过期数据
4、待合并HFile集合选择策略
理想情况选择带合并的HFile集合承载了大量IO请求但是文件本身很小，这样Compact过程本身不会消耗太多IO,而合并完成之后对读的性能会有显著提升
实际选择思想
4.4.1、减少参与Compaction的文件数，尽量不要合并那些大文件
4.4.2、不合并不需要合并的文件，某些应用场景下的老数据基本不会被查询。因此不合并也不会影响查询性能
4.4.3、小Region更有利于Compac，小Region只会生成少量文件。将这些文件合并不会引起显著的IO放大，小于2G认为是小Region
5、HFile合并流程
1）读取要合并的HFile文件的KeyValue，进行归并排序，之后写到.tmp目录下
2）将临时文件移动到对应Store的数据目录中
3）将Compaction的输入文件路径和输出文件的路径封装成kv写入HLog日志，并打上Compaction标记，并强制执行sync
4）将对应Store数据目录下的Compaction输入文件删除。
6、Compaction限制
Compaction操作可以提升读取性能，但是如果不对Compact执行阶段的读写吞吐进行限制，可能会引起短时间大量系统资源的消耗。使业务发生读写延迟抖动HBase社区提出了一些优化方案
6.1、Limit Compaction Speed：通过感知Compaction的压力情况下自动调节Compaction的吞吐量，在压力大的时候减低吞吐，压力小的时候增加吞吐。
6.2、Compaction BandWidth Limit：设置一次Compaction的最大带宽使用量，如果高于该值就会强制sleep一段时间
6.3、两种方案在HFile过多的情况下都会失效。所有写请求都会被阻塞直到Compaction完成。因为系统认为compact速度完全跟不上写入速度了，这样后续的读取成本会非常高。系统会进入一个恶性循环，compact跑不完，写入也很长时间很慢。
