HBase WAL原理学习

关注

转载最新推荐文章于 2026-10-20 11:15:15 发布 3.1k 阅读 AI 写同款· GEO 优化 ›

大数据组件的WAL机制的架构设计原理对比 HBase 的 HLog 滚动清理 vs 长时间保留（增加恢复选项但占用存储）ZooKeeper 同步刷盘（强一致） vs Flink 异步刷盘（高性能）增量快照（如 Flink 的 Changelog）可能部分替代传统 WAL。：通过“日志先行”在性能与可靠性之间取得平衡，但需根据场景优化配置。：选择 ZooKeeper 或 HBase（同步 WAL）。存储硬件（如 NVMe）提升 WAL 的写入性能瓶颈。：优先考虑 Redis 或 Kafka（异步刷盘）。Kafka 的日志分段删除策略（按时间/大小）阅读详情

1.概述
客户端往RegionServer端提交数据的时候，会写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败，换句话说这其实是一个数据落地的过程。在一个RegionServer上的所有的Region都共享一个HLog，一次数据的提交是先写WAL，再写memstore，示意图如下

2.HLog Class
WAL的实现类是HLog，当一个Region被初始化的时候，一个HLog的实例会作为构造函数的参数传进去。当Region在处理Put、Delete等更新操作时，可以直接使用该共享的HLog的append方法来落地数据。Put、Delete在客户端上可以通过setWriteToWAL(false)方法来关闭该操作的日志，这么做虽然可以提升入库速度，但最好别这么做，因为有数据丢失的风险存在。
HLog的另一个重要功能是跟踪变化，这个通过sequence number来实现。sequence number作为HFile里的一个元数据字段，它用来跟踪哪些日志是已经持久化了的，哪些还在内存中。（注：通过对源码的分析，这种变化因为每个Region是不一样的，所以在HLog的日志里是记录了多条，是针对于每个Region来记录的，把该Region的最后一次持久化的seqId作为一条日志写入HLog，这样，比该seqId小的数据就是已经持久化过的了。）（照这种分析，在HLog replay的过程中，岂不是从后往前replay日志更方便么？有待学习replay的实现方式来验证）

这个图表明同一个RegionServer上的三个Region共享一个HLog，因此当它们写数据时，是把<HLogKey,WALEdit>这个的数据对按顺序混合的写到HLog上的，以获得最好的写入速度。

3.HLogKey Class
WAL现在是通过Hadoop的SequenceFile来存储key/value集合。value简单的存储了来自客户端的数据如row key, column family, column qualifier, timestamp, type, and value；而HLogKey则存储了the region and table name、还有更新时间、sequence number和cluster ID,cluster ID用于将日志复制到集群里的其他机器上。

4.WALEdit Class
来自客户端的更新数据的请求被封装到WALEdit类上。这个类把对row数据的修改原子化。(怎么原子化的还得看源码)
5.LogSyncer Class
Table在创建的时候，有一个参数可以设置，是否每次写Log日志都需要往集群里的其他机器同步一次，默认是每次都同步，同步的开销是比较大的，但不及时同步又可能因为机器宕而丢日志。
Pipeline vs. n-Way Writes
同步的操作现在是通过Pipeline的方式来实现的，Pipeline是指datanode接收数据后，再传给另外一台datanode，是一种串行的方式；n-Way Writes是指多datanode同时接收数据，最慢的一台结束就是整个结束。差别在于一个延迟大，一个并发高，hdfs现在正在开发中，以便可以选择是按Pipeline还是n-Way Writes来实现写操作。
Table如果设置每次不同步，则写操作会被RegionServer缓存，并启动一个LogSyncer线程来定时同步日志，定时时间默认是一秒也可由hbase.regionserver.optionallogflushinterval设置

5、HLog的几个特点
WAL(Write-Ahead-Log)是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时，首先将其数据封装成〉，append到RegionServer对应的 HLog文件的过程。它有几个重要的特点：
1、RegionServer上所有的Region共享HLog文件；也就是RegionServer的个数与HLog是一一对应的，为什么不选择每个Table对应一个HLog的原因是，通过RegionServer的个数可以衡量分布式系统的规模，这是系统运维可以控制的因素，而Table的个数和大小完全是由应用层来决定。极端情况下，我们的HBase集群可能只有一张大表 (每天10亿规模的读写)，而可能需要上百个节点搭建HBase集群，在这种情况下，按照RegionServer记录一个HLog的意义就凸现出来了。同样的道理可以解释，为什么要把所有的Region的log都插入同一个文件。

