Hbase的WAL机制 Write Ahead Log (WAL)

叁歲伎倆 2022-10-01 14:45 290阅读 0赞

### 简介 ###

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

客户端向RegionServer端提交数据的时候，会先写入WAL日志，只有当WAL日志写入成功的时候，客户端才会被告诉提交数据成功。如果写WAL失败会告知客户端提交失败，这其实就是数据落地的过程。

在一个RegionServer上的所有Region都共享一个HLog，一次数据的提交先写入WAL，写入成功后，再写入menstore之中。当menstore的值达到一定的时候，就会形成一个个StoreFile。

![20180419134053354][]

## 架构图——线程模型、消息机制 ##

![668023-20160825165419007-57626050.png][]

## 解决的问题 ##

HBase的Write Ahead Log (WAL)提供了一种高并发、持久化的日志保存与回放机制。每一个业务数据的写入操作（PUT / DELETE）执行前，都会记账在WAL中。

如果出现HBase服务器宕机，则可以从WAL中回放执行之前没有完成的操作。

本文主要探讨HBase的WAL机制，如何从线程模型、消息机制的层面上，解决这些问题：

**1. 由于多个HBase客户端可以对某一台HBase Region Server发起并发的业务数据写入请求，因此WAL也要支持并发的多线程日志写入。——确保日志写入的线程安全、高并发。**

2. **对于单个HBase客户端，它在WAL中的日志顺序，应该与这个客户端发起的业务数据写入请求的顺序一致**。

（对于以上两点要求，大家很容易想到，用一个队列就搞定了。见下文的架构图。）

3. **为了保证高可靠，日志不仅要写入文件系统的内存缓存，而且应该尽快、强制刷到磁盘上（即WAL的Sync操作）。但是Sync太频繁，性能会变差。所以：**

** (1) Sync应当在多个后台线程中异步执行**

** (2) 频繁的多个Sync，可以合并为一次Sync——适当放松对可靠性的要求，提高性能**。

## Region Server RPC服务线程 ##

这些线程处理HBase客户端通过RPC服务调用（实际上是Google Protobuf服务调用）发出的业务数据写入请求。在上图的例子中，“Region Server RPC服务线程1” 做了3个Row的Append操作，和一个强制刷磁盘的Sync操作。

Sync操作是为了确保之前的Append操作（包括涉及的业务数据）一定可靠地记录到了磁盘上的日志中，然后HBase才能做后续相对不可靠的复杂操作，比如写入MemStore。——这就是Write Ahead的语义。

从架构图中可见，并发的Append操作只是往队列中增加了Append请求对象。

这里的队列是一个LMAX Disrutpor RingBuffer（[我的这篇文章][Link 1]作了介绍），你可以简单理解为是一个无锁高并发队列。

Append的具体代码如下：

![668023-20160825170159835-804820375.png][]

对于Sync操作：

(1)往队列里放一个SyncFuture对象，代表一次Sync操作请求。

每一个SyncFuture都有一个自增的Sequence ID——这是全局唯一的，由LMAX Disrutpor队列创建。后来的SyncFuture的Sequence ID更高。

(2)调用SyncFuture.get()**阻塞等待**，直到后台线程（架构图中的SyncRunner）通知SyncFuture退出阻塞，表明WAL日志已经保存在了磁盘上。

![668023-20160825170556429-1368487593.png][]

## WAL日志消费线程 ##

WAL机制中，只有一个WAL日志消费线程，从队列中获取Append和Sync操作。这样一个**多生产者，单消费者的模式**，决定了WAL日志并发写入时日志的全局唯一顺序。

1. 对于获取到的Append操作，直接调用Hadoop Sequence File Writer将这个Append操作（包括元数据和row key, family, qualifier, timestamp, value等业务数据）写入文件

![668023-20160825171816022-1854619320.png][]

因此WAL日志文件使用的是Hadoop Sequence文件格式。当然，它也可以替换成其他存储格式，如Avro。

Hadoop Sequence文件格式不再这里累述，其主要特点是：

(1) 二进制格式。row key, family, qualifier, timestamp, value等HBase byte\[\]数据，都原封不动地顺序写入文件。

(2) Sequence文件中，每隔若干行，会插入一个16字节的魔数作为分隔符。这样如果文件损坏，导致某一行残缺不全，可以通过这个魔数分隔符跳过这一行，继续读取下一个完整的行。

(3) 支持压缩。可以按行压缩。也可以按块压缩（将多行打成一个块）

### Hbase容错处理 ###

WAL记载了每一个RegionServer对应的HLog。RegionServer1或者RegionServer1上某一个regiong挂掉了，都会迁移到其它的机器上处理，重新操作，进行恢复。

当RegionServer意外终止的时候，Master会通过Zookeeper感知到，Master首先会处理遗留下来的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应的Region目录下，然后再将实效的Region重新分配，领取到这些Regio你的RegionMaster发现有历史的HLog需要处理，因此会Replay HLog的数据到Memstore之中，然后flush数据到StoreFiles，完成数据的恢复。

### Hbase适用场景 ###

1.大数据量存储，大数据量高并发操作。

2.需要对数据随机读写操作。

3.读写访问均是非常简单的操作

### Hbase和HDFS的关系 ###

相同点：

二者都具有良好的容错性和扩展性，都可以扩展成百千上万个结点

不同点：

1.HDFS适合批处理场景。

2.HDFS不支持数据的随机查找、不适合增量数据处理、不支持数据更新。

关系：

Hbase内存管理的所有文件都存储在HDFS之中。

原文：

[https://www.cnblogs.com/ohuang/p/5807543.html][https_www.cnblogs.com_ohuang_p_5807543.html]

https://blog.csdn.net/joananjin/article/details/80003743

[20180419134053354]: /images/20220118/56e9c61dd9b448f3b022fb99b0ecb23b.png
[668023-20160825165419007-57626050.png]: /images/20220118/35dfdab7b6f44b66b3c71e92b8826298.png
[Link 1]: http://www.cnblogs.com/ohuang/p/5799467.html
[668023-20160825170159835-804820375.png]: /images/20220118/921988d57b2f4de4911b5d89d2215c60.png
[668023-20160825170556429-1368487593.png]: /images/20220118/5208390c9afa4c9e85ac529674453a3d.png
[668023-20160825171816022-1854619320.png]: /images/20220118/442519544b9b41678315885ddf7203c2.png
[https_www.cnblogs.com_ohuang_p_5807543.html]: https://www.cnblogs.com/ohuang/p/5807543.html