Compact的工作原理:
Compact是一个合并操作，从Region的Store中选择HFile文件进行合并，进行合并时，会从这些待合并的数据文件中依次读出KeyValue,再从小到大排序后写入一个新的文件，然后，新生成的文件取代之前已合并的所有文件对外提供服务。
Compact的种类:
之前已经初步了解过了，Compact根据选择的HFile文件的个数可分为Minor Compaction和Major Compaction。
Minor Compaction：选取部分小的，相邻的HFile，将其合并为一个更大的HFile。可以进行局部的compact,占用IO较少，适合较高频率进行。
Major Compaction：将一个Store中的所有的HFile合并成一个HFile,在此过程中会完全清理以下数据:被删除的数据，TTL过期数据，版本号超过设定版本号的数据。费时间较长，占用IO较大，对上层业务有较大影响，不适宜使用频繁,可定期手动执行。
Compact的作用:
compact含有以下作用:
1).合并小文件，减少文件数，稳定随机读延迟。
2).提高数据的本地化率。本地化率越高，在HDFS上访问数据延迟就越小，相反，延迟会比较大。
3).清除无效文件，减少数据存储量。
Compaction的基本流程:
HBase中会有一个独立的线程来处理Compaction。该线程会先选择合适的HFile进行合并，然后挑选对应的线程池处理，最后对这些文件进行具体的合并操作，流程如下:
Compaction常见的时机有如下三种:MemStore Flush,手动触发，后台线程周期性检查。
MemStore Flush：之所以发生Compaction操作，是因为HFile文件越来越多，而MemStore Flush会产生HFile文件。因此每次进行完flush操作之后，都会对Store中的文件数进行判断。通过hbase.hstore.compactionThreadshold参数设置阈值，一旦文件数超过阈值，就会触发Compaction。
后台线程周期性检查:RegionServer会在后台启动一个线程CompactionChecker,定期检查对应的Store是否需要执行Compaction。检查周期为hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier。如果当前Store中HFile的最早更新时间早于设定的mcTime值，就会触发Major Compaction,mcTime的值为[hbase.hregion.majorcompaction-hbase.hregion.majorcompaction.jitter,hbase.hregion.majorcompaction+hbase.hregion.majorcompaction.jitter]。hbase.hregion.majorcompaction默认值为7，hbase.hregion.majorcompaction.jitter。建议禁用Major Compaction，即将参数hbase.hregion.majorcompaction设置为0。
手动触发:手动触发主要是用于执行Major Compaction。手动触发有以下好处:
1).可以选择在业务低峰期手动触发，减少Major Compaction对读写性能的影响。
2).可以在执行alter操作后使操作立刻生效。
3).当硬盘容量不够时可以用来删除过期数据。
在Compaction操作中，选择合适的文件非常重要，这直接影响到Compaction最终效果和对业务的影响程度。
HFile选择流程如下:
1)筛选HFile合并文件，排除不满足条件的文件。包括如下文件:
当前正在执行Compaction的文件以及比这些文件更新的所有文件。
文件大小大于hbase.hstore.compaction.max.size (默认Long.MAX_VALUE),容易导致大量IO操作。
2).判断是否满足Major条件:
用户强制执行执行Major Compaction。
长时间未进行Major Compaction且候选文件数小于hbase.hstore.compaction.max(默认为10)。
Store中含有reference文件，refrence文件是region分裂产生的临时文件，必须在Compaction过程中进行清理。
如果满足Major Compaction条件，则进行Major Compaction操作。
3).选择Minor Compaction策略:
如果不满足Major Compaction条件，则进行Minor Compaction操作，会先选择HFile文件选择策略。含有两种选择策略:
RatioBasedCompactionPolicy：从老到新逐一扫描所有候选文件，满足以下条件便停止扫描。
a.当前文件大小 < 比当前文件新的所有文件大小总和*ratio,ratio为可变值，在高峰期为1.2，非高峰期为5。可通过hbase.offpeak.start.hour和hbase.offpeak.end.hour两个参数设置高峰期时间段。
b.当前所剩候选文件数小于等于hbase.store.compaction.min，默认为3。
然后剩下的为待合并文件，即当前扫描文件以及比他更新的所有文件。
ExploringCompactionPolicy：
该策略与RatioBasedCompactionPolicy类似，不同的是，Ratio在找到一个合适的文件集合后便停止扫描，而Exploring会记录所有的文件集合并在集合中寻找最优解。
HBase中使用专门的类CompactSplitThread来接收Compaction请求和split请求。该类内部根据请求的不同构造了多个线程池，largeCompactions，smallCompaction,splits等。largeCompactions线程用来处理大Compaction，smallCompaction用来处理小Compaction。splits线程池负责处理所有的split请求。largeCompactions线程池与smallCompactions线程池默认都只有一个线程，可以通过hbase.regionserver.thread.compaction.large和hbase.regionserver.thread.compaction.small参数进行配置修改。通过这种方式，可以将请求独立处理，提高系统的处理能力。
选出待合并的HFile文件集合并选出合适的处理线程后，便会进行合并流程，分为四步:
第一步,读取待合并HFile文件的KeyValue,进行归并排序处理，然后写到./tmp目录下的临时文件中。
第二步,将临时文件移动到对应的Store的数据目录下。
第三步,将Compaction的输入文件路径和输出文件路径写入HLog中，并打上Compaction标记，最后强制执行sync。
第四步,删除对应Store数据目录下的Compaction输入文件。
对于文件集合最优解而言，是在满足合并策略的情况下，当待合并文件数相同的时候，文件大小选择更小的，或者是在文件大小相同的时候，选择合并文件数更多的，在最优解的情景下产生的IO消耗更小。
这里的大Compaction与小Compaction如何理解呢？与Major Compaction和Minor又有何联系呢?大与小的界限根据HBase的一个hbase.regionServer.thread.compaction.throttle参数来进行判断，如果Compaction合并的总文件大小超过该值，就认为是Compaction。反之，则认为是小Compaction。
上面讲述了HFile文件合并有四步，在这四步中，如果发生异常，HBase怎么处理呢?
情景一:第二步之前异常。此时本次Compaction会被判定失败，数据失效。
情景二:第二步到第三步之间异常。与情景一一样会被判定为失败，数据失效。
情景三:第三步到第四步之间异常。恢复后RegionServer重新打开Region后会查看到标有Compaction的日志，只需要根据HLog删除相应的Compaction输入文件即可。
该篇中，我们初步了解了HBase中的Compaction机制，如何选择文件，如何选择线程池等。当然，这只是初步对Compaction有一个概念，知道最基础的知识点。跟Compaction相关的还有很多繁杂晦涩的知识点等你我去学习。
END
原文作者：DBA修行之路；如有侵权，请联系管理员删除。
