实时系统HBase读写优化--大量写入无障碍

在使用hbase过程中发现在写入hbase的数据量很大时，经常发生写不进去的情况。而我们基于hbase的应用是对实时性要求很高的，一旦hbase不能读写则会大大影响系统的使用。下面将记录hbase写优化的过程。

1.禁止Major Compaction

在hbase进行Major Compaction时，该region将合并所有的storefile，因此整个region都不可读，所有对此region的查询都会block。HBase默认一天左右执行一次Major Compaction。我们将Major Compaction禁掉并用Cron脚本每天在系统空闲时对所有表执行major compaction。

Major Compaction的配置：

<property>
<name>hbase.hregion.majorcompaction</name>
<value>0</value>
</property>

默认是1天，每个region会在创建时以当前时间初始化regionMajorCompactionTime，并将下一次的major compaction时间设为1+-0.2天。配置中将此值设为0禁止major compaction。

major_compaction的脚本：取出所有table，一一执行major_compact：

TMP_FILE=tmp_tables
TABLES_FILE=tables.txt

echo "list" | hbase shell > tmp_tables
sleep 2
sed '1,6d' $TMP_FILE | tac | sed '1,2d' | tac > $TABLES_FILE
sleep 2

for table in $(cat $TABLES_FILE); do
        echo "major_compact '$table'" | hbase shell
        sleep 10
done
2.禁掉split

hbase通过split region实现水平的sharding，但在split的过程中旧的region会下线，新region还会做compaction，中间有一段时间大量的数据不能被读写，这对于我们这种online系统是不能忍受的。我们同样禁掉自动的split，而在晚上系统空闲时执行我们的splittool手动的split。

禁止split的配置：

<property>
<name>hbase.hregion.max.filesize</name>
<value>536870912000</value>
</property>

配置项的含义是当region的大小大于设定值后hbase就会开始split，我们将此值设为500G，我们认为在白天系统繁忙时一个region不会超过此大小，在晚上时运行splittool将region分割开。

splittool的逻辑比较简单。遍历所有region的信息，如果region大小大于某值（比如1G）则split该region，这样为一轮split，如果一轮后没有大于某值的region则结束，如果还有大于某个值的region则继续新一轮split，直到没有region大于某个阈值为止。这里提一下判断split完成的方法：通过检查hdfs上旧region的文件夹是否被清除来判断split是否结束。

3.设置blockingStoreFiles

这个参数的重要性是在我们的性能测试中发现的。我们禁掉major_compaction和split后理论上写入应该无障碍了，但在测试中发现写入单个region速度大于10M/s时还是会出现长时间无法写入的情况。通过查看log，我们发现了这行log“Waited 90314ms on a compaction to clean up 'too many store  files'”，通过查看代码发现原来是blockingStoreFiles这个参数在作怪。

在flushRegion时会检测当前store中hfile的数量是否大于此值，如果大于则会block数据的写入，等待其他线程将hfile compact掉。这样，如果写入速度超过compact的速度，hbase就会阻止该region的数据写入。

private boolean flushRegion(final FlushRegionEntry fqe) {
    HRegion region = fqe.region;
    if (!fqe.region.getRegionInfo().isMetaRegion() &&
        isTooManyStoreFiles(region)) {
      if (fqe.isMaximumWait(this.blockingWaitTime)) {
        LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) +
          "ms on a compaction to clean up 'too many store files'; waited " +
          "long enough... proceeding with flush of " +
          region.getRegionNameAsString());
      }

默认值为7

this.blockingStoreFilesNumber =
      conf.getInt("hbase.hstore.blockingStoreFiles", 7);
    if (this.blockingStoreFilesNumber == -1) {
      this.blockingStoreFilesNumber = 1 +
        conf.getInt("hbase.hstore.compactionThreshold", 3);
    }

我们将此值设为很大的值，使得此问题不会block我们的写入。

<property>
<name>hbase.hstore.blockingStoreFiles</name>
<value>2100000000</value>
</property>