HBase性能优化2

对于Table内RowKey个数的统计，一直是HBase系统面临的一项重要工作，目前有两种执行该操作的方式。

1）使用MapReduce进行。可以借助HTableInputFormat实现对于Rowkey的划分，但是需要占用资源，另外由于使用的Hadoop集群提交作业，经常会遇到不能申请到资源的情况，延迟较大，不适合应用的频繁访问。

2）使用Scan+KeyOnlyFilter的方式进行。可以借助Filter的功能，尽可能实现数据在RegionServer端进行统计，减轻Client端的压力。但是，在大多数情况下，从每一个Region上进行Scan，当Table较大时，会造成非常长的延迟，用户体验下降。

基于此，我们考虑到了Coprocessor这样的新特性。

操作上，HBase-0.92.1提供了
org.apache.hadoop.hbase.coprocessor.AggregateImplementation，我们需要对于某一个Table注册该Coprocessor，具体做法为：

View Code JAVA

      String coprocessClassName = "org.apache.hadoop.hbase.coprocessor.AggregateImplementation";         HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.create());         admin.disableTable(tableName);         HTableDescriptor htd = admin.getTableDescriptor(tableName);         htd.addCoprocessor(coprocessClassName);         admin.modifyTable(tableName, htd);         admin.enableTable(tableName);

然后执行的代码如下：

         Scan s = new Scan();        s.addColumn(Bytes.toBytes("cf1"), Bytes.toBytes("c1"));        AggregationClient ac = new AggregationClient(HBaseConfiguration.create());        try {            return ac.rowCount(tableName, new LongColumnInterpreter(), s);        } catch (Throwable e) {            // TODO Auto-generated catch block           e.printStackTrace();        }        return 0;

为了统计使用Scan增加KeyOnlyFilter和Coprocessor之间的区别，记录了500次操作的时间，性能对比图如下：

从上图中，可以看出，大部分通过Coprocessor获取RowCount个数的延迟，小于1s，而使用Scan的方式，获得RowKeyCount的个数大概在4～5s。(备注，检查的table的Rowkey的个数在3w左右)。

那么究竟是什么原因让Coprocessor在统计Rowkey的个数上，拥有如此明显的优势呢？

这是因为在Table注册了Coprocessor之后，在执行AggregationClient的时候，会将RowCount分散到Table的每一个Region上，Region内RowCount的计算，是通过RPC执行调用接口，由Region对应的RegionServer执行InternalScanner进行的。

因此，性能的提升有两点原因:

1) 分布式统计。将原来客户端按照Rowkey的范围单点进行扫描，然后统计的方式，换成了由所有Region所在RegionServer同时计算的过程。

2）使用了在RegionServer内部执行使用了InternalScanner。这是距离实际存储最近的Scanner接口，存取更加快捷。

From Binospace, post HBase性能优化2—使用Coprocessor进行RowCount统计

文章的脚注信息由WordPress的wp-posturl插件自动生成

4

Tags: Coprocessor, HBase, RowCount, tunning