数据库专题

架构视角:什么业务场景用Hbase?

2021-02-20  本文已影响0人  洪文聊架构

要想非常明确什么场景下用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优势。


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

上一篇下一篇

猜你喜欢

热点阅读