根据hbase中的lsm树模型，数据由两部分组成：内存树（包含数据的最新更新）和磁盘存储树（disk store tree），磁盘存储树将数据的其余部分排列成位于硬盘上的不可变顺序b树。hbase服务有时会决定它在内存中有足够的更改来将它们刷新到文件存储中。在这种情况下，它执行数据从虚拟空间到磁盘的滚动合并，执行类似于合并排序算法的合并步骤的操作。
在hbase基础设施中，这种数据模型基于几个组件，这些组件将集群中的所有数据组织为lsm树的集合，这些lsm树位于从属服务器上，由主服务驱动。系统由以下部件驱动：
hmaster—主hbase服务，通过管理和平衡从属区域服务器节点之间的数据来维护从属区域服务器节点的正确状态。此外，它还驱动存储中元数据信息的变化，如表或列的创建和更新。
zookeeper—表示hbase服务及其客户端用于存储有关命名和配置的协调最新信息的分布式缓存。
区域服务器—以lsm树方式HDF执行信息管理和存储的hbase工作节点—由场景后面的区域服务器用于数据的实际存储
从底层来看，hbase的大部分功能都位于区域服务器中，该服务器对表执行读写操作。从技术上讲，每个表都可以作为称为hregions的独立部分的集合分布在不同的区域服务器上。单个区域服务器节点可以容纳一个表的多个区域。每个hregion都有一定范围的行，这些行在内存和磁盘空间之间共享，并按key属性排序。这些范围在不同的区域之间不相交，因此我们可以在集群中中继它们的连续行为。单个区域服务器hregion包括以下部分：
提前写入日志（wal）文件—每次写入操作都会在进入内存之前保留数据的第一个位置。正如我前面提到的，lsm树的第一部分保存在内存中，这意味着它可能会受到一些外部因素的影响，比如示例中的功率损失。将此类操作的日志文件保存在一个单独的位置，可以轻松地恢复该部分，而不会出现任何松动。
memstore—保存内存中信息的最新更新的排序集合。它是前面描述的lms树结构的第一部分的实际实现。定期执行滚动合并到本地硬盘上名为hfiles的存储文件中
hfile—表示从memstore接收并保存在hdfs中的一小段日期。每个hfile包含排序的keyvalues集合和b-tree+索引，允许在不读取整个文件的情况下查找数据。hbase定期对这些文件执行合并排序操作，以使它们适合标准hdfs块的配置大小，并避免小文件问题

您可以通过推送数据并将其传递给整个lsm树过程来手动遍历这些元素。我在最近的文章中描述了如何做到这一点：
https://oyermolenko.blog/2017/02/21/hbase-as-primary-nosql-hadoop-storage/

你可以看看这两篇文章，它们准确地描述了你想要什么
http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/
http://blog.cloudera.com/blog/2012/06/hbase-write-path/
简而言之：
客户端将数据发送到负责处理密钥的区域服务器
（.元。包含每个区域的键范围）
用户操作（例如put）被写入预写日志（wal，hlog）
（日志仅用于“安全”如果区域服务器崩溃，则会重放日志以恢复未写入磁盘的数据）
写入日志后，数据也会写入memstore
…一旦memstore达到阈值（conf属性）
memstore在磁盘上刷新，创建一个hfile
…当hfiles的数量增长过多（conf属性）时，压缩开始（merge）
在磁盘数据结构方面：http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/ 上面的文章介绍了hfile格式。。。它是一种仅附加的格式，可以看作是一个b+树(请记住，此b+树不能就地修改）
hlog只用于“安全”，一旦数据写入hfiles，日志就可以被丢弃