Hbase在数据统计中的应用心得

来源:互联网 发布:水刀编程软件 编辑:程序博客网 时间:2024/04/30 17:03

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

原文出自:http://www.cnblogs.com/panfeng412/archive/2011/11/19/2254921.html

0 0