ghterRegion A和B准备上线（暂时没有location信息，因为仍没open）。另外如果修改失败，则会进行回滚操作，把之前创建的.split目录删除，然后HRegionServer会终止服务，然后HMaster会负责清理其余的状态。
4、并行打开A，B两个HRegion。创建对应的HStore，读取Reference（Reference文件有专门的Scanner和reader来限制读取对应HFile的范围），从所有HFile里读取最大的MemStoreTS、SequenceId。HRegion成功打开后，就更新hbase:meta表中A和B的location。然后根据每个HFile的MaxSequenceId进行replay WALEdit，就是把内容重新写入HStore的memstore。如果WALEdit的logNum里小于MaxSequenceId则表明已经写入HFile（每条记录对应一个SequenceId），就会跳过。然后会请求一个异步Major compact，从Reference生成真正的HFile（异步Major compact会清理所有的Reference，参考这里）。这个时候，这两个daughterRegion已经可以对外提供读服务。
5、 更新zk节点状态。在zk上之前创建的/hbase/region-in-transition/regionName节点的type改为RS_ZK_REGION_SPLIT，通知HMaster完成split操作。另外要注意，由于zk可能会丢失消息，因此这里需要不断循环节点状态，当节点被HMaster删除当时候才表明HMaster收到通知。
6、释放表的全局读锁
这样，在CompactSplitThread的split操作就完成，在这个时候，两个daughterRegion对外提供读请求，父HRegion的文件仍然存在。等待major compact请求完成之后，两个daughterRegion的Refernece文件就会被删除。HMaster会定期监控hbase:meta表，一旦发现存在parentRegion且daughterRegion已经没有Reference文件，则会删除parentRegion的相关内容。这样就最终完成了整个split的操作。
预Split操作
在实际实践过程中，如果可以根据业务大致确认表的数据规模，则可以使用预Split把表分成指定多个HRegion。这样做可以避免Split过程带来的IO开销，并且在大批量导入数据的时候，可以让集群的多个节点分流写请求，加快导入效率。具体做法如下：
首先是关闭Split操作。从Split的过程可以看到，在判断是否需要split的时候，有两种可选的策略，我们这里采取ConstantSizeRegionSplitPolicy，然后把hbase.hregion.max.filesize设置到一个非常大的值，这样HBase就几乎不会对任何HRegion采取split操作。
然后就是在create表的时候，需要指定多个splitKey范围，如：
?
hbase(main):015:0> create 'test_table', 'f1', SPLITS=> ['a', 'b', 'c']
这样就会创建4个HRegion，rowKey范围分别为[负无穷，a)、[a, b)、[b, c)、[c, 正无穷)。在导入数据的时候，客户端就会根据自己的rowKey插入到对应的范围里。当然也要注意某些热点数据会导致某个HRegion特别大，最好要监控好HRegion的读写请求数（可以从master提供的web页面查看状态）。如果发现某些热点数据，可以利用命令行手动设置这个HRegion的split操作，HBase就会对这个HRegion进行split，保持负载平衡。
?
总结
split操作提供了表自动sharding的功能，但这是以额外的IO消耗为代价的。我们可以根据自己的业务需求进行预split或者手动split等操作。无论是哪种，这些split操作都相对较方便，能够免除维护sharding带来的一系列数据同步问题。