之前有幸在MOOC学院抽中小象学院hadoop体验课。
这是小象学院hadoop2.X概述第八章的笔记
主要介绍HBase，一个分布式数据库的应用案例。
案例概况：
1）时间序列数据库(OpenTSDB)
用HBase储存时间序列数据，每时每刻都在解决，数据库为开源
2）HBase爬虫调度库
垂直搜索爬虫
大规模爬虫（全网爬虫）
这里界定URL爬虫调度
3）HBase文档库
储存文档数据库，偏重于储存
4）银行人民币查询系统
不在博客园上阅读时才会看到的，这篇博文归http://www.cnblogs.com/weibaar 所有
仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示，他站请保留作者信息尊重版权啊
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的评论和正文之间是有关联的）
不在博客园上阅读时才会看到的，这篇博文归http://www.cnblogs.com/weibaar 所有
仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示，他站请保留作者信息尊重版权啊
技术特点
拆分基础数据和动态数据（两个column family）
基础的基本不会变（网页标题啊内容啊创建时间啊）
动态数据可以实时变化（浏览量啊等等）
这里不再是一个server应对不同组，而是多个server应对多个组，以应对不同组的不同数据精细化要求
关联
不在博客园上阅读时才会看到的，这篇博文归http://www.cnblogs.com/weibaar 所有
仅保证在博客园博客上的排版干净利索还有代码块与图片正确显示，他站请保留作者信息尊重版权啊
银行人民币查询系统
特点：
规模极大，且设备分散（如ATM啊点钞机啊等等），采集系统要求要及时且不能有遗漏
可按照人民币冠字号来看，做HASH值或逆转（因为冠字号可能是连续的，有些连号钞票会储存在一起，无法有效切分数据储存，有时候会造成访问热点，因此需要更改冠字号来做rowkey）
要求
及时可靠，能够快速检索及存储，且扩展性要好
因为涉及到多设备采集输入，所以可以用Flume+HBase解决问题
选择HBase的原因是应用非常简单，只是简单查询而已，用HBase就够了
可以参考Cloudera开源的日志收集系统
总结
HBase常常需要与其他系统结合使用
要尽量避免产生访问热点（尤其要避免直接采用时间作为rowkey），要把连续号打散
