Hadoop Hbase中的日志结构合并树

我正在研究Hbase。我有一个关于Hbase如何使用LSM按排序顺序存储数据的问题

据我了解，Hbase在大规模数据处理中使用LSM树进行数据传输。当数据来自客户机时，它首先顺序存储在内存中，然后排序并存储为B树存储文件。然后将存储文件与磁盘B树（键）合并。对吗？我错过什么了吗

• 如果是，则在群集环境中。有多个RegionServer接受客户端请求。在这种情况下，所有HLOG（每个regionServer的）如何与磁盘B-Tree合并（作为分布在所有dataNode磁盘上的现有密钥）

• 是否Hlog仅将数据与同一regionServer的Hfile合并

---

你可以看看这两篇文章，它们准确地描述了你想要什么

简言之：

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

在磁盘数据结构方面： 上面的文章介绍了hfile格式。。。 这是一种仅附加的格式，可以像b+树一样看到。（请记住，此b+树不能就地修改）

---

HLog仅用于“安全”，一旦数据写入hfiles，日志可以丢弃

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

在HBase基础设施中，这种数据模型基于几个组件，这些组件将集群中的所有数据组织为LSM树的集合，这些LSM树位于从属服务器上，由主服务驱动。系统由以下部件驱动：

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

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

区域服务器-以LSM树方式管理和存储信息片段的HBase工作节点 HDFS—由现场后面的区域服务器用于数据的实际存储

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

预写日志（WAL）文件-在每次写入操作中数据在进入内存之前被保存的第一个位置。正如我前面提到的，LSM树的第一部分保存在内存中，这意味着它可能会受到一些外部因素的影响，比如示例中的功率损失。将此类操作的日志文件保存在一个单独的位置将允许轻松恢复此部分，而不会出现任何松动

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

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

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

---

我浏览了上面的链接。很好的文章。我想知道的一件事是：当多个客户端从不同的区域对同一个表执行put时，在这种情况下，客户端将数据放在R1上&该数据的区域是R2，而不是R1的内存数据与R2的磁盘数据合并？或者R1将数据发送到R2的Memstore（内存中），然后Memstore将数据放入与R2数据合并的Hfile中，是否正确？每个区域负责处理一组键，例如区域1处理范围a-e，区域2处理范围F-M。。。每个客户机通过查看要放置的行键和键范围来知道选择哪个区域/