HBase中WAL(Write-Ahead-Log)的特性与场景分析

原文：http://blog.sina.com.cn/s/blog_4a1f59bf010197ct.html

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下线，可以保证数据服务的一定的可用性。