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

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

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

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

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

6）近期訪客流水：实时显示站点当前的被訪问情况，包含訪问时间、IP地址、来源网址、訪问网址和来源地区等。

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

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

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

3）能够将数据统计分为两部分来理解：一部分是对于实时数据的统计，动态展示网站的訪问数据更新情况。还有一部分是对于历史数据的统计，如用于各项报表分析。

Hbase是一个分布式的存储系统，能够非常easy在便宜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的作用非常easy，就是将其作为一个黑匣子来使用，依照之前设计好的表结构来存储具有稀疏结构的数据。

基于这样的思路，假设Hbase无法全然满足业务的需求，就在应用程序层次做一些设计或者优化工作，以终于满足业务的需求。

2）另外一种方向，因为Hbase是开源的。所以可以对Hbase本身机制进行完好与扩展，终于形成一个可以满足业务须要的稳定可用的Hbase版本号。

针对第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的查询响应会非常快）。

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