图 1 RegionServer内WAL文件与Region的关系图

2、HLog也是记录在HDFS上；这一个众所周知的问题，这里提出来的原因在于，在大多数情况下它成为了影响了HBase写操作吞吐的重要因素。如图2、3显示，在对表格进行批量删除数据时，每次操作时不写HLog比写HLog，性能要好大概10~20倍。而且正是由于写HDFS的原因，可以看到大概有些点的性能偏离平均值2倍以上的性能。对于图2写WAL而言，这些点大部分属于写HDFS响应的时间的异常点。在HBase-0.92版本中，使用的append操作在hdfs底层其实是一种write操作，而这种操作在遇到超过block预设大小时，会有一次和NameNode的操作，另外在高负载的HDFS集群上，写速度波浪式的，不会持续保持稳定，而这种不稳定对于像append这样的操作，最终在反复测试时，就会表现出现偏离平均值2倍以上的1%现象。相比较而言，图3由于没有写WAL，可以看到它不仅在平均性能上表现更好，也在稳定性上更胜一筹，它的抖动出现在MemStore向HDFS刷数据的时间点上。显然，在MemStore足够大的情况下，这种波动是可以预期的，甚至也是很多应用可以容忍的。

图 2写WAL批量删除数据的性能图

图 3不写WAL批量删除数据的性能图

写 WAL 还是不写 WAL ，在一定程度上确实会给系统性能产生了很大影响，根据 HBase 内部设计， WAL 是一种规避数据丢失风险的一种补偿机制，如果应用可以容忍一定的数据丢失的风险，可以尝试在更新数据时，关闭写 WAL 。下一篇文章，会介绍使用不写 WAL 删除数据失效的场景。

3、HLog是系统稳定的重要依据。在一个HRegionServer的存活周期内，可能因为长时间的Stop-The-World GC，或者因为它所依赖的HDFS或者ZooKeeper，出现下线的情况，对于一个高负载的HBase生产集群而言，这是一个非常常见的现象。对于RegionServer的下线，往往通过jps监控进程存活和nc –z来监控关键服务端口的存活状态来验证服务的状态，保证让下线的RegionServer尽快恢复，保证原HBase集群的整体负载的吞吐。在RegionServer下线这个过程中，是HBase内部最核心部件工作的关键时期，简单总结一下RegionServer下线后内核处理流程如下：

(1) HMaster从ZooKeeper捕获到对应RegionServer的znode被删除，将其放入ServerManager的DeadSevers列表中。

（2）启动ServerShutdownHandler，进入该handler的处理流程中。

（3）SplitLogManager对原RegionServer的HLog文件夹内的Hlog文件提交到zookeeper的splitlog路径下。(注意，HLog存在Roll操作，造成了Hlog文件夹内可能存在多个hlog文件)。

（4）SplitLogManager等待RegionServer上的SplitLogWorker认领任务，并在任务完成之后，进入Region Assign流程。每个SplitLogWorker都会经历将HLog上出现的所有Region分别以文件的形式存储，在hbase所在hdfs根目录下splitlog文件夹内，会以RegionServer认领一个某个下线的RegionServer的HLog为文件夹名，包含按照Region分散开来的Hlog文件集。

（5）HMaster的AssignmentManager从.META.以及当前处于InTransaction状态的集合中，计算出需要Assign的Region，然后通过getRegionPlan获得将该Region迁移的目的地址，并修改Region状态从Offline变成OPENING。然后AssignmentManager就进入了状态机的处理流程中。

（6）被选中目的地的Region，Master通过RPC让其执行openRegion操作，RegionSever使用HRegion.openRegion,会首先经历一次replayRecoveredEditsIfAny，将那些散落在splitlog下各个worker处理过的Region的Hlog信息加载过来，并执行replay。

（7）所有相关的Region处理完毕，这样一个RegionServer下线的影响就结束了。在这段时间内，相应Region的读写操作全部暂停。你如果客户端写得比较友好，Region上线有足够快的话，对于客户端而言，相当于一次服务抖动，只是这个抖动有点大。

从这个流程中可以看出，虽然HLog采用了Distributed Split来加快切分，但是这里Hlog的稳定仍然是服务稳定性重要因素。因此，有一项比较有趣的事情时，我们完全可以做一个备用的RegionServer来轮询是否有RegionServer处于下线状态，一旦处于下线状态，就按照只读的方式来加载相应的Region，这样至少可以保证在RegionServer下线，可以保证数据服务的一定的可用性。