HBase split policy

HBase Region达到一定的大小之后，将会进行split操作。
而split policy主要如下：
1.采用ConstantSizeRegionSplitPolicy策略，即storefile固定大小策略：
在0.94版本之前ConstantSizeRegionSplitPolicy 是默认和唯一的split策略。当某个storefile（对应一个columnfamily）的大小大于配置值‘hbase.hregion.max.filesize’的时候（默认DEFAULT_MAX_FILE_SIZE = 10 * 1024 * 1024 *1024L=10G）region就会自动分裂:
对应的源代码如下：

storefile固定大小策略

2. 采用IncreasingToUpperBoundRegionSplitPolicy策略，即根据region数来决定：

IncreasingToUpperBoundRegionSplitPolicy

0.94.0（包含）之后，默认采用IncreasingToUpperBoundRegionSplitPolicy策略，当store file的大小大于如下公式得出的值的时候就会split，公式如下：
Min (R^3* "hbase.hregion.memstore.flush.size", "hbase.hregion.max.filesize")
R为同一个table中在同一个region server中region的个数。
例如：
R为同一个table中在同一个regionserver中region的个数，
hbase.hregion.memstore.flush.size默认为128M，如果设置为1G
hbase.hregion.max.filesize默认为10G

• 如果初始时R=1,那么Min(1G,10GB)=1G,也就是说在第一个flush的时候就会触发分裂操作。
• 当R=2的时候Min(2 X 2 X 2 X 1G,10GB)=8G ,当某个store file大小达到8G的时候，就会触发分裂。
• 当R=3的时候Min(3 X 3 X 3 X 1G,10GB)=10G ,当某个store file大小达到10G的时候，就会触发分裂。
• 如此类推，当R大于等于3的时候，则都是10G，所以在这个策略下的效果和ConstantSizeRegionSplitPolicy一样。

对应源代码如下：

IncreasingToUpperBoundRegionSplitPolicy

还有两种用户自定义策略：KeyPrefixRegionSplitPolicy和DelimitedKeyPrefixRegionSplitPolicy，这两种策略是IncreasingToUpperBoundRegionSplitPolicy策略的具体实现。

1.KeyPrefixRegionSplitPolicy策略，即根据rowkey指定长度的前缀来划分region：
即保证相同的前缀的row保存在同一个region中。指定rowkey前缀位数划分region，通过读取 KeyPrefixRegionSplitPolicy.prefix_length 属性，该属性为数字类型，表示前缀长度，在进行split时，按此长度对splitPoint进行截取。此种策略比较适合固定前缀的rowkey。当table中没有设置该属性，指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy。
相关源代码如下：

splitPoint

2.DelimitedKeyPrefixRegionSplitPolicy策略：
保证以分隔符前面的前缀为splitPoint，保证相同RowKey前缀的数据在一个Region中。

splitPoint

对于第三个分割方法，我们可以设置rowkey的前缀长度prefix_split_key_policy.prefix_length，这样在对表进行分割的时候具有相同前缀的行总是被分割到相同的region。
而第四个分割方法保证以分隔符前面的前缀为splitPoint，保证相同RowKey前缀的数据在一个Region中。

参考：
http://blog.csdn.net/jdplus/article/details/47273983
http://blog.csdn.net/maomaosi2009/article/details/47261131
http://www.cnblogs.com/niurougan/p/3976519.html
http://blog.csdn.net/dcswin/article/details/52335293
http://wangneng-168.iteye.com/blog/2067734