Hadoop HBase中split原理学习

在Hbase中split是一个很重要的功能，Hbase是通过把数据分配到一定数量的region来达到负载均衡的。一个table会被分配到一个或多个region中，这些region会被分配到一个或者多个regionServer中。在自动split策略中，当一个region达到一定的大小就会自动split成两个region。table在region中是按照row key来排序的，并且一个row key所对应的行只会存储在一个region中，这一点保证了Hbase的强一致性 。
在一个region中有一个或多个stroe，每个stroe对应一个column families(列族)。一个store中包含一个memstore 和 0 或 多个store files。每个column family 是分开存放和分开访问的。

预split(pre-splitting)
预split就是在建表时，指定拆分的各key，可以指定多份，在HBase shell下执行就像这样：
create 'test_table', 'f1', SPLITS=> ['a', 'b', 'c']
或用外部文件表示，每一行为一个切分点(key)
$ echo -e "a\nb\nc" >/tmp/splits
create 'test_table', 'f1', SPLITSFILE=>'/tmp/splits'

自动split
如果你之前没听过region还要split也不要紧，HBase会在region量达到一定程度时，自己进行 split。什么时候自动进行split呢，这是根据Split Policy来决定的，0.94之前是一个定值 (ConstantSizeRegionSplitPolicy)，之后改成根据一个公式(IncreasingToUpperBoundRegionSplitPolicy) 来计算是否要split

手动split
自动split在前面说了并不如自己管理split靠谱（但这也增加了程序员的运维成本）， 如果你也下定决心要自己动手，那还需要修改配置文件hbase-site.xml中的 hbase.hregion.max.filesize（对，就是前面公式里的第二项）为一个较大的值，比如100G。 因此这里需要说下手动split。只需要在HBase shell中执行一条语句：
split 'regionName', 'splitKey'
更多用法可以在HBase shell中查。另外也可以在HBase的GUI管理界面中直接操作，如果split point不写，相当于只指定了表要被切分，则HBase会自行将表切分一次。经过几次试验， 这类“自动”切分对于少量数据（比如100条）或没有数据的region不会切分， 每个region都会被测试一次要不要切分。

在org.apache.Hadoop.hbase.regionserver包中，可以找到这么几个自带的splitPolicy： ConstantSizeRegionSplitPolicy
IncreasingToUpperBoundRegionSplitPolicy
KeyPrefixRegionSplitPolicy。

ConstantSizeRegionSplitPolicy:按固定长度分割region，固定长度取值优先获取table的”MAX_FILESIZE” 值，若没有设定该属性，则采用在hbase-site.xml中配置的hbase.hregion.max.filesize值，在0.94版本中这个值的缺省值已经被调整为：10 * 1024 * 1024 * 1024L 也就是10G，网上很多关于 hbase.hregion.max.filesize 默认值 1G的文章应该都是基于0.92的hbase的。这个在使用中需要明确具体的hbase版本号。这个策略是0.94版本之前默认使用的，采用该策略后，当table的某一region中的某一store大小超过了预定的最大固定长度时，对该region进行split。splitPoint算法的选择还是依据“数据对半”原则，找到该region的最大store的中间长度的rowkey进行split。

IncreasingToUpperBoundRegionSplitPolicy:按照region数量累增划分region，该策略为Hbase 0.94默认使用的策略，采用该策略分割的region大小是不相等的，每次新region的大小随着region数量的增多而增大。具体增长方法为：

Min (R^2 *  'MEMSTORE_FLUSHSIZE'||'hbase.hregion.memstore.flush.size', “hbase.hregion.max.filesize”);

其中R 为当前这个region所在regionserver中对应此table的region数，MEMSTORE_FLUSHSIZE 为table创建时指定大小，若table指定了此属性则忽略下面的hbase.hregion.memstore.flush.size 。

hbase.hregion.memstore.flush.size 为hbase-site中设定大小 默认128M
hbase.hregion.max.filesize 为hbase-site中设定的单个region大小，默认10G

每次region大小是取上述两个size中较小的那个。

假设使用hbase.hregion.memstore.flush.size 128M, hregion.max.filesize为10G， 那么每次region增长情况为：512M,1152M,2G,3,2G,4,6G,6,2G,etc。当region增长到9个时，9*9*128M/1024=10.125G >10G,至此以后region split大小都固定为10G。

KeyPrefixRegionSplitPolicy:指定rowkey前缀位数划分region，通过读取table的prefix_split_key_policy.prefix_length属性，该属性为数字类型，表示前缀长度，
在进行split时，按此长度对splitPoint进行截取。个人理解是rowkey前缀不相等，则划分region。此种策略比较适合固定前缀的rowkey。当table中没有设置prefix_split_key_policy.prefix_length属性，或prefix_split_key_policy.prefix_length属性不为Integer类型时，指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy。

// 更新现有表的split策略  
         HBaseAdmin admin = new HBaseAdmin( conf);  
         HTable hTable = new HTable( conf, ”test” );  
         HTableDescriptor htd = hTable.getTableDescriptor();  
         HTableDescriptor newHtd = new HTableDescriptor(htd);  
         newHtd.setValue(HTableDescriptor.SPLIT_POLICY, KeyPrefixRegionSplitPolicy.class.getName());// 指定策略  
         newHtd.setValue(“prefix_split_key_policy.prefix_length”, ”2″);  
         newHtd.setValue("MEMSTORE_FLUSHSIZE", "5242880"); // 5M  
         admin.disableTable("test");  
         admin.modifyTable(Bytes.toBytes("test"), newHtd);  
         admin.enableTable("test");  

0.94版本之前使用的是ConstantSizeRegionSplitPolicy策略，此策略只是大于一个基本固定的阀值就允许split，而现在的策略则是store大小大于一个变化的阀值就允许split，什么意思呢，举个例子，当hbase相关split的属性都没有配置，采用默认，一张表刚建立，默认情况只有1个region，那么逻辑上是当这个region的store大小超过 1*1*1*flushsize = 128M(没有自己设置flushSize)时 才会允许split，如果达到这个值切分后，会有两个region，其中一个region中的某个store大小大于 2*2*2*flushsize = 512M 时，则允许split，如此计算下去，直到这个大小超过了hbase.hregion.max.filesize+ hbase.hregion.max.filesize*随机小数*hbase.hregion.max.filesize.jitter才允许split，基本也就固定了，如果粗劣的计算可以把这个hbase.hregion.max.filesize的大小作为最后的阀值，默认是10G，也就说当这个阀值变化到10G，这个阀值就基本上不再变化。

这种思想使得阀值达到一个基本固定的值之前先做了几次split，而这几次split的数据量很少，对hbase的影响也没有那么大，而且相当于数据导入量不大的时候就做了一次“预分region”，在一定意义上减少了以后的热点region的发生。