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 建表基本命令总结

访问hbase,以及操作hbase,命令不用使用分号 hbase shell 进入hbase list 查看表 hbase shell -d hbase(main):024:0> scan '...

HBase 预写日志 (WAL)

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

我是如何成为一名python大咖的?

人生苦短,都说必须python,那么我分享下我是如何从小白成为Python资深开发者的吧。2014年我大学刚毕业..

hbase 原代码分析 (11) WAL 写日志过程

1) WAL在创建region的时候创建。 2) WAL 存储在HDFS,主要类FSHLog 3) 在put 和delete写入内存之前都会写入WAL,主要是防止机器崩溃时能恢复。 4)用户在协...

HBase的WAL机制

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

HBase源码分析之WAL

WAL(Write-Ahead Logging)是数据库系统中保障原子性和持久性的技术,通过使用WAL可以将数据的随机写入变为顺序写入,可以提高数据写入的性能。在hbase中写入数据时,会将数据写入内...

Hbase的WAL在RegionServer基本调用过程

Hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。本文档用于说明hbase的wal简单原理以及从源码的角度分析...

HBase中的WAL

WAL(Write-Ahead-Log)是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时,首先将其数据封装成〉,ap...

HBase WAL 解析

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

hadoop学习笔记之hbase原理

基础hbase是面向列存储的NoSQL数据库。行的每一列被划分到某一列族,调优和存储都是基于列族完成的。在数据库中,行的每一列作为存储的基本单位,其结构关系为,每一行包含一个或多个列族,一个列族包含多...
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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