Hbase中的日志结构化合并树答案

【问题标题】：Log Structured Merge Tree in HbaseHbase中的日志结构化合并树
【发布时间】：2012-11-25 15:01:07
【问题描述】：

我正在研究 Hbase。我对 Hbase 如何使用 LSM 按排序顺序存储数据有疑问。

据我了解，Hbase 在大规模数据处理中使用 LSM Tree 进行数据传输。当数据来自客户端时，它首先顺序存储在内存中，然后排序并存储为 B-Tree 作为存储文件。比它将 Store 文件与 Disk B-Tree(of key) 合并。这是正确的吗？我错过了什么吗？

如果是，则在集群环境中。有多个 RegionServers 接受客户端请求。在那种情况下，（每个 regionServer 的）所有 Hlogs 如何与磁盘 B-Tree 合并（作为分布在所有 dataNode 磁盘上的现有密钥）？
是不是像Hlog只把数据和同一个regionServer的Hfile合并？

【问题讨论】：

标签： hadoop hbase hive hdfs

【解决方案1】：

你可以看看这两篇描述你想要什么的文章

http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/

http://blog.cloudera.com/blog/2012/06/hbase-write-path/

简而言之：

客户端向负责处理密钥的区域服务器发送数据
（.META. 包含每个区域的关键范围）
用户操作（例如put）被写入Write-Ahead-Log（WAL，HLog）
（该日志仅用于“安全”，如果区域服务器崩溃，则重播日志以恢复未写入磁盘的数据）
写入日志后，数据也写入MemStore
...一旦 memstore 达到阈值（conf 属性）
memstore 被刷新到磁盘上，创建一个单独的 hfile
...当 hfile 的数量增长过多（conf 属性）时，压缩开始（合并）

在磁盘数据结构方面： http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/ 上面的文章涵盖了 hfile 格式... 它是一种仅附加格式，可以看作是 b+树。（记住这个b+tree不能就地修改）

HLog只用于“安全”，一旦数据写入hfiles，日志就可以扔掉

【讨论】：

我浏览了上面的链接。很好的文章。我想知道的一件事是：当多个客户端从不同区域对同一张表执行 put 时，在这种情况下，客户端将数据放在 R1 和区域上的数据是 R2，而不是 R1 的内存数据与 R2 合并磁盘数据？或 R1 将数据发送到 R2 的 Memstore（内存中），然后 Memstore 将数据放入与 R2 数据合并的 Hfile 中，是否正确？
每个区域负责处理一组键，例如Region-1 处理 A-E 范围，Region-2 处理 F-M 范围，... 每个客户端通过查看要放置的行键和 .META 中的键范围/区域映射来知道选择哪个区域。每个区域管理它自己的键子集，因此区域之间没有交叉合并。您无法在 Region-2 中发送密钥 A，因为您无法在 Region-1 中发送密钥 F
还有一个问题。当数据来自客户端时，它会在内存中存储在 MemStore 中，然后排序并转储到 Hfile 中。那么当 LSM 出现时呢？下一个 MemStore 与 Hfile 合并？或创建新的 Hfile ？还是多个 Hfile 聚合到磁盘树？
我读了 Hbase 的书。他们告诉说“..存储文件的排列类似于 B 树，但针对顺序磁盘访问进行了优化，其中所有节点都被完全填充并存储为单页或多页块。更新存储文件是滚动完成的合并方式，即系统将现有的磁盘多页块与刷新的内存数据一起打包，直到块达到其最大容量，此时开始一个新的块。“无法获得这部分！
LSM 的基本思想是，按顺序记下数据，然后当你有太多的搜索时将它们合并在一起。在 HBase 中，这被翻译为，在内存中积累一些数据，然后刷新到单个 hfile 被写入磁盘（顺序写入）。合并部分是当您有太多文件（〜太多搜索）时的压缩，您将文件合并在一起，在一个文件中减少搜索并删除可能的重复/删除等等...... MemStore 永远与 hfile 合并，MemStore 只是一个缓冲区，将作为单个 hfile 刷新。

【解决方案2】：

根据 HBase 中的 LSM-tree 模型，数据由两部分组成 - 包含数据最近更新的内存树和将数据的其余部分排列成不可变顺序 B 形式的磁盘存储树树位于硬盘驱动器上。 HBase 服务有时会决定它在内存中有足够的更改以将它们刷新到文件存储中。在这种情况下，它执行从虚拟空间到磁盘的数据滚动合并，执行类似于合并排序算法的合并步骤的操作。

在 HBase 基础架构中，此类数据模型基于多个组件，这些组件将集群中的所有数据组织为位于从属服务器上并由主主服务驱动的 LSM 树的集合。该系统由以下组件驱动：

HMaster - 主要的 HBase 服务，通过管理和平衡它们之间的数据来维护从属 Region Server 节点的正确状态。此外，它还驱动存储中元数据信息的更改，例如表或列的创建和更新。

Zookeeper - 表示 HBase 服务及其客户端使用的分布式缓存，用于存储协调一致的有关命名和配置的最新信息。

区域服务器 - HBase 工作节点，以 LSM-tree 方式执行信息片段的管理和存储 HDFS - 由区域服务器在后台用于实际存储数据

从底层开始，HBase 功能的大部分位于区域服务器中，该服务器对表执行读写工作。从技术上讲，每个表都可以作为称为 HRegions 的单独部分的集合分布在不同的区域服务器上。单个区域服务器节点可以容纳一个表的多个 HRegions。每个 HRegion 保存一定范围的内存和磁盘空间之间共享的行，并按 key 属性排序。这些范围在不同区域之间不相交，因此我们可以在集群中传递它们的顺序行为。单个区域服务器 HRegion 包括以下部分：

预写日志 (WAL) 文件 - 数据在每次写入操作进入内存之前被持久化的第一个位置。正如我之前提到的，LSM 树的第一部分保存在内存中，这意味着它可能会受到一些外部因素的影响，例如示例中的功率损耗。将此类操作的日志文件保存在单独的位置可以轻松恢复此部分而不会丢失。

Memstore - 将最近更新信息的有序集合保存在内存中。它是前面描述的 LMS-tree 结构第一部分的实际实现。定期将滚动合并到本地硬盘上称为 HFiles 的存储文件中

HFile - 表示从 Memstore 接收并保存在 HDFS 中的一小段日期。每个 HFile 包含排序的 KeyValues 集合和 B-Tree+ 索引，允许在不读取整个文件的情况下查找数据。 HBase 会定期对这些文件进行归并排序操作，使它们符合标准 HDFS 块的配置大小，避免小文件问题

您可以通过推送数据并将其传递给整个 LSM-tree 过程来手动遍历这些元素。我在最近的文章中描述了如何做到这一点：

https://oyermolenko.blog/2017/02/21/hbase-as-primary-nosql-hadoop-storage/

【讨论】：