HBase介绍以及对比MongoDB

HBase全称:Hadoop Database。

HBase是一种高可靠性,高性能,面向列的可扩展分布式存储系统,使用HBase技术在廉价的PC服务器上构建大规模结构化存储集群。 HBase的目标是存储和处理大量数据,特别是仅使用标准硬件配置即可处理包含数千行和列的大量数据,可处理PB级别数据存储,亿级QPS查询。

它适用于实时性要求不高的业务场景,HBase存储Byte数组,该数组不介意数据类型,从而允许动态,灵活的数据模型。

架构解析:

HBase由HMaster和HRegionServer组成,并且遵循主从服务器体系结构。 HBase将逻辑表分为多个数据块HRegion,并将它们存储在HRegionServer中。

HMaster负责管理所有HRegionServer。 它本身不存储任何数据,而仅存储数据到HRegionServer的映射(元数据)。

群集中的所有节点均由Zookeeper协调,并处理HBase操作期间可能遇到的各种问题。 HBase的基本架构如下所示:

客户端:使用HBase的RPC机制与HMaster和HRegionServer通信,提交请求并获得结果。 对于管理操作,客户端使用HMaster执行RPC。 对于数据读取和写入操作,客户端使用HRegionServer执行RPC。

Zookeeper:通过将集群中每个节点的状态信息注册到ZooKeeper,HMaster可以随时感知每个HRegionServer的健康状态,还可以避免HMaster的单点故障。

HMaster:管理所有HRegionServer,告诉他们需要维护哪些HRegion,并监视所有HRegionServer的运行状况。 当新的HRegionServer登录到HMaster时,HMaster告诉它等待数据分配。 当HRegion死亡时,HMaster将其负责的所有HRegion标记为未分配,然后将它们分配给其他HRegionServer。 HMaster没有单点问题。 HBase可以启动多个HMaster。 通过Zookeeper的选举机制,群集中始终有一个HMaster运行,从而提高了群集的可用性。

HRegion:当表的大小超过预设值时,HBase会自动将表划分为不同的区域,每个区域都包含表中所有行的子集。 对于用户来说,每个表都是数据的集合,用主键(RowKey)加以区分。 从物理上讲,一个表分为多个块,每个块都是一个HRegion。 我们使用表名+开始/结束主键来区分每个HRegion。 一个HRegion会将一段连续数据保存在一个表中。 完整的表数据存储在多个HRegions中。

HRegionServer:HBase中的所有数据通常从底层存储在HDFS中。 用户可以通过一系列HRegionServer获得此数据。 通常,群集的一个节点上仅运行一台HRegionServer,并且每个段的HRegion仅由一个HRegionServer维护。 HRegionServer主要负责响应用户I / O请求将数据读取和写入HDFS文件系统。 它是HBase中的核心模块。 HRegionServer在内部管理一系列HRegion对象,每个HRegion对应于逻辑表中的连续数据段。 HRegion由多个HStore组成。 每个HStore对应于逻辑表中一个列族的存储。 可以看出,每个列族都是一个集中式存储单元。 因此,为了提高操作效率,最好将具有共同I / O特性的列放在一个列系列中。

HStore:它是HBase存储的核心,它由MemStore和StoreFiles组成。 MemStore是内存缓冲区。用户写入的数据将首先放入MemStore。当MemStore已满时,Flush将是一个StoreFile(底层实现是HFile)。当StoreFile文件的数量增加到某个阈值时,将触发Compact合并操作,将多个StoreFile合并为一个StoreFile,并在合并过程中执行版本合并和数据删除操作。因此,可以看出,HBase仅添加数据,并且所有更新和删除操作都在后续的Compact进程中执行,因此用户的写入操作可以在其进入内存后立即返回,从而确保HBaseI /哦当StoreFiles Compact时,它将逐渐形成越来越大的StoreFile。当单个StoreFile的大小超过某个阈值时,将触发分割操作。同时,当前的HRegion将被拆分为2个HRegion,并且父HRegion将脱机。 HMaster将这两个子HRegion分配给相应的HRegionServer,以便将原始HRegion的负载压力分流到这两个HRegion。

