要想非常明确什么场景下用Hbase，那么我们来先了解下Hbase的主要核心特性，那么在什么业务场景下用Hbase，就比较清晰了！

Hbase是一种在Hadoop之上的NoSQL的Key/vale数据库，底层依靠HDFS进行数据存储。

一、Hbase核心特性

海量数据存储

面对互联网应用的海量数据，传统关系型数据库比如mysql，一般单表不会超过一千万，并且单表字段数量也一般不会超过100个，否则性能急剧下降。

但基于Hbase的设计理念与存储原理，Hbase单表可以有百亿行、百万列，在横向和纵向两个维度所支持的数据量级都非常巨大，在列上其实并没有数量的限制。

Hbase可支撑PB级数据存储，即支持的记录数达万亿以上。

所以根据业务需求，当表需要非常大时，可考虑选型Hbase。
如果最多只是上亿条记录并且列不是特别大的话，没有必要放入hbase中，ES和mongodb都能轻松搞定。

面向列存储

Hbase的数据在表中是按照列进行存储的（列簇），可动态增加列，这样在只查询少数几个字段的时候，不需要全表扫描，能极大提高查询效率。

存储记录的多个版本

Hbase的每一个列的数据存储有多个版本，比如地理位置列、天气温度列等，可能有多次变更，所以该列可以有多个版本。Hbase会记录数据所有的历史版本，在特定应用场景中非常有用。后面将会具体提到。

列的稀疏性

为空的列并不占用存储空间，表可以设计的非常稀疏。不必像关系型数据库那样需要预先知道所有列名然后再进行null填充。

弹性伸缩/可扩展性

Hbase底层是依赖HDFS进行数据存储与查询的，由于HDFS的高可用性与极强的扩展性，所以Hbase一样具备这样的能力。

当数据量剧增，需要扩充磁盘空间时，只需要动态增加HDFS的datanode节点即可，非常方便。

数据高可靠性

Hbase本身写入高可靠性特性，保证数据写入的时候不会因为集群异常而导致写入数据丢失。内存中没有写入磁盘的数据会记录在相应的日志文件中，集群恢复后会获取日志中的数据，保证数据不丢失。

Hbase底层使用HDFS，本身数据也有多个副本。这种副本机制，保证了在集群节点出现故障后，数据不会丢失。

高性能

Hbase的Region切分、主键索引、缓存机制等特性，使得Hbase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能够到达毫秒级别。

Hbase能够达到准实时查询，在百亿行百万列的情况下，查询速度能达到百毫秒以内；

底层的LSM数据结构和RowKey有序排列等架构上的独特设计，使得Hbase写入性能也非常高，可支持千万级高并发。

HBase 写入速度快是因为数据并不是真的立即落盘，而是先写入内存，随后异步刷入HFile。所以在客户端看来，写入速度很快。

HBase从自身读写性能对比而言，是一种读比写慢的数据库。

以上，初步介绍了Hbase的核心特性，接下来我们看看它适合的业务场景。

二、适合的业务场景

写密集型应用，每天写入量巨大，而相对读数量较小的应用

比如互联网公司的社交软件的历史消息，大型系统的各种日志等。

Facebook用Hbase进行社交信息的存储、查询与分析，主要存储在线消息，每天数据量近百亿，每月数据量超过200T。

基于HBase，Facebook可以很方便地横向扩展服务规模，提供给数百万用户。该系统每天处理数百亿条事件， HBase读写比基本在1:1，吞吐量达到150w QPS。

此外，米聊历史数据，消息push系统等多个重要应用系统都建立在HBase基础之上。

网易的哨兵监控系统，云信历史数据，日志归档数据等一系列重要应用底层都由HBase提供服务。

京东用Hbase存储卖家操作日志，即几十万商家时时刻刻进行的各种操作。以便进行分析，并且可以保证商家可以精确查询自己的各种操作。卖家操作日志的特点是：数据量大、实时性强、增多查少。

