Hbase compaction 源码分析二：详细 compaction 过程
原创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的读写性能均有一定影响，有关对性能影响以及相关调优可参考：
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。