HLog:每个HRegionServer都有一个HLog对象,该对象是实现预写日志的预写日志类。 每次用户将数据写入MemStore时,它还将数据的副本写入HLog文件。 定期滚动和删除HLog文件,并删除旧文件(已保存到StoreFile的数据)。 当HMaster检测到HRegionServer被Zookeeper意外终止时,HMaster首先处理旧版HLog文件,分割不同HRegion的HLog数据,将它们放入相应的HRegion目录中,然后重新分发无效的HRegion。 在加载HRegion的过程中,这些HRegion的HRegionServer将发现需要处理HLog的历史记录,因此将Replay HLog中的数据传输到MemStore,然后刷新到StoreFiles以完成数据恢复。

HBase基于BigTable,它是稀疏的长期存储(在HDFS上),多维和排序的映射表。 该表的索引是行关键字,列关键字和时间戳。 HBase数据是字符串,没有类型。

HBase读写过程

下图是HRegionServer数据存储关系图。 如上所述,HBase使用MemStore和StoreFile将更新存储到表中。 数据在更新后首先写入HLog和MemStore。 MemStore中的数据已排序。

当MemStore累积到某个阈值时,将创建一个新的MemStore,并将旧的MemStore添加到Flush队列中,并将一个单独的线程刷新到磁盘上以成为StoreFile。 同时,系统将在Zookeeper中记录一个CheckPoint,表明该时间之前的数据更改已保留。 当发生意外系统时,MemStore中的数据可能会丢失。

在这种情况下,HLog用于在CheckPoint之后恢复数据。

StoreFile是只读的,一旦创建便无法修改。 因此,HBase的更新是一项附加操作。 当商店中的StoreFile达到某个阈值时,将执行合并操作,并且将相同密钥的修改合并以形成一个大型StoreFile。 当StoreFile的大小达到某个阈值时,StoreFile被拆分并分为两个StoreFiles。

写操作流程

  • 步骤1:客户端通过Zookeeper的调度向HRegionServer发送写数据请求,并将数据写入HRegion。
  • 步骤2:将数据写入HRegion的MemStore,直到MemStore达到预设阈值。
  • 步骤3:MemStore中的数据被整理到StoreFile中。
  • 步骤4:随着StoreFile文件数量的增加,当StoreFile文件数量增加到特定阈值时,将执行Compact合并操作,并将多个StoreFiles合并到一个StoreFile中,并在版本库中执行版本合并和数据删除。 同时。
  • 步骤5:StoreFiles通过连续的Compact操作逐渐形成越来越大的StoreFile。
  • 步骤6:在单个StoreFile的大小超过某个阈值之后,将触发Split操作,将当前的HRegion拆分为两个新的HRegion。 父HRegion将脱机,新的Split的两个子HRegion将由HMaster分配给相应的HRegionServer,以便可以将原始HRegion的压力分流到这两个HRegion。

读取操作流程

  • 步骤1:客户端访问Zookeeper,找到-ROOT-table,并获得.META。 表信息。
  • 步骤2:从.META中搜索。 表获取目标数据的HRegion信息,找到对应的HRegionServer。
  • 步骤3:获取需要通过HRegionServer查找的数据。
  • 步骤4:HRegionserver的内存分为两部分:MemStore和BlockCache。 MemStore主要用于写入数据,而BlockCache主要用于读取数据。 首先将请求读取到MemStore以检查数据,检查BlockCache检查,然后检查StoreFile,然后将读取结果放入BlockCache。

HBase使用场景

半结构化或非结构化数据:对于没有很好定义或混乱的数据结构字段,很难根据适用于HBase的概念来提取数据。 如果随着业务增长存储更多字段,则需要关闭RDBMS来维护更改表结构,并且HBase支持动态添加。

记录非常稀疏:RDBMS行的多少列是固定的,而空列则浪费存储空间。 HBase为空的列不会存储,这样可以节省空间并提高读取性能。

多版本数据:根据RowKey和列标识符定位的值可以具有任意数量的版本值(时间戳是不同的),因此将HBase用于需要存储更改历史记录的数据非常方便 。

