【每日五分钟搞定大数据】系列，HBase第一篇
讲完了Zookeeper， 接下来我们来说下Google三驾马车之一BigTable的开源实现：HBase，要讲得内容如下：
千万级高并发
PB级存储
非结构化存储
动态列，稀疏列
支持二级索引
强一致性，可靠性，扩展性（CP系统，可用性做了一点让步）
场景不需要复杂查询条件来查询数据的应用。
使用rowkey，单条记录或者小范围的查询性能不错，大范围的查询由于分布式的原因，可能在性能上有点影响。
使用HBase的过滤器的话性能比较差。
不需要关联的场景，HBase为NoSQL无法支持join。
可靠性要求高
master支持主备热切。
regionServer宕机，region会分配给在线的机器。
数据持久化在HDFS，默认3份，HDFS保证数据可靠性。
内存的数据若丢失可以通过Wal预写日志恢复。
数据量较大，而且增长量无法预估的应用。
HBase支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过HBase横向扩展来满足功能。
对象存储系统
HBase MOB（Medium Object Storage），中等对象存储是hbase-2.0.0版本引入的新特性，用于解决hbase存储中等文件（0.1m~10m）性能差的问题。这个特性适合将图片、文档、PDF、小视频存储到Hbase中。
OLAP的存储
Kylin的底层用的是HBase的存储，看中的是它的高并发和海量存储能力。kylin构建cube的过程会产生大量的预聚合中间数据，数据膨胀率高，对数据库的存储能力有很高要求。
Phoenix是构建在HBase上的一个SQL引擎，通过phoenix可以直接调用JDBC接口操作Hbase，虽然有upsert操作，但是更多的是用在OLAP场景，缺点是非常不灵活。
时序型数据
openTsDB应用，记录以及展示指标在各个时间点的数值，一般用于监控的场景，是HBase上层的一个应用。
用户画像系统
动态列，稀疏列的特性，
用于描述用户特征的维度数是不定的且可能会动态增长的(比如爱好，性别，住址等)
不是每个特征维度都会有数据
消息/订单系统
强一致性，良好的读性能，至于hbase如何保证强一致性的后面的文章会详细说明。
feed流系统存储
上面的系统我就不一一说了，蹭个热度，拿个比较火的feed流系统说下。说起feed流系统不得不提的是，前几天据说支持八个一线明星同时出轨的挂了....
feed流系统有三个概念，如图
feed：
一个终端发布的一些内容
可以是用户发布的动态消息
可以是广告系统推荐的广告
也可以是系统本身推荐的一些公告
比如你在微博发了条动态，那这条动态就是feed
feeds流；
feeds流就是系统实时推送的根据了一定规则排序的信息流
比如你刷了下微博，在你的首页出现了按时间排好序的一堆新消息，那这就是feed流
feeds订阅；
这个比较简单，就是你通过应用，微博，朋友圈这些，关注了某个人，那就是订阅了Ta的feeds
Feed流系统中需要存储的内容大致可以分为两部分，
账号关系数据（比如关注列表）
Feed消息内容
其实有很多方案实现，但是这篇说的是HBase，那我们就说说如何用HBase实现。
关注列表就不重点讨论了，数据特点是：列数量不定，量大，关系简单，有序，性能要求高，可靠性要求高。互相关注，单向关注这种场景用二级索引很好实现。
Feed消息数据的特点：1.读多写少，举个栗子，看我文章的人里面有多少人是暗中观察的，不评论不点赞自己也不发文章的，这样“暗中观察”的同学占总用户的比例是很大的。
2.数据模型简单，消息时间，消息体，发布人，订阅人，很少会有需要关联的场景
3.高并发，波峰波谷式访问，Feed流系统属于社交类系统，热点来得快去得也快。
4.持久化可靠性存储
每个人发布的内容都是需要永久存储且不能丢失的，存储量会随着时间的推移会越来越大。需要系统有很强的扩展性和可靠性。
5.消息排序，HBase的rowKey按字典序排序正好适用于这个场景。比如rowkey可以设计成这样
<userId><timestamp><feedId>这样获取某个用户发布的消息时就可以指定时间范围来scan，性能不错的同时还能保证时间线正确。
从上面feed数据的特性可以看出，HBase是适合做feed流系统的，实际生产中也确实有feed流应用是用HBase来做的存储，