本文主要是从HBase应用程序设计与开发的角度,总结几种经常使用的性能优化方法。有关HBase系统配置级别的优化,可参考:淘宝Ken Wu同窗的博客。html
下面是本文总结的第四部份内容:数据计算相关的优化方法。前端
Coprocessor运行于HBase RegionServer服务端,各个Regions保持对与其相关的coprocessor实现类的引用,coprocessor类能够经过RegionServer上classpath中的本地jar或HDFS的classloader进行加载。apache
目前,已提供有几种coprocessor:api
Coprocessor:提供对于region管理的钩子,例如region的open/close/split/flush/compact等;性能优化
RegionObserver:提供用于从客户端监控表相关操做的钩子,例如表的get/put/scan/delete等;函数
Endpoint:提供能够在region上执行任意函数的命令触发器。一个使用例子是RegionServer端的列聚合,这里有代码示例。oop
以上只是有关coprocessor的一些基本介绍,本人没有对其实际使用的经验,对它的可用性和性能数据不得而知。感兴趣的同窗能够尝试一下,欢迎讨论。性能
HBase自己能够看做是一个能够水平扩展的Key-Value存储系统,可是其自己的计算能力有限(Coprocessor能够提供必定的服务端计算),所以,使用HBase时,每每须要从写端或者读端进行计算,而后将最终的计算结果返回给调用者。举两个简单的例子:优化
PV计算:经过在HBase写端内存中,累加计数,维护PV值的更新,同时为了作到持久化,按期(如1秒)将PV计算结果同步到HBase中,这样查询端最多会有1秒钟的延迟,能看到秒级延迟的PV结果。spa
分钟PV计算:与上面提到的PV计算方法相结合,每分钟将当前的累计PV值,按照rowkey + minute做为新的rowkey写入HBase中,而后在查询端经过scan获得当天各个分钟之前的累计PV值,而后顺次将先后两分钟的累计PV值相 减,就获得了当前一分钟内的PV值,从而最终也就获得当天各个分钟内的PV值。
对于UV的计算,就是个去重计算的例子。分两种状况:
若是内存能够容纳,那么能够在Hash表中维护全部已经存在的UV标识,每当新来一个标识时,经过快速查找Hash肯定是不是一个新的UV,如果 则UV值加1,不然UV值不变。另外,为了作到持久化或提供给查询接口使用,能够按期(如1秒)将UV计算结果同步到HBase中。
若是内存不能容纳,能够考虑采用Bloom Filter来实现,从而尽量的减小内存的占用状况。除了UV的计算外,判断URL是否存在也是个典型的应用场景。
若是对于响应时间要求比较苛刻的状况(如单次http请求要在毫秒级时间内返回),我的以为读端不宜作过多复杂的计算逻辑,尽可能作到读端功能单一 化:即从HBase RegionServer读到数据(scan或get方式)后,按照数据格式进行简单的拼接,直接返回给前端使用。固然,若是对于响应时间要求通常,或者 业务特色须要,也能够在读端进行一些计算逻辑。
做为一个Key-Value存储系统,HBase并非万能的,它有本身独特的地方。所以,基于它来作应用时,咱们每每须要从多方面进行优化改进 (表设计、读表操做、写表操做、数据计算等),有时甚至还须要从系统级对HBase进行配置调优,更甚至能够对HBase自己进行优化。这属于不一样的层次 范畴。
总之,归纳来说,对系统进行优化时,首先定位到影响你的程序运行性能的瓶颈之处,而后有的放矢进行针对行的优化。若是优化后知足你的指望,那么就能够中止优化;不然继续寻找新的瓶颈之处,开始新的优化,直到知足性能要求。