大量数据:当数据量越来越大时,RDBMS数据库将无法承受,并且存在读写分离策略。 通过一个主机,它负责写操作,而多个从机则负责读取操作,服务器成本增加了一倍。 随着压力的增加,船长无法承受压力。 此时,将对库进行划分,并且将几乎不相关的数据分别部署。 某些联接查询无法使用,并且需要使用中间层。 随着数据量的进一步增加,表的记录变得越来越大,查询变得非常慢。

因此,有必要例如通过对ID进行模化将表划分为多个表,以减少单个表的记录数。 经历过这些事情的人都知道如何抛弃这个过程。

HBase很简单,只需将新节点添加到群集,HBase就会自动水平拆分,并且与Hadoop的无缝集成可确保数据可靠性(HDFS)和高性能的海量数据分析(MapReduce)。

HBase Map Reduce

HBase中的Table与Region之间的关系与HDFS中的File与Block之间的关系有些相似。 由于HBase提供了与MapReduce进行交互的API,例如TableInputFormat和TableOutputFormat,因此HBase数据表可以直接用作Hadoop MapReduce的输入和输出,这有利于MapReduce应用程序的开发,并且不需要注意HBase的处理。 系统本身的详细信息。

数据结构分析

HBase使用LSM(Log-Structure Merge)树,传统数据库Innodb使用B+树

LSM Tree特点:

1、侧重写

2、读需要访问多棵树,IO次数比B+树多,波动大

3、写都是顺序IO,随机读是随机IO,顺序读是顺序IO

优点:

1、写性能大幅度提高

2、不受SSD随机写入放大干扰

3、不受空间放大干扰

缺点:

1、读性能有牺牲,IO次数比B+树大

2、需要定期compaction,对整体网络/磁盘IO存在放大

HBase的优点:

1、数据是按列存储的,查询时只访问所涉及的列,大量降低系统I/O,数据类型一致,空值不存储数据,可以高效压缩存储。

2、Key/Value的存储方式,这意味着,即便面临海量数据的增长,也几乎不会导致查询性能下降。

3、列式数据库,相对于于传统的行式数据库而言。当你的单张表字段很多的时候,可以将相同的列(以regin为单位)存在到不同的服务实例上,分散负载压力。

HBase的缺点:

1、原生不支持二级索引,只能通过主键访问。社区实现的二级索引功能支持和数据更新有时延,导致头疼的一致性问题

2、宽表模型概念拗考,难于理解并且要求实现建模,不够灵活

3、支持程序语言种类少(Java,Thrift, RESTful API),没SQL只能使用API

4、集群结构复杂,有8种不同类型节点

5、数据类型低级,只支持比特流,开发很不友好

6、无一致性快照功能

7、需要定时compact,对持续读写场景影响很大

8、Hbase不支持表的关联操作,因此数据分析是HBase的弱项。常见的 group by或order by只能通过编写MapReduce来实现

综上所述:

HBase 适合特别大数据量写入场景,写入数据后,再异步对数据进行分析处理,对应业务场景就为:对实时性要求不需要太高,但需要特大数据量写入场景,如硬件,车载系统数据监控采集,用户画像等场景。

(总结:主要解决海量存储问题,后续集成数据分析组件,可完成大数据分析,用户行为,实时推荐,风控等功能)。

而MongoDB本文没有做过多的介绍,MongoDB的写入性能在大数据量情况下远远低于HBase,虽然在同机器集群配置下,MongoDB的写入能力不如HBase,但在查询下数据时,MongoDB因为在写入数据时会创建对应索引信息,查询速度和维度将高于HBase,HBase查询数据的维度有限,从查询的灵活度和各种条件的查询效率而言,MongoDB略胜一筹。所以更加适合需要实时查询分析的场景,但如果需要提高MongoDB的写入能力,可能需要更多高性能集群节点加入才可以提高MongoDB的写入能力。

在真正使用过程中,要分析不同的组件产品,以便于匹配最适合自己的业务场景以供使用。

文章目录

随心笔记

技术无止境 创新不停驻