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列表中删除
- 将region的writestate的writesEnabled置为false,告诉后台的compact和flush线程不要再工作了
开始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节点