Hbase Split 解析

HBase Split是hbase根据一定的触发条件和一定的分裂策略将HBase的一个region进行分裂成两个子region并对父region进行清除处理的过程。Region是HBase中一个非常核心的组织单元，所有的region组成了整个HBase集群，如下面的HBase的体系结构所示：

在HBase中，split其实是进行sharding的一种技术手段，通过HBase的split条件和split策略，将region进行合理的split，再通过HBase的balance策略，将分裂的region负载均衡到各个regionserver上，最大化的发挥分布式系统的优点。HBase这种自动的sharding技术比传统的数据库sharding要省事的多，减轻了维护的成本，但是这样也会给HBase带来额外的IO开销，因此在很多系统中如果能很好的预计rowkey的分布和数据增长情况，可以通过预先分区，事先将region分配好，再将HBase的自动分区禁掉。

Region split的大概流程如下：

1.region先更改ZK中该region的状态为SPLITING。
2.Master检测到region状态改变。
3.region会在存储目录下新建.split文件夹用于保存split后的daughter region信息。
4.Parent region关闭数据写入并触发flush操作，保证所有写入Parent region的数据都能持久化。
5.在.split文件夹下新建两个region，称之为daughter A、daughter B。
6.Daughter A、Daughter B拷贝到HBase根目录下，形成两个新的region。
7.Parent region通知修改.META.表后下线，不再提供服务。
8.Daughter A、Daughter B上线，开始向外提供服务。
9.如果开启了balance_switch服务，split后的region将会被重新分布。

上面1 ~ 9就是region split的整个过程，split过程非常快，速度基本会在秒级内，那么在这么快的时间内，region中的数据怎么被重新组织的？其实，split只是简单的把region从逻辑上划分成两个，并没有涉及到底层数据的重组，split完成后，Parent region并没有被销毁，只是被做下线处理，不再对外部提供服务。而新产生的region Daughter A 和 Daughter B，内部的数据只是简单的到Parent region数据的索引，Parent region数据的清理在Daughter A和Daughter B进行major compact以后，发现已经没有到其内部数据的索引后，Parent region才会被真正的清理。

HBase Split触发条件

1 Pre-splitting
当一个table刚被创建的时候，Hbase默认的分配一个region给table。也就是说这个时候，所有的读写请求都会访问到同一个regionServer的同一个region中，这个时候就达不到负载均衡的效果了，集群中的其他regionServer就可能会处于比较空闲的状态。解决这个问题可以用pre-splitting，在创建table的时候就配置好，生成多个region。

在table初始化的时候如果不配置的话，Hbase是不知道如何去split region的，因为Hbase不知道应该那个row key可以作为split的开始点。如果我们可以大概预测到row key的分布，我们可以使用pre-spliting来帮助我们提前split region。不过如果我们预测得不准确的话，还是可能导致某个region过热，被集中访问，不过还好我们还有auto-split。最好的办法就是首先预测split的切分点，做pre-splitting,然后后面让auto-split来处理后面的负载均衡。

Hbase自带了两种pre-split的算法，分别是 HexStringSplit 和 UniformSplit 。如果我们的row key是十六进制的字符串作为前缀的，就比较适合用HexStringSplit，作为pre-split的算法。例如，我们使用HexHash(prefix)作为row key的前缀，其中Hexhash为最终得到十六进制字符串的hash算法。我们也可以用我们自己的split算法。

2 Auto splitting

1.当memstore flush操作后，HRegion写入新的HFile，有可能产生较大的HFile，HBase就会调用CompactSplitThread.requestSplit判断是否需要split操作。

2.HStore刚刚进行完compact操作后有可能产生较大的HFile，当满足HBase的某一分裂策略后就会进行split操作。

HBase默认有三种自动split的策略，ConstantSizeRegionSplitPolicy,IncreasingToUpperBoundRegionSplitPolicy还有 KeyPrefixRegionSplitPolicy。在0.94版本之前ConstantSizeRegionSplitPolicy 是默认和唯一的split策略。当某个store（对应一个column family）的大小大于配置值 ‘hbase.hregion.max.filesize’的时候（默认10G）region就会自动分裂。而0.94版本中，IncreasingToUpperBoundRegionSplitPolicy 是默认的split策略。这个策略中，最小的分裂大小和table的某个region server的region 个数有关，当store file的大小大于如下公式得出的值的时候就会split，公式如下

 Min (R^2 * “hbase.hregion.memstore.flush.size”, “hbase.hregion.max.filesize”)  R为同一个table中在同一个region server中region的个数。

例如:

hbase.hregion.memstore.flush.size 默认值 128MB。

hbase.hregion.max.filesize默认值为10GB 。

  如果初始时R=1,那么Min(128MB,10GB)=128MB,也就是说在第一个flush的时候就会触发分裂操作。

  当R=2的时候Min(2*2*128MB,10GB)=512MB ,当某个store file大小达到512MB的时候，就会触发分裂。

  如此类推，当R=9的时候，store file 达到10GB的时候就会分裂，也就是说当R>=9的时候，store file 达到10GB的时候就会分裂。

split 点都位于region中row key的中间点。KeyPrefixRegionSplitPolicy可以保证相同的前缀的row保存在同一个region中。指定rowkey前缀位数划分region，通过读取 KeyPrefixRegionSplitPolicy.prefix_length 属性，该属性为数字类型，表示前缀长度，在进行split时，按此长度对splitPoint进行截取。此种策略比较适合固定前缀的rowkey。当table中没有设置该属性，指定此策略效果等同与使用IncreasingToUpperBoundRegionSplitPolicy。我们可以通过配置 hbase.regionserver.region.split.policy 来指定split策略，我们也可以写我们自己的split策略。

3 Forced Splits
当HBaseAdmin手动发起split时，也会触发split操作。 、

split策略

1. 采用ConstantSizeRegionSplitPolicy策略，即storefile固定大小策略：

在0.94版本之前ConstantSizeRegionSplitPolicy 是默认和唯一的split策略。当某个storefile（对应一个columnfamily）的大小大于配置值 ‘hbase.hregion.max.filesize’的时候（默认DEFAULT_MAX_FILE_SIZE = 10 * 1024 * 1024 *1024L=10G）region就会自动分裂:

对应的源代码如下：

@Override
  protected void configureForRegion(HRegion region) {
    super.configureForRegion(region);
    Configuration conf = getConf();
    HTableDescriptor desc = region.getTableDesc();
    if (desc != null) {
      this.desiredMaxFileSize = desc.getMaxFileSize();
    }
    if (this.desiredMaxFileSize <= 0) {
      this.desiredMaxFileSize = conf.getLong(HConstants.HREGION_MAX_FILESIZE,
        HConstants.DEFAULT_MAX_FILE_SIZE);
    }
    double jitter = conf.getDouble("hbase.hregion.max.filesize.jitter", 0.25D);
    this.jitterRate = (RANDOM.nextFloat() - 0.5D) * jitter;
    long jitterValue = (long) (this.desiredMaxFileSize * this.jitterRate);