HBase WAL原理学习

转载 2013年12月06日 10:28:33
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)HBaseRegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次PutDelete等一条记录时,首先将其数据封装成〉,appendRegionServer对应的 HLog文件的过程。它有几个重要的特点:
    1RegionServer上所有的Region共享HLog文件;也就是RegionServer的个数与HLog是一一对应的,为什么不选择每个Table对应一个HLog的原因是,通过RegionServer的个数可以衡量分布式系统的规模,这是系统运维可以控制的因素,而Table的个数和大小完全是由应用层来决定。极端情况下,我们的HBase集群可能只有一张大表 (每天10亿规模的读写),而可能需要上百个节点搭建HBase集群,在这种情况下,按照RegionServer记录一个HLog的意义就凸现出来了。 同样的道理可以解释,为什么要把所有的Regionlog都插入同一个文件。

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

 1 RegionServerWAL文件与Region的关系图


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

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

 

 

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



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

 

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

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

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

  •  (1) HMasterZooKeeper捕获到对应RegionServerznode被删除,将其放入ServerManagerDeadSevers列表中。
  • 2)启动ServerShutdownHandler,进入该handler的处理流程中。
  • 3SplitLogManager对原RegionServerHLog文件夹内的Hlog文件提交到zookeepersplitlog路径下。(注意,HLog存在Roll操作,造成了Hlog文件夹内可能存在多个hlog文件)
  • 4SplitLogManager等待RegionServer上的SplitLogWorker认领任务,并在任务完成之后,进入Region Assign流程。每个SplitLogWorker都会经历将HLog上出现的所有Region分别以文件的形式存储,在hbase所在hdfs根目录下splitlog文件夹内,会以RegionServer认领一个某个下线的RegionServerHLog为文件夹名,包含按照Region分散开来的Hlog文件集。
  • 5HMasterAssignmentManager.META.以及当前处于InTransaction状态的集合中,计算出需要AssignRegion,然后通过getRegionPlan获得将该Region迁移的目的地址,并修改Region状态从Offline变成OPENING。然后AssignmentManager就进入了状态机的处理流程中。
  • 6)被选中目的地的RegionMaster通过RPC让其执行openRegion操作,RegionSever使用HRegion.openRegion,会首先经历一次replayRecoveredEditsIfAny,将那些散落在splitlog下各个worker处理过的RegionHlog信息加载过来,并执行replay
  • 7)所有相关的Region处理完毕,这样一个RegionServer下线的影响就结束了。在这段时间内,相应Region的读写操作全部暂停。你如果客户端写得比较友好,Region上线有足够快的话,对于客户端而言,相当于一次服务抖动,只是这个抖动有点大。

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

提升HBase写性能

本文主要介绍软件层面的性能调优。故,在此之前,请检查硬件状况。硬盘推荐SSD,一般SATA即可。网络千兆以上。可以安装Ganglia等工具,检查各节点的各硬件的运作状态:CPU,Memo,网络等等。 ...
  • dyllove98
  • dyllove98
  • 2013年02月16日 10:32
  • 4830

HBase的WAL机制

WAL(Write-Ahead-Log)预写日志是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时,首先将其数据写入到...
  • scgaliguodong123_
  • scgaliguodong123_
  • 2015年07月04日 21:10
  • 5468

HBase WAL 解析

WAL(Write-Ahead-Log)是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。大致过程如下图所示,首先客户端启动一个操作来修改数据,每一个修改都...
  • u010039929
  • u010039929
  • 2017年07月04日 15:05
  • 574

JAVA操作HBASE数据操作详解

JAVA操作HBASE数据操作详解
  • kezhong_wxl
  • kezhong_wxl
  • 2017年08月23日 22:10
  • 403

HBase 预写日志 (WAL)

WAL最重要的作用是灾难恢复,一旦服务器崩溃,通过重放log,我们可以恢复崩溃之前的数据。如果写入WAL失败,整个操作也将认为失败。 图6  WAL   基本流程:首先,客户...
  • mlljava1111
  • mlljava1111
  • 2014年10月15日 22:06
  • 674

Hbase WAL线程模型源码分析

Hbase的WAL机制是保证hbase使用lsm树存储模型把随机写转化成顺序写,并从内存read数据,从而提高大规模读写效率的关键一环。wal的多生产者单消费者的线程模型让wal的写入变得安全而高效。...
  • tengxy_cloud
  • tengxy_cloud
  • 2016年12月12日 10:03
  • 505

HBase最佳实践-HBase中的写性能优化策略

上一篇文章主要介绍了HBase读性能优化的基本套路,本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比,HBase写数据流程倒是显得很简单:数据先顺序写入HLog,再写入对应...
  • ourpush
  • ourpush
  • 2016年12月10日 14:37
  • 981

Hbase的基本操作

Hbase的基本操作Hbase的基本操作总结,目前先包含hbase shell的操作,后续有时间再加入API的操作。 Hbase 是一个分布式的、面向列的开源数据库,...
  • w541826816
  • w541826816
  • 2015年05月13日 11:47
  • 2697

有关HBase系统配置级别的优化

转载自:http://www.cnblogs.com/panfeng412/archive/2012/03/08/hbase-performance-tuning-section1.html ...
  • kky2010_110
  • kky2010_110
  • 2013年10月17日 14:50
  • 2787

HBase WAL预写日志

HBase的region服务器会将数据保存到内存中,直接有足够多的数据才会将其刷写到硬盘中,这样可以避免创建很多的小文件。存储在内存中的数据具有不稳定性,如果服务器断电那么内存中的数据就会可能丢失。 ...
  • Post_Yuan
  • Post_Yuan
  • 2016年12月12日 09:48
  • 474
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:HBase WAL原理学习
举报原因:
原因补充:

(最多只允许输入30个字)