HBase是基于LSM树存储模型的分布式NoSQL数据库。LSM树对比普遍的B+树来说，能够获得较高随机写性能的同时，也能保持可靠的随机读性能（可参考这里）。在进行读请求的时候，LSM树要把多个子树（类似B+树结构）进行归并查询，对于HBase来说，这些子树就是HFile（还包括内存上的树结构MemStore）。因此归并查询的子树数越少，查询的性能就越高。
在写请求的这篇文章里，已经介绍过对于每个写请求，都必须写入MemStore以及HLog才算完成事务提交。当MemStore超过阀值的时候，就要flush到HDFS上生成一个HFile。因此随着不断写入，HFile的数量将会越来越多，根据前面所述，HFile数量过多会降低读性能。为了避免对读性能的影响，可以对这些HFile进行compact操作，把多个HFile合并成一个HFile。compact操作需要对HBase的数据进行多次的重新读写，因此这个过程会产生大量的IO。可以看到compact操作的本质就是以IO操作换取后续的读性能的提高。
HBase的compact是针对HRegion的HStore进行操作的。compact操作分为major和minor两种，major会把HStore所有的HFile都compact为一个HFile，并同时忽略标记为delete的KeyValue（被删除的KeyValue只有在compact过程中才真正被"删除"），可以想象major会产生大量的IO操作，对HBase的读写性能产生影响。minor则只会选择数个HFile文件compact为一个HFile，minor的过程一般较快，而且IO相对较低。在日常任务时间，都会禁止mjaor操作，只在空闲的时段定时执行。
可以请求compact的地方有很多，包括在open region、MemStore flush等都会判断是否需要进行compact操作（单个HStore的MemStore flush之后，如果触发compact操作，则会对所属HRegion下的所有HStore分别进行compact）。除此之外，HRegionServer.CompactionChecker负责定期10 * 1000s针对所有HRegion的HStore检测是否需要进行compact操作。
CompactionChecker判断是否需要进行compact操作的条件如下：
1、HStore下还没有进行compact的HFile的总数 >= hbase.hstore.compaction.min（默认为3），则需要进行compact。
2、如果1不成立，则判断是否需要执行major compact。主要是查看一下是否太久没有执行compact操作。具体判断过程：
1）获得compact时间间隔。hbase.hregion.majorcompaction（默认7天）为base基准时间，hbase.hregion.majorcompaction.jitter（默认5.0）为jitter，公式base + jitter - Math.round(2 * jitter * randomNum) 计算出一个会每次自动抖动的数值作为major compact的时间间隔。之所以要一个自动抖动，就是避免在HRegionServer重启的时候大量的major compact出现造成大量的IO。
2）所有HFile最老（时间戳最小）的那个HFile的时间间隔大于这个major compact的时间间隔，则执行major compact。另外如果HRegion只有一个HFile，并且这个HFile的所有KeyValue的时间戳都没有超过TTL，则表示无须进行major compact，会跳过这次major compact。
当1或2成立都会分别对CompactSplitThread发送compact请求，不同的是，1会异步选择需要进行compact的HFile，2则会进行同步选择。
CompactSplitThread是HRegionServer内负责专门执行minor compact、major compact、split、merge操作的线程池。其内部对应4个操作有不同的线程池执行对应的请求。把这些耗时较大的操作放到各自的线程池里有助于提高系统整个吞吐量，同时可以避免某个操作阻塞影响其它操作。
对于每个compact请求，CompactionChecker需要区分出major和minor，然后分配到对应的线程池执行。条件是进行compact的文件总大小 > hbase.regionserver.thread.compaction.throttle（默认2*maxFileCompacts*memstoreFlushSize＝2*10*128MB），则为major compact，否则为minor compact。
选择compact的文件操作由对应的HStore进行。CompactionChecker的2会同步选择compact文件，这样就可以马上确定是哪个线程池执行具体的compact操作。但1会异步选择compact进行的HFile时，由于不知道文件总大小，HBase会首先在minor compact的线程池进行compact文件选择操作，选择操作后如果判断为需要进行major compact，则会重新把请求发送到major的线程池进行后续的compact操作。
compact文件的选择首先要判断是major还是minor，如果是major，则整个HStore的所有HFile都被选中，否则就选择部分文件进行minor compact。考虑到compact操作都会耗费大量的IO，因此minor compact操作的目标就是以最少的IO代价换取最大的读性能提高。目前在新版本里，HStore的compact文件选择策略能够充分考虑了整体情况去选择最佳的方案。整个过程如下：
其中选择compact文件过程是主要步骤，具体如下：
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操作。这样做就可以有效地控制大量写请求的速度，但同时这也是影响写请求速度的主要原因之一。
两者实现如下：
可见ExploringCompactionPolicy是基于所有候选文件考虑，而RatioBasedCompactionPolicy则是遍历找到就停止。ExploringCompactionPolicy是新版本的策略，旧版本的RatioBasedCompactionPolicy当时只考虑到最大的文件往往是最老的，但对于bulk-loaded的文件等某些情况则会破坏这个规则，RatioBasedCompactionPolicy的算法就不是最优的压缩策略。
完成compact文件选择后，HStore保存这次compact的结果，并返回给CompactSplitThread。
CompactSplitThread接下来会要求HRegion进行compact请求，HRegion会增加compact的计数值表明正在执行的compact操作，这样可以防止compact过程中，HRegion被关闭。然后HRegion调用具体HStore的compact方法执行真正的compact操作。
HStore的compact操作步骤过程，主要就是把这些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，最好应该在集群空闲时间手动触发。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/pun_c/article/details/47132419
