（转载）Hbase -- Hbase数据统计应用中使用心得

1. 数据统计的需求

互联网上对于数据的统计，一个重要的应用就是对网站站点数据的统计，例如CNZZ站长统计、百度统计、Google Analytics、量子恒道统计等等。

网站站点统计工具无外乎有如下一些功能：

1）网站流量统计：包括PV、UV、IP等指标，这些统计指标能够以趋势图的形式展现出来，如最近一周、最近一个月等。

2）IP来源信息统计：记录各个来源IP下的访问PV数。

3）访问来源分析：记录访客是从哪些途径到达本网站的。

4）搜索引擎及搜索关键词分析：对于各个指定搜索引擎带来访问PV的变化及趋势进行分析；对不一样时段内访客搜索关键词的流量趋势进行统计。

5）访问地区分析：统计不一样时间段内各地区的PV浏览量、UV访客数的变化趋势。

6）最近访客流水：实时显示网站当前的被访问状况，包括访问时间、IP地址、来源网址、访问网址和来源地区等。

从统计的角度来看，这些业务功能的需求能够归纳为：

1）各项统计指标的计算，如PV、UV、IP等，能够归结为的对一条一条数据求SUM、AVG等操做。

2）统计需求愈来愈要求实时性，访问来源随时随地发生，来源途径多样化。对于这类需求，不须要统计计算，而是要通过预处理后快速向用户展现其关心的数据。

3）能够将数据统计分为两部分来理解：一部分是对于实时数据的统计，动态展现站点的访问数据更新状况；另外一部分是对于历史数据的统计，如用于各项报表分析。

2. HBase的实现思路

HBase是一个分布式的存储系统，能够很容易在廉价PC上搭建其大规模存储系统，用于存储海量数据，这使得HBase适合于做为站点数据统计工具的存储系统。

1）对于实时数据的统计，HBase可以提供较低延迟的读写访问，承受高并发的访问请求；而对于历史数据的统计，HBase则能够被视为一个巨大的Key-Value存储系统，用于存储各个网站上历史的访问信息，用于作离线的数据分析与报表生成。

2）对于像PV、UV、IP这样须要求累加计算的操做（求SUM/AVG），因为要对HBase表中相关记录进行扫描求和计算，因此若是被统计站点的数据量很大的话，使用HBase来作可能会保证不了很快的响应速度。也就是说，从前端发出一个查询请求到最终结果的响应，时间会比较长（超过1秒或更长）。对于这个问题，将在第3节进行讨论。

3）对于像站点访客流水信息这样的实时数据展现，则比较适合于使用HBase来作，只要咱们设计了合理的key，那么在根据key取单条访问记录时响应速度会很快。

下面是一个使用HBase做为存储系统的结构示意图：

其中，HBase服务端就是指HBase集群，应用程序分别经过入库端与查询端对HBase进行写操做与读操做。

从HBase应用角度来看，能够分为两个不一样的方向：

1）第一种方向，将HBase视为一个可靠可用的容量巨大的Key-Value存储系统，使用HBase的做用很简单，就是将其做为一个黑匣子来使用，按照以前设计好的表结构来存储具备稀疏结构的数据。基于这种思路，若是HBase没法彻底知足业务的需求，就在应用程序层次作一些设计或者优化工做，以最终知足业务的需求。

2）第二种方向，因为HBase是开源的，因此能够对HBase自己机制进行完善与扩展，最终造成一个可以知足业务须要的稳定可用的HBase版本。

3. 问题的解决思路

针对第2节中提到的在使用HBase进行累加计算的操做（求SUM/AVG）时的问题，下面给出几种解决问题的思路与方法。

基于第一种方向：

1）HBase服务端进行聚合计算，这样应用程序的查询端没必要请求HBase响应大量数据进行传输，而只是在服务端计算后的结果，所以可以知足实时响应的需求。

基于第二种方向：

1）在HBase表设计时，加入一个空列专门用于统计所用，这样能够减小从HBase服务端到查询端的数据传输量。

2）应用程序端计算：

a) 入库端：在HBase表设计时，加入一个专门用于存储PV/UV这样累加结果的表，每次新来一条数据时，首先查询HBase表中上次记录下来的PV/UV数，而后判断是否加1后，再从新写回HBase表中相应key下。经过这种方式，查询端就能够直接经过HBase的一次get操做获得PV/UV。

b) 查询端：在查询端加入PV/UV的缓存，下一次查询请求来的时候，在已缓存PV/UV值的基础上，加上扫描HBase表中新增行的记录数（缓存更新的时间周期足够短的话，新增数会比较小，对HBase的查询响应会很快）。

4. 总结的话

这里是在使用HBase进行数据统计应用中的一些经验总结，其中对于提到问题的解决思路，有过一些尝试，欢迎讨论。