[Binospace] HBase性能优化2—使用Coprocessor进行RowCount统计

对于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接口,存取更加快捷。

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

猜你喜欢

转载自57832638.iteye.com/blog/2022817