HBase Region分裂实现

分裂策略

不同的分裂策略的实现需要继承RegionSplitPolicy，主要实现两个方法：

shouldSplit()表示是否需要分裂
getSplitPoint()得到分裂点rowkey

从 HBase 0.94之后，默认的分裂策略是IncreasingToUpperBoundRegionSplitPolicy

，思想就是当Region的大小超过某个阈值时，即进行分裂。

这个阈值主要由如下几个因素决定:

hbase.hregion.max.filesize
hbase.increasing.policy.initial.size
当前Region所在RegionServer上和当前Region属于同一张表的Region个数

根据以上三个因素算出一个阈值后，如果当前Region有某个Store的大小大于这个阈值，则认为该Region可分裂，这里对于Store还有一个条件就是Store下不能存在reference类型的StoreFile，这种reference类型的StoreFile是一次分裂后产生的，后续会详说。

对于IncreasingToUpperBoundRegionSplitPolicy来说，使用基类中默认的getSplitPoint()函数，即将Region中size最大的Store下最大的StoreFile拿出来，然后根据block index找出StoreFile中间的block，那么这个block的startkey就是split point

分裂实现

在后台flush线程flush完成一个region内部的memstore时，会去检查这个region是否需要分裂，如果需要分裂，会提交一个SplitRequest任务给后台的compactSplitThread线程内部的负责split的线程池，SplitRequest内部会创建一个SplitTransaction来完成split

根据待分裂region和split point生成两个HRegionInfo对象，代表分裂后产生的两个dautghter region
在zk上创建一个ephemeral node，路径是 /hbase/region-in-transition/regionEncodedName，节点内容为了通知master某个region server想split

某个region，两个子region的信息，包括range等，需要通知master原因是防止master对这个

region进行迁移等等
等待master批准region server split
在hdfs上为这个region的split过程创建临时工作目录/hbase/data/namespace/tableName/regionEncodedName/.splits
关闭当前待分裂region
- 将region的writestate的writesEnabled置为false，告诉后台的compact和flush线程不要再工作了
- 如果当前region内的memstore size大于hbase.hregion.preclose.flush.size，默认5MB，那么先做一次pre flush。这里最开始时已经进行了flush region的操作，在flush region完成到现在中间可能还有写操作写入当前region内的各个store的memstore中，由于关闭region期间region不能提供读写服务，并且关闭region期间需要将region中的memstore进行flush，所以为了让region的不能提供读写服务时间变少，这里做一个pre flush，后续再真正关闭region
- 置上region的closing标记，导致region停读写。
- flush当前region的所有memstore，并且将region的所有storefile关闭
- 置上region的closed标记
- 将region从region server的online region列表中删除
开始split 当前region的store file(splitStoreFiles),为region下的每个storefile都创建一个StoreFileSplitter任务，交给线程池处理。StoreFileSplitter任务实际上没有真正的劈开

storefile，生成两个小的storefile，而是生成两个类型为reference的storefile文件，文件名和内容都比较特殊，比如：假设region encoded name为aaaa的region，分裂为两个name为bbbb和cccc的region，aaaa下有一个column family叫做cfA，下面有一个名

为hfileA的storefile，那么三个region的目录结构如下

/hbase/data/namespace/tableName/aaaa/cfA/hfileA

/hbase/data/namespace/tableName/bbbb/.splits/cfA/hfileA.aaaa

/hbase/data/namespace/tableName/cccc/.splits/cfA/hfileA.aaaa

```

从最后的hfile文件名可以看到，子region引用了父亲region的同名的hfile，这两个特殊的文件里没有真实的数据，而是一个索引数据，记着split row是什么，并且自己是split row的前半部分还是后半部分(Reference).

往两个子region的目录中写入.regioninfo文件，并且将临时目录改名，目录结构如下

/hbase/data/namespace/tableName/bbbb/cfA/hfileA.aaaa

/hbase/data/namespace/tableName/cccc/cfA/hfileA.aaaa

```

原子的修改meta table，在meta table里面标记父亲region下线，并且split为两个region，

并且在meta table中加入两个子region对应的项

－打开两个子region，更新meta table，将location记录其中
将两个子region加入region server的online region列表中
请求一个compaction操作，后台的compaction操作最终会清理掉这些reference文件
更新zk上节点的状态，告诉master已经split完成
等待master删除zk节点

参考资料

https://github.com/apache/hbase/tree/0.98