HBase 1.1.2 split 策略

背景：

今天让同事用ycsb做HBase的性能测试，他跟我反馈reigon总是在配置的大小前split(配置的是10G)，于是我就给他说起了hbase的spilt策略：从0.94增加了新的策略，还是在会每次flush的时候会去判断需不需要split，但是判断的策略有了改变，会比较现有文件的大小与改表region个数的平方*memstore大小的关系，如果前者较大也会去做split，巴拉巴拉。但他跟我说region个数的平方*memstore这个不对吧，日志里是memstore二倍的大小，还给我截图为证，无奈，就翻看了1.1.2的代码，发下算法真的变了，对应变成了region个数的三次方*2*memstore。

日志如下：

regionserver.IncreasingToUpperBoundRegionSplitPolicy: ShouldSplit because 0 size=296442912, sizeToCheck=268435456, regionsWithCommonTable=1

从日志中可以看到，每次flush时候都会调用IncreasingToUpperBoundRegionSplitPolicy类中的shouldSplit方法，方法内容如下：

 @Override  protected boolean shouldSplit() {    if (region.shouldForceSplit()) return true;    boolean foundABigStore = false;    // Get count of regions that have the same common table as this.region    int tableRegionsCount = getCountOfCommonTableRegions();    // Get size to check    long sizeToCheck = getSizeToCheck(tableRegionsCount);    for (Store store : region.getStores()) {      // If any of the stores is unable to split (eg they contain reference files)      // then don't split      if ((!store.canSplit())) {        return false;      }      // Mark if any store is big enough      long size = store.getSize();      if (size > sizeToCheck) {        LOG.debug("ShouldSplit because " + store.getColumnFamilyName() +          " size=" + size + ", sizeToCheck=" + sizeToCheck +          ", regionsWithCommonTable=" + tableRegionsCount);        foundABigStore = true;      }    }    return foundABigStore;  }

代码说明：

首先，通过getCountOfCommonTableRegions()方法获取目前的region个数tableRegionCount，然后通过getSizeTOCheck(tableRegionCount)方法运算得出一个阈值sizeToCheck,接着在for循环中遍历该reigon下所有的sotre，如果有store不能做split(调用HStore类的canSplit方法，该方法判断store下的hfile是否有被reference的，即region刚拆分，但hfile还处于reference状态，未完成拆分)，直接返回false。如果该store可以做split，则比较store下hfile的大小与sizeToCheck的值，如果大于则标识foundABigStore置为true。

接着看下getSizeTOCheck(tableRegionCount)方法：

  protected long getSizeToCheck(final int tableRegionsCount) {    // safety check for 100 to avoid numerical overflow in extreme cases    return tableRegionsCount == 0 || tableRegionsCount > 100 ? getDesiredMaxFileSize():      Math.min(getDesiredMaxFileSize(),        this.initialSize * tableRegionsCount * tableRegionsCount * tableRegionsCount);  }

代码说明：

如果tableRegionCount的值是0或者大于100，则通过getDesiredMaxFileSize()方法读取配置文件中的hbase.hregion.max.filesize值(即前文说的10G)，否则进行Math.min判断，后面tableRegionCount三次方很容易理解，看看initialSize怎么来的，相关方法内容如下：

@Override  protected void configureForRegion(HRegion region) {    super.configureForRegion(region);    Configuration conf = getConf();    this.initialSize = conf.getLong("hbase.increasing.policy.initial.size", -1);    if (this.initialSize > 0) {      return;    }    HTableDescriptor desc = region.getTableDesc();    if (desc != null) {      this.initialSize = 2*desc.getMemStoreFlushSize();    }    if (this.initialSize <= 0) {      this.initialSize = 2*conf.getLong(HConstants.HREGION_MEMSTORE_FLUSH_SIZE,        HTableDescriptor.DEFAULT_MEMSTORE_FLUSH_SIZE);    }  }

代码说明：

代码逻辑也是非常简单，这里不再赘述。

补充，昨天以为getCountOfCommonTableRegions()的逻辑是获取这张表所有的region，今天测试发现不是这样，回头再看代码，代码内容如下：

  private int getCountOfCommonTableRegions() {    RegionServerServices rss = this.region.getRegionServerServices();    // Can be null in tests    if (rss == null) return 0;    TableName tablename = this.region.getTableDesc().getTableName();    int tableRegionsCount = 0;    try {      List<Region> hri = rss.getOnlineRegions(tablename);      tableRegionsCount = hri == null || hri.isEmpty()? 0: hri.size();    } catch (IOException e) {      LOG.debug("Failed getOnlineRegions " + tablename, e);    }    return tableRegionsCount;  }}

代码说明:

首先获取该region所在的regionserver，然后获取该regionserver上的所有region，而不是该表在整个集群中的region数量。