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进行数据统计应用中的一些经验总结，其中对于提到问题的解决思路，有过一些尝试，欢迎讨论。