Region切分触发策略

参考：HBase原理 – 所有Region切分的细节都在这里了
HBase中的SplitRegionPolicy实现原理及其源码解读

Region切分触发策略
在最新稳定版（1.2.6）中，HBase已经有多达6种切分触发策略。当然，每种触发策略都有各自的适用场景，用户可以根据业务在表级别选择不同的切分触发策略。常见的切分策略如下图：

1-1.png
1.ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。这是最容易理解但也最容易产生误解的切分策略，从字面意思来看，当region大小大于某个阈值（hbase.hregion.max.filesize）之后就会触发切分，实际上并不是这样，真正实现中这个阈值是对于某个store来说的，即一个region中最大store的大小大于设置阈值之后才会触发切分。另外一个大家比较关心的问题是这里所说的store大小是压缩后的文件总大小还是未压缩文件总大小，实际实现中store大小为压缩后的文件大小（采用压缩的场景）。ConstantSizeRegionSplitPolicy相对来来说最容易想到，但是在生产线上这种切分策略却有相当大的弊端：切分策略对于大表和小表没有明显的区分。阈值（hbase.hregion.max.filesize）设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。
2.IncreasingToUpperBoundRegionSplitPolicy: 0.94版本~2.0版本默认切分策略。这种切分策略微微有些复杂，总体来看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系 ：当前regionserver下region个数的3次方* flush size * 2，当然阈值并不会无限增大，最大值为用户设置的MaxRegionFileSize。
min(单一Region文件大小 , Region增加策略的初使化大小（其可由配置控制参数为hbase.increasing.policy.initial.size指定；如果没有配置该参数，由取值MemStore的缓存刷新值大小的两倍，MemStore缓存刷新值默认其值为128M，即此时取值256M）X 当前Table Region数的3次方)。这种切分策略很好的弥补了ConstantSizeRegionSplitPolicy的短板，能够自适应大表和小表。而且在大集群条件下对于很多大表来说表现很优秀，但并不完美，这种策略下很多小表会在大集群中产生大量小region，分散在整个集群中。而且在发生region迁移时也可能会触发region分裂。

第一次split：1^3 * 256 = 256MB 
第二次split：2^3 * 256 = 2048MB 
第三次split：3^3 * 256 = 6912MB 
第四次split：4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB 
后面每次split的size都是10GB了

之所以对小region的表不太友好，是因为当region大小<参数值or缓存刷新值2倍，则以region大小为基准值缓存值2进行拆分。在小于100个region的情况下，会拆分很多小region出来。
3.SteppingSplitPolicy: 2.0版本默认切分策略。这种切分策略的切分阈值又发生了变化，相比IncreasingToUpperBoundRegionSplitPolicy简单了一些，依然和待分裂region所属表在当前regionserver上的region个数有关系，如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize，如果只有1个Region的情况下，那第1次的拆分就是256M，后续则按配置的拆分文件大小（10G）做为拆分标准。这种切分策略对于大集群中的大表、小表会比IncreasingToUpperBoundRegionSplitPolicy更加友好，小表不会再产生大量的小region，而是适可而止。