Hbase特点
1. 高速写入：高速写入，对读取需求比较小。
2.大数据：分布式存储，海量数据搞得定。不用担心无限增长的数据。
3. 可靠：写入的不是内存，是硬盘，高性能
4. 查询简单：不需要复杂查询条件来查询数据的应用，HBase只支持基于rowkey的查询，对于HBase来说，单条记录或者小范围的查询是可以接受的。
Hbase使用场景1：对象存储
我们知道不少的头条类、新闻类的的新闻、网页、图片存储在HBase之中，一些病毒公司的病毒库也是存储在HBase之中。
Hbase使用场景2：时序数据
HBase之上有OpenTSDB模块，可以满足时序类场景的需求。
Hbase使用场景3：用户画像
特别是用户的画像，是一个比较大的稀疏矩阵，蚂蚁的风控就是构建在HBase之上。
Hbase使用场景4：时空数据
主要是轨迹、气象网格之类，滴滴打车的轨迹数据主要存在HBase之中，另外在技术所有大一点的数据量的车联网企业，数据都是存在HBase之中。
Hbase使用场景5：CubeDB OLAP
Kylin一个cube分析工具，底层的数据就是存储在HBase之中，不少客户自己基于离线计算构建cube存储在hbase之中，满足在线报表查询的需求。
Hbase使用场景5：消息/订单
在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在HBase之上。聊天系统的日志存储。Facebook的在线聊天，每天数据量近百亿。哨兵监控系统，云信历史数据，日志归档数据等一系列重要应用底层都由HBase提供服务。
Hbase使用场景6：Feed
典型的应用就是xx朋友圈类似的应用。
使用案例
Mozilla: Moving Socorro to HBase
Facebook: Facebook’s New Real-Time Messaging System: HBase
http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html
Facebook和淘宝的总结：
摘自facebook的相关文档
1 storing large amounts of data（100s of TBs）
存储大量的数据（100s TB级数据）
2 need high write throughput
需要很高的写吞吐量
3 need efficient random access (key lookups) within large data sets
在大规模数据集中进行很好性能的随机访问（按列）
4 need to scale gracefully with data
需要进行优雅的数据扩展
5 for structured and semi-strured data
结构化和半结构化的数据
6 don‘t need full RDFS capabilites（cross row/cross table transactions,joins etc.）
不需要全部的 关系数据库特性，例如交叉列、交叉表，事务，连接等等
来自淘宝的使用场景总结：
1 瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景。
2 数据需要长久保存，且量会持久增长到比较大的场景
3 HBase不适用与有join，多级索引，表关系复杂的数据模型
4 合理设计rowkey，非常重要
5 数据较好是可恢复的
6 生产环境关闭split，region数不要太多。
整理总结：
1大数据量 （100s TB级数据） 且有快速随机访问的需求。
例如淘宝的交易历史记录。数据量巨大无容置疑，面向普通用户的请求必然要即时响应。
2 容量的优雅扩展
大数据的驱使，动态扩展系统容量的必须的。例如：webPage DB。
3 业务场景简单，不需要关系数据库中很多特性（例如交叉列、交叉表，事务，连接等等）
4 优化方面：合理设计rowkey。因为hbase的查询用rowkey是较高效的，也几乎的生产环境可行的方式。所以把你的查询请求转换为查询rowkey的请求吧。
