Hbase 使用场景及案例

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

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的请求吧。

from:https://java-er.com/blog/hbase-where-use/

hbase