HBase性能优化2—使用Coprocessor进行RowCount统计
http://www.binospace.com/index.php/make-your-hbase-better-2/
关键词：AggregationClient
?
对于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，具体做法为：
从上图中，可以看出，大部分通过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接口，存取更加快捷。
