原文:http://blog.sina.com.cn/s/blog_4a1f59bf010197ct.html
WAL(Write-Ahead-Log)是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时,首先将其数据封装成〉,append到RegionServer对应的 HLog文件的过程。它有几个重要的特点:
图 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批量删除数据的性能图
-
(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,会首先经历一次replayRecoveredEditsIfAn
y,将那些散落在splitlog下各个worker处理过的Region的Hlog信息加载过来,并执行replay。
- (7)所有相关的Region处理完毕,这样一个RegionServer下线的影响就结束了。在这段时间内,相应Region的读写操作全部暂停。你如果客户端写得比较友好,Region上线有足够快的话,对于客户端而言,相当于一次服务抖动,只是这个抖动有点大。
从这个流程中可以看出,虽然HLog采用了Distributed Split来加快切分,但是这里Hlog的稳定仍然是服务稳定性重要因素。因此,有一项比较有趣的事情时,我们完全可以做一个备用的RegionServer来轮询是否有RegionServer处于下线状态,一旦处于下线状态,就按照只读的方式来加载相应的Region,这样至少可以保证在RegionServer下线,可以保证数据服务的一定的可用性。