Hadoop-HBASE案例分析-Hadoop学习笔记

主要介绍HBase，一个分布式数据库的应用案例。

案例概况：

1）时间序列数据库(OpenTSDB) 
用HBase储存时间序列数据，每时每刻都在解决，数据库为开源 
2）HBase爬虫调度库 
垂直搜索爬虫 
大规模爬虫（全网爬虫） 
这里界定URL爬虫调度 
3）HBase文档库 
储存文档数据库，偏重于储存 
4）银行人民币查询系统

HBase在实际问题中的应用：

当数据需要随机读写应用，或者高并发操作（大数据多次操作），或者当数据结构简单，但是量大（非关系型需要大量应用join操作） 
HBase对关系型查询，如join等比较难操作 
关键要设计Rowkey，可加快查询 
常用语言有Java, thrift引用其他语言操作

在rowkey设计里要避免rowkey热点，要充分利用rowkey有序特点，并可以把需求字段组合成rowkey

时间序列数据库

OpenTSDB属于分布式、可伸缩的时间序列数据库 
可以在秒级数据进行采集，并支持永久存储与容量规划，另外可以从不同的metrics进行存储、索引 
普通mysql容量不够，维度支持不够 
该数据库的经验（应该会有遗漏。。） 
1）更多的列，更多的数据，扫描更快（在列上扫描比行上扫描快） 
2）要让每一行的数据相对独立。把行按照一定的规律进行切分（譬如认为10秒是一行数据，时间戳） 
3）要在每一个KeyValue里储存更多的数据 
4）不要把同步的储存到server里面（如HTable/HTablePool等），多用asynchbase的护理高并发数据库 
5）key尽量等长 
6）不要在一个Region里储存过多？

储存时间序列的方法

每一行保存一个metric & time 以及值，这样可以按不同维度储存 
把metric id放在时间前面做组合的key，能够更快扫描相应的维度,而且可以节省储存空间（把metrics编号，而不是直接用其名字做metrics） 
还可以把行变宽，使行储存更多数据(+0,+1,+2)，但是这个不会节省任何空间，只是展示上有所变化而已 
但是行不能无限度变宽。

另外，为了防止网络中断错行，建议按照时间戳分行，而不是时间+1、+2、+3这样按列数断行 
有相应的PDF，网上搜就可以了。。

总结

加宽行可以增加扫描速度，组合使用rowkey，但这些并不能节省空间 
只有合并列、缩短column family名字才能一定程度上缩短空间

垂度爬虫调度库

多个组（如图片组新闻组等）同时进行爬虫处理，并储存到调度库里，HBase定期读取即可

特点

爬虫软件需要根据实时性、优先级等存储调度需要爬取的url 
且爬虫需要为不同组维护url列表 
基本上是队列特征，先插入的URL要优先爬取。但是也要有可以自定义优先级的功能。而且由于数据量差异大（图片很大），也要合理分配资源。 
如垂直业务同时调度、站点抓取速度限速处理、还有时间戳调度处理。

调度库

为不同频道储存host特点及host url列表。 
在url里按照hostid与优先级排序 
这里符合之前OpenTSDB的特性，不要直接用名字做rowkey，而是用ID（来自host name表）排序 
这样就可以有间隔的扫描线程来执行URL

总结：

要充分运用rowkey进行有序排序 
要把rowkey融入有用的字段hostid+PID+URLID 
不要直接用字符串作为rowkey，而是编码以后（整数）进行扫描，节省空间（因为每个列都要储存rowkey 
而且整数化以后就规整化了

文档库

文档库与调度库原理比较相似 
文档库，可以存储网页分析以后更加精细化的数据

特点：

数据格式不一样，需要实时读取和写入（还有更新），数据之间存储会有关联（如BLOG的评论和正文之间是有关联的）

技术特点

拆分基础数据和动态数据（两个column family） 
基础的基本不会变（网页标题啊内容啊创建时间啊） 
动态数据可以实时变化（浏览量啊等等） 
这里不再是一个server应对不同组，而是多个server应对多个组，以应对不同组的不同数据精细化要求 
关联

银行人民币查询系统

特点：

规模极大，且设备分散（如ATM啊点钞机啊等等），采集系统要求要及时且不能有遗漏 
可按照人民币冠字号来看，做HASH值或逆转（因为冠字号可能是连续的，有些连号钞票会储存在一起，无法有效切分数据储存，有时候会造成访问热点，因此需要更改冠字号来做rowkey） 
要求 
及时可靠，能够快速检索及存储，且扩展性要好 
因为涉及到多设备采集输入，所以可以用Flume+HBase解决问题 
选择HBase的原因是应用非常简单，只是简单查询而已，用HBase就够了 
可以参考Cloudera开源的日志收集系统

总结

HBase常常需要与其他系统结合使用 
要尽量避免产生访问热点（尤其要避免直接采用时间作为rowkey），要把连续号打散