具体分割过程是这样的：
当memstore中的数据大于一定阀值后会被刷新到磁盘上，生成一个storefile文件，刷新操作完成后，触发一个minor compaction合并压缩操作，将属于该region的一些最早生成的storefile文件重写到一个大的storefile，然后删除被合并的文件。
当合并后的storefile文件的size大于配置的 hbase.hregion.max.filesize的值(该值也可以在定义表结构时设置大小，该值就是分割region分区的阀值)时，这个storefile所属的region分区就会自动被水平分割成对等的2个分区；这个split操作会很快被服务器完成：因为分区的时候系统只是简单地为新的分区创建了2个对父region的引用，每个引用只引用原region的一半数据。
HRegion server会在父分区创建2个split目录——每个新分区一个目录，然后原region会下线，也不会响应任何客户端的请求，这些请求路由到对应的新生成region分区并有新region响应。
接着HRegion Server会推过后台的多线程程序在split目录内为新分区创建一写必须的文件结构，包括为新region创建分区目录和对父region的引用文件。这些预备文件结构成功完成后，服务器会将这两个新的region目录移到table目录，同时修改.META.表的表信息，即原region被分割成了2个新的新的子region。从下图所示可以看一下region分割时.META.表是什么样子的：
从上图中我们可以看出，原region被分成了2个新的region，在rowkey = 550的地方平分，SPLIT => true表明region处于split状态，被splitA和splitB两个region引用。
新的region对原region的引用文件中只保存很少的信息：分割region的rowkey和分区对应的结束rowkey和开始的rowkwy,即starkey和endkey。查询新region上的数据时是通过hbase的HalfFileReader类来读取原region上的数据文件，代替原分区响应客户端的请求。
新分割的子region在触发compaction操作的时候，会在后台将原region中的数据文件合重写到新的region的storefile文件中，合并重写完成会自动用新生成的storefile替换原来的引用文件。当没有对已下线的原region的引用后，原分区的相关数据会被彻底删除，最后处于对负载均衡的考虑HMaster会在合适的一个时间点将split region移动到其他HRegion Server。