hbase权威指南： store file合并（compaction）

      hbase为了防止小文件（被刷到磁盘的menstore）过多，以保证保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的 store file，这个过程就称之为compaction。






在hbase中，主要存在两种类型的compaction：minor  compaction和major compaction。

          major compaction 的功能是将所有的store file合并成一个，触发major compaction的可能条件有：major_compact 命令、majorCompact() API、region server自动运行（相关参数：hbase.hregion.majoucompaction 默认为24 小时、hbase.hregion.majorcompaction.jetter 默认值为0.2 防止region server 在同一时间进行major compaction）。hbase.hregion.majorcompaction.jetter参数的作用是：对参数hbase.hregion.majoucompaction 规定的值起到浮动的作用，假如两个参数都为默认值24和0,2，那么major compact最终使用的数值为：19.2~28.8 这个范围。

         minor compaction的运行机制要复杂一些，它由一下几个参数共同决定：

                   hbase.hstore.compaction.min :默认值为 3，表示至少需要三个满足条件的store file时，minor compaction才会启动

                   hbase.hstore.compaction.max 默认值为10，表示一次minor compaction中最多选取10个store file

                   hbase.hstore.compaction.min.size 表示文件大小小于该值的store file 一定会加入到minor compaction的store file中

                   hbase.hstore.compaction.max.size 表示文件大小大于该值的store file 一定会被minor compaction排除

                   hbase.hstore.compaction.ratio 将store file 按照文件年龄排序（older to younger），minor compaction总是从older store file开始选择，如果该文件的size 小于它后面hbase.hstore.compaction.max 个store file size 之和乘以 该ratio，则该store file 也将加入到minor compaction 中。

        如果对minor compaction过程还是不了解，可以去看hbase中关于minor compaction 的源码，或者：http://blog.csdn.net/macyang/article/details/6423078

六、region split

描述： 这个是最最根蒂根基的题目了，当然，hbase大多半的bug就是呈如今这里。当region中的storefile的总大小大于hbase.hregion.max.filesize设置的大小时，这个region就要split，在这个region一分为二的过程中，进行的很是快，因为hbase只须要为两个新的region（在hbase中也成为daughters）建两个reference file罢了.当两个daughters筹办上可以上线的时辰，后台线程会把父region的store files写到两个子region中，同时也会调换掉reference file。最后master会看看到底需不须要做load balance。

七、Compactions

描述 ：当region内的storefile的数量大于hbase.hstore.compaction.min（hbase.hstore.compactionThreshold）时，就会触发minor compaction，而每次minor ompaction所包含的最大文件数由hbase.hstore.compaction.max指定。并且，hbase.hstore.compaction.min.size（凡是设置成和memstore flush的值一样）与hbase.hstore.compaction.max.size（凡是设置为Long.MAX_VALUE）会进一步限制参与compact的文件。与minor compaction不合， major compact会把所有的store里面的文件合成一个大文件，compact的类型在搜检阶段就已经断定好了。以下几种景象会触发搜检compaction，1、shell中的compact或者major_compact恳求 2、memstore flush后 3、恳求响应的api中的majorCompact（ ） 4、后台线程轮询，时候由hbase.server.thread.wakefrequency和hbase.server.thread.wakefrequency，multiplier相乘所得。假如你在shell中恳求了major_compact，或者恳求了api中的majorCompact，都邑强迫履行majorCompact，在其它景象下，rs会根据hbase.hregion.majorcompaction来断定是否应当履行major。

split和compact相对来说错杂点，我找时候再把源码拉出来解析下吧。说到源码，我把源码中compact线程中斗劲首要的一段注释提一下：

归并storefiles，这可能须要一点时候。在这段时候时候中store还是可以或许正常供给办事的，它还是能从storefile中取值，也能从memstore中写入新的storefile。直到新的归并完的storefile已经全部写到硬盘了，本来的storefiles才会删掉。