Hbase compaction 源码分析二：详细 compaction 过程

因为major compact很影响hbase的读写性能，所以在不同版本是否major compact其实社区一直都在寻求优化，可根据需要选择不同的实现类RatioBasedCompactionPolicy、ExploringCompactionPolicy和StripeCompactionPolicy，选择了不同的policy(实现类)后，也选择了相应的选择算法从对应store中选择合适的hfile文件进行合并。有关不同Policy的算法性能影响及适合场景可参考文章：

http://hbasefly.com/2016/07/25/hbase-compaction-2/

hbase1.1.3版本使用的实现类是RatioBasedCompactionPolicy:

下面，从chore方法中开始分析 compactor的过程，从chore方法中可以看到minor compact将调用compactSplitThread的requestSystemCompaction方，major compact将调用ompactSplitThread的requestCompaction方法，但这两个方法都会调用CompactSplitThread的requestCompactionInternal方法：

这个是requestCompactionInternal方法原型：

从源码中可以看到，minor和major的区别再于参数CompactionRequest和selectNow。

这个方法很简单：根据请求compact的文件大小以及selectNow判断使用long或者short线程池，然后封装成CompactionRunner放到对应线程池中执行。

placeholder:selectCompaction方法有点长。

doCompaction方法是真正实现方法，在为了完成compact一共分为以下步骤：

1.选择需要Compaction的问题（只有Minor compaction）

2.执行前置listener

3.在region中以store为单位执行compaction

4.是否需要split

5.执行后置listerner

选择文件的方法是利用滑动窗口把最多的小文件进行合并，可参考http://www.cnblogs.com/cenyuhai/p/3746473.html：，本文档将着重分析在region中以store为单位进行compaction：

在保证当前store并没有在compaction后：

1.首先对region的lock锁加上读锁；

2.创建一个status用于监控和跟踪compaction的过程

3.调用doRegionCompactionPrep()方法进行compaction的准备，当前实现为空

4.调用对应store的compact方法

5.status标记成功

在store的compact方法中：

1.检查compactRequest参数

2.通过compaction(DefaultStoreEngine,查看类图)的compaction方法，并返回compaction后的新hfile文件

3.根据hbase.hstore.compaction.complete判断是否做一些compaction的complete工作：

a,把compact生成的文件移动到正确的位置

b.记录WALEdit日志

c.更新HStore相关的数据结构

d.归档旧的文件，关闭reader，重新计算file的大小

执行结束之后会生成临时文件，临时文件的意义在于，在Compaction执行期间，对于原数据访问没有影响。Compaction执行合并操作生成的文件生效过程，需要对Store的写操作加锁，阻塞Store内的更新操作，直到更新Store的storeFiles完成为止。

compact生成新文件的方法很简单，给源文件创建一个StoreScanner，之前说过StoreScanner能从多个Scanner当中每次都取出最小的kv，然后用StoreFile.Append的方法不停地追加写入即可：

PS，compaction对hbase的读写性能均有一定影响，有关对性能影响以及相关调优可参考：

http://hbasefly.com/2016/07/13/hbase-compaction-1/

http://hbasefly.com/2016/07/25/hbase-compaction-2/