此外，互联网公司还需要收集和存储海量用户的操作行为，比如转发、评论和点赞，通过这些行为来分析用户的特征，形成用户画像，精准投放广告，提升广告收入。

Hbase非常适合收集这种海量用户的交互数据（每天数十亿），并已经成功地应用在这种场合，它可以增量捕获第一手点击流和用户交互数据，然后用不同处理方式（MapReduce是其中一种）来处理数据（清理、装饰、使用数据）。在这种公司，你会发现很多HBase案例。

HBase只支持基于rowkey的查询，对于HBase来说，单条记录或者小范围的查询是可以接受的，大范围的查询由于分布式的原因，可能在性能上有点影响。

并且不支持多条件复杂查询，不支持二级索引。

但当你面对每天数十亿数据，数据量接近PB级时，如果也只是通过rowkey去查数据，那么对于上PB级的数据，都非常适合用Hbase来查询，性能也是非常高的。

因此，Hbase适合做海量数据（亿万条记录）的最底层数据源。

海量数据源都存在Hbase中，把可搜索的字段存到ES/Solr中作为二级索引，提供搜索服务，业务系统用时，先从ES中搜索出记录的rowkey，再根据rowkey查Hbase即可。

对性能和可靠性要求非常高的应用

由于HBase本身没有单点故障，可用性非常高。 数据量较大，而且增长量无法预估的应用，HBase支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过HBase横向扩展来满足功能。

需要存储历史记录场景

当业务需求，需要持续记录用户的历史记录信息时，比如你想要存储用户的地址和喜好，这当然可以做成结构化SQL。但是用户把家搬到上海了，那么以前在北京的地址要update覆盖掉吗，我们要计算分析用户的整个人生周期的活动记录和喜好，来推测他的行为，收入，知识层次，信用，道德水准之类的，当然他的相关历史行为是不能被丢弃的。所以hbase可以很好的适应这样的场景！

三、用在生产环境前的注意事项：

HBase从本身原理和特性上保证了其高可用、高可靠性，以及分布式全内存异步的高写入性能，那么最终用在生成环前需要注意以下几个方面？

查询条件：

HBase查询条件简单，只支持基于主键rowkey索引，即只能通过rowkey进行查询，不能像其他数据库一样使用多条件复杂查询，不支持二级索引，因此选型前，需确认是否能满足业务需求。

rowkey设计要求较高

HBase是Key/vale数据库，也只能通过key（即rowkey）来查询数据，rowkey的设计非常重要，一个优秀的rowkey设计，即可以满足查询业务需求，同时也能让数据均衡分布在集群中的节点上。提升读写性能。

不太适合大范围key查询

从HBase的存储原理可知，其根据rowkey字节范围进行分区分文件存储，大范围的数据查询会使查询落到多个不同的RegionServer上，所以大范围的rokey查询，查询效率会比较低下。

Hbase部署相对复杂，运维成本高：

部署Hbase集群之前，首先要部署Hadoop集群，这包括HDFS、Yarn、Mapredue等一系列组件，其次还要部署Zookeeper集群。

在这两块的服务都正常部署启动后，才能部署HBase集群，此外还包括监控运维等服务组件。

这样看，部署Hbase集群，其实就是要部署和运维Hadoop的整个生态，对于初步使用的开发者而言，还是有不小的工作量。

四、总结

HBase已成熟地应用于国内外的很多大公司，总之，HBase 适合用来存储各种类型的大规模的数据，高可用、扩展性好，可无限伸缩，可为用户提供实时的在线查询，同时也支持离线的应用，配合Hadoop平台具备天然的大数据分析优势。但也要注意上面提到的局限性，因此，需要架构人员和研发人员进行综合考量，发挥HBase优势。

喜欢本文的朋友，欢迎关注、转发、评论，让我们一起成为有智慧的架构师！