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是一个分布式的存储系统,能够非常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版本号。
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进行数据统计应用中的一些经验总结。当中对于提到问题的解决思路。有过一些尝试,欢迎讨论。
从最初的:http://www.cnblogs.com/panfeng412/archive/2011/11/19/2254921.html