HBase源碼分析之WAL
WAL(Write-Ahead Logging)是數據庫系統中保障原子性和持久性的技術，通過使用WAL可以將數據的隨機寫入變為順序寫入，可以提高數據寫入的性能。在hbase中寫入數據時，會將數據寫入內存同時寫wal日誌,為防止日誌丟失，日誌是寫在hdfs上的。
默認是每個RegionServer有1個WAL，在HBase1.0開始支持多個WALHBASE-5699,這樣可以提高寫入的吞吐量。配置參數為hbase.wal.provider=multiwal,支持的值還有defaultProvider和filesystem(這2個是同樣的實現)。
WAL的持久化的級別有如下幾種：
- SKIP_WAL：不寫wal日誌,這種可以較大提高寫入的性能，但是會存在數據丟失的危險，只有在大批量寫入的時候才使用(出錯了可以重新運行)，其他情況不建議使用。
- ASYNC_WAL：異步寫入
- SYNC_WAL：同步寫入wal日誌文件，保證數據寫入了DataNode節點。
- FSYNC_WAL: 目前不支持了，表現是與SYNC_WAL是一致的
- USE_DEFAULT: 如果沒有指定持久化級別，則默認為USE_DEFAULT, 這個為使用HBase全局默認級別(SYNC_WAL)
wal寫入
先看看wal寫入中的幾個主要的類
1. WALKey:wal日誌的key，包括regionName：日誌所屬的region
tablename：日誌所屬的表，writeTime：日誌寫入時間，clusterIds:cluster的id，在數據復制的時候會用到。
2.WALEdit:在hbase的事務日誌中記錄一系列的修改的一條事務日誌。另外WALEdit實現了Writable接口，可用於序列化處理。
3. FSHLog: WAL的實現類，負責將數據寫入文件系統
在每個wal的寫入這裏使用的是多生產者單消費者的模式，這裏使用到了disruptor框架，將WALKey和WALEdit信息封裝為FSWALEntry，然後通過RingBufferTruck放入RingBuffer中。接下來看hlog的寫入流程，分為以下3步：
- 日誌寫入緩存：由rpcHandler將日誌信息寫入緩存ringBuffer.
- 緩存數據寫入文件系統：每個FSHLog有一個線程負責將數據寫入文件系統(HDFS)
- 數據同步：如果操作的持久化級別為(SYNC_WAL或者USE_DEFAULT 則需進行數據同步處理
下面來詳細說明一下各類線程是如何配合來實現這幾步操作的，
- rpcHandler線程負責將日誌信息(FSWALEntry)寫入緩存RingBbuffer，在操作日誌寫完後，rpcHandler會調用wal的sync方法，進行數據同步，其實際處理為寫入一個SyncFuture到RingBuffer，然後blocking一直到syncFuture處理完成。
- wal線程從緩存RingBuffer中取數據，如果為日誌(FSWALEntry)就調用Writer將數據寫入文件系統，如果為SyncFuture,則由專門的同步線程來進行同步處理。
整體處理流程圖如下：
HLog的寫入
wal寫入文件系統是通過Writer來寫入的，其實際類為ProtobufLogWriter，使用的是Protobuf的格式持久化處理。使用Protobuf格式有如下優勢：
- 性能較高
- 結構更加緊湊，節省空間
-
方便擴展以及支持其他語言，通過其他語言來解析日誌。
寫入的日誌中是按WALKey和WALEdit來依次存儲的（具體內容見前面WALKey和WALEdit類的說明），另外還將WALKey和WALEdit分別進行了壓縮處理。
wal同步過程
每個wal中有一個RingBufferEventHandler對象，其中用數組管理著多個SyncRunner線程(由參數hbase.regionserver.hlog.syncer.count配置，默認5)來進行同步處理，每個SyncRunner對象裏面有一個LinkedBlockingQueue(syncFutures,大小為參數{hbase.regionserver.handler.count默認值200}*3
另外這裏的SyncFuture是每個rpcHandler線程擁有一個，由wal中的private final Map
class RingBufferEventHandler implements EventHandler<RingBufferTruck>, LifecycleAware {
private final SyncRunner [] syncRunners;
private final SyncFuture [] syncFutures;
...
}
private class SyncRunner extends HasThread {
private volatile long sequence;
// Keep around last exception thrown. Clear on successful sync.
private final BlockingQueue<SyncFuture> syncFutures;
...
}這裏在處理ringBuffer中的syncFuture時，不是每有一個就提交到syncRunner處理，而是按批來處理的，這裏的批分2種情況：
- 從ringBuffer中取到的一批數據(為提高效率，在disruptor框架中是按批從ringBuffer中取數據的，具體的請看disruptor的相關文檔)，如果這批數據中的syncFuture個數<{hbase.regionserver.handler.count默認值200},則按一批處理
- 如果這一批數據中的syncFuture個數>={hbase.regionserver.handler.count默認值200}個數，則按{hbase.regionserver.handler.count默認值200}分批處理。
如果達到了批大小，就從syncRunner數組中順序選擇下一個SyncRunner,將這批數據插入該SyncRunner的BlockingQueue中。最後由SyncRunner線程進行hdfs文件同步處理。為保證數據的不丟失，rpc請求需要保證wal日誌寫入成功後才能返回，這裏HBase做了一系列的優化處理的操作。
wal滾動
通過wal日誌切換，這樣可以避免產生單獨的過大的wal日誌文件，這樣可以方便後續的日誌清理(可以將過期日誌文件直接刪除)另外如果需要使用日誌進行恢復時，也可以同時解析多個小的日誌文件，縮短恢復所需時間。
wal觸發切換的場景有如下幾種：
- SyncRunner線程在處理日誌同步後，如果有異常發生，就會調用requestLogRoll發起日誌滾動請求
- SyncRunner線程在處理日誌同步後, 檢查當前在寫的wal的日誌大小是否超過配置{hbase.regionserver.hlog.blocksize默認為hdfs目錄塊大小}*{hbase.regionserver.logroll.multiplier默認0.95}，超過後同樣調用requestLogRoll發起日誌滾動請求
- 每個RegionServer有一個LogRoller線程會定期滾動日誌，滾動周期由參數{hbase.regionserver.logroll.period默認值1個小時}控制
這裏前面2種場景調用requestLogRoll發起日誌滾動請求，最終也是通過LogRoller來執行日誌滾動的操作。
wal失效
當memstore中的數據刷新到hdfs後，那對應的wal日誌就不需要了，FSHLog中有記錄當前memstore中各region對應的最老的sequenceId，如果一個日誌中的各個region的操作的最新的sequenceId均小於wal中記錄的各個需刷新的region的最老sequenceId，說明該日誌文件就不需要了，於是就會將該日誌文件從./WALs目錄移動到./oldWALs目錄。這塊是在前面日誌滾動完成後調用cleanOldLogs來處理的。
wal刪除
由於wal日誌還會用於跨集群的同步處理，所以wal日誌失效後並不會立即刪除，而是移動到oldWALs目錄。由HMaster中的LogCleaner這個Chore線程來負責wal日誌的刪除，在LogCleaner內部通過參數{hbase.master.logcleaner.plugins}以插件的方式來篩選出可以刪除的日誌文件。目前配置的插件有ReplicationLogCleaner、SnapshotLogCleaner和TimeToLiveLogCleaner
- TimeToLiveLogCleaner: 日誌文件最後修改時間在配置參數{hbase.master.logcleaner.ttl默認600秒}之前的可以刪除
- ReplicationLogCleaner:如果有跨集群數據同步的需求，通過該Cleaner來保證那些在同步中的日誌不被刪除
- SnapshotLogCleaner: 被表的snapshot使用到了的wal不被刪除
總結
在本篇中對HBase中wal日誌的整個周期進行了敘述，能對wal的處理過程有了整體的了解，後續在單獨說說WAL日誌的恢復的內容。
參考資料：
1. http://hbasefly.com/2016/03/23/hbase_writer/
2. http://hbasefly.com/2016/10/29/hbase-regionserver-recovering/
轉：https://blog.csdn.net/xiangel/article/details/54424900
HBase源碼分析之WAL