的引用文件，一般必须在compact过程中删除。判断是否major compact。满足用户指定的force major，或者太长时间没有进行compact（CompactionChecker的判断2）且候选文件数小于hbase.hstore.compaction.max（默认10），或者有Reference文件，满足上面三个条件之一则是major compact。minor compact继续排除操作。 1、排除在metadata里设置不进行minor compact的HFile（bulkLoad的时候设置） 2、applyCompactionPolicy（后面详述） 3、候选文件数小于hbase.hstore.compaction.min（默认3）则排除全部的候选文件排除候选文件数里超过hbase.hstore.compaction.max（默认10）的部分，如果是major compact则跳过这步，注意从最新的HFile开始进行排除，也就是如果有12个候选文件，则排除掉最后2个最新的HFile。
compact的选择过程中，主要是判断major和minor，然后在配置的最大最小相关限制下进行选择。整个步骤的重点在applyCompactionPolicy，用户可以实现自己的选择策略，HBase主要有两个策略RatioBasedCompactionPolicy和ExploringCompactionPolicy。我们首先假设一个现象：当写请求非常多，导致不断生成HFile，但compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度：在每次执行MemStore flush的操作前，如果HStore的HFile数超过hbase.hstore.blockingStoreFiles （默认7），则会阻塞flush操作hbase.hstore.blockingWaitTime时间，在这段时间内，如果compact操作使得HStore文件数下降到回这个值，则停止阻塞。另外阻塞超过时间后，也会恢复执行flush操作。这样做就可以有效地控制大量写请求的速度，但同时这也是影响写请求速度的主要原因之一。
两者实现如下：
RatioBasedCompactionPolicy。 从最旧文件开始遍历到最新候选文件，找到小于［hbase.hstore.compaction.min.size（默认为memstore的flush大小，128M）和compact文件总大小*ratio 的最大值］的符合条件文件，如果发现不符合则马上停止搜索。ratio是一个可变的比例，可以通过设置高峰期的时间来改变这个比例，在高峰期时ratio为1.2，非高峰期为5，也就是非高峰期允许compact更大的文件（非高峰期可以耗费更大IO）。 目的是尽可能找到小文件进行minor compact。如果判断这个compact操作后文件数仍然过多会阻塞flush操作，则只是简单选择从最老的文件起，候选文件数减去hbase.hstore.compaction.min（默认3）个文件。 ExploringCompactionPolicy。 从最旧文件开始遍历
所有的候选文件，找出符合［compact文件大小 小于 hbase.hstore.compaction.max.size（默认Long最大值）且所有文件的大小都不会超过其它文件大小*ratio］并且效率最高［compact文件数最多或compact大小最小］。ratio是高峰期比例。注意，由于存在限制，因此可能候选文件被排除到为0个，这时如果判断这个compact操作后文件数仍然过多会阻塞flush操作，则会选择hbase.hstore.compaction.min（默认3）个文件起，符合最大（Long最大值）最小compact大小（128MB）的总大小最小的一个子集合。
可见ExploringCompactionPolicy是基于所有候选文件考虑，而RatioBasedCompactionPolicy则是遍历找到就停止。ExploringCompactionPolicy是新版本的策略，旧版本的RatioBasedCompactionPolicy当时只考虑到最大的文件往往是最老的，但对于bulk-loaded的文件等某些情况则会破坏这个规则，RatioBasedCompactionPolicy的算法就不是最优的压缩策略。
完成compact文件选择后，HStore保存这次compact的结果，并返回给CompactSplitThread。
compact的执行
CompactSplitThread接下来会要求HRegion进行compact请求，HRegion会增加compact的计数值表明正在执行的compact操作，这样可以防止compact过程中，HRegion被关闭。然后HRegion调用具体HStore的compact方法执行真正的compact操作。
HStore的compact操作步骤过程，主要就是把这些HFile写成一个HFile。主要过程为：
对所有文件创建对应的scanner，Reference有特殊的scanner。scanner的层次可以参考之前的读请求，最终得到的是一个StoreScanner对象，另外如果是major compact，则会指定在scanner的时候忽略Delete的KeyValue。创建一个临时文件，循环调用scanner的next()方法，把获得的有序的KeyValue写入到临时文件中，然后把这些KeyValue最大的SequenceId写入metadata里。把写到临时文件的compact文件移动到HStore对应的存储目录。把compact的结果写入WAL，RS宕机时就可以依据WAL执行删除旧storeFile用新的compact文件更新HStore内部的数据通知执行读请求中的scanners更新读的HFile，删除旧文件（实际上将其归档），重新计算所有HFile总大小
可以看到在整个compact操作里，只有最后完成compact过程才会对读请求有影响。
完成了HStore的compact操作后，HRegion就会减去之前compact的计数值。返回到CompactSplitThread流程，如果hbase.hstore.blockingStoreFiles（默认7）减去当前的HStore的HFile数。如果<0则表示HRegion将会阻塞后续的memstore flush操作，处于stuck状态则继续调用requestSystemCompaction，否则执行requestSplit查看是否需要split。
至此，就完成了HStore的compact操作。
总结
HBase的compact操作能够通过牺牲当前的IO来获得后来的读性能提高，为了能够减轻compact对系统带来的影响，每次的compact操作都应尽可能选择IO最少，且能提升读性能最大（文件数最多），另外对于major compact，最好应该在集群空闲时间手动触发。