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的写入能力。

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