[翻譯]HBase 架構(gòu)101 –預(yù)寫日志系統(tǒng) (WAL)

HBase 架構(gòu)101 –預(yù)寫日志系統(tǒng)  (WAL)

原文：http://www./2010/01/hbase-architecture-101-write-ahead-log.html

什么是預(yù)寫日志WAL? 之前的文章我們簡單介紹了HBase的存儲(chǔ)結(jié)構(gòu)。其中提到了預(yù)寫日志。這里，我們要介紹它的實(shí)現(xiàn)細(xì)節(jié)，所有的描述都基于HBase 0.20.3.

WAL最重要的作用是災(zāi)難恢復(fù)。和MySQL 的BIN log類似，它記錄所有的數(shù)據(jù)改動(dòng)。一旦服務(wù)器崩潰，通過重放log，我們可以恢復(fù)崩潰之前的數(shù)據(jù)。這也意味如果寫入WAL失敗，整個(gè)操作將認(rèn)為失敗。

我們先看看HBase是如何做到的。首先，客戶端初始化一個(gè)可能對數(shù)據(jù)改動(dòng)的操作，如put(Put),delete(Delete) 和 incrementColumnValue()。這些操作都將被封裝在一個(gè)KeyValue對象實(shí)例中，通過RPC 調(diào)用發(fā)送給HRegionServer(最好是批量操作)。 一旦達(dá)到一定大小，HRegionServer 將其發(fā)送給HRegion。這個(gè)過程中，數(shù)據(jù)會(huì)首先會(huì)被寫入WAL，之后將被寫到實(shí)際存放數(shù)據(jù)的MemStore中。

當(dāng)MemStore到達(dá)一定大小，或者經(jīng)過一段時(shí)間后，數(shù)據(jù)將被異步地寫入文件系統(tǒng)中。然而，在兩次寫入文件系統(tǒng)之間的數(shù)據(jù)，是保留在內(nèi)存中的。如果這個(gè)時(shí)候系統(tǒng)崩潰，那數(shù)據(jù)···，別急，我們有WAL！

我們先來看看WAL幾個(gè)重要的類。

HLog

HLog是實(shí)現(xiàn)WAL的類。一個(gè)HRegionServer對應(yīng)一個(gè)HLog實(shí)例。當(dāng)HRegion初始化時(shí)，HLog將作為一個(gè)參數(shù)傳給HRegion的構(gòu)造函數(shù)。

HLog最核心的是調(diào)用doWrite的append() 方法，前面提到的可能對數(shù)據(jù)改動(dòng)的操作都就將首先調(diào)用這個(gè)方法。出于性能的考慮，put(), delete() 和incrementColumnValue()有一個(gè)開關(guān)函數(shù)setWriteToWAL(boolean) ， 設(shè)為false將禁用WAL。這是為什么上圖中向下的箭頭是虛線的原因。默認(rèn)時(shí)候當(dāng)然需要WAL，但是假如你運(yùn)行一個(gè)數(shù)據(jù)導(dǎo)入的MapReduce Job，你可以通過關(guān)閉WAL獲得性能上的提升。

另一個(gè)重要的特性是HLog將通過“sequence number”追蹤數(shù)據(jù)改變。它內(nèi)部使用AtomicLong保證線程安全。sequence number的起始值為0，或者是最近一次存入文件系統(tǒng)中sequence number。Region打開存儲(chǔ)文件，讀取每個(gè)HFile中的最大的sequence number，如果該值大于HLog 的sequence number, 就將它作為HLog 的sequence number的值。最后，HLog將得到上次存入文件和繼續(xù)記log的點(diǎn)。過會(huì)，我們將看到它的應(yīng)用。

上圖表示了3個(gè)不同的region，每一個(gè)負(fù)責(zé)一段rowkey的范圍。這些region將共享同一個(gè)HLog實(shí)例，我們可以看出，從不同region來的數(shù)據(jù)寫入WAL的順序是不確定的。在后面我們會(huì)再詳細(xì)的介紹。

最后，Hlog利用HMaster恢復(fù)和切分一個(gè)由一個(gè)崩潰的HRegionServery遺留下來的Log。之后，重新部署regions。

HLogKey

WAL使用Hadoop的SequenceFile,它將記錄存儲(chǔ)為key/values 的數(shù)據(jù)集。對于WAL，key是一個(gè)HLogKey的實(shí)例。如前一篇文章中提到的， KeyValue不僅包括row，column family, qualifier, timestamp, value, 還包括“Key Type”—派上用場啦， 這里，可以用Key Type代表一個(gè)“put”或“delete”操作。

但是，哪里去存放KeyValue的歸屬信息，比如region或者表名呢？這些存放在HLogKey中。同時(shí)還包括 sequence number，和“寫入時(shí)間”， 是一個(gè)記錄數(shù)據(jù)何時(shí)寫入到log的時(shí)間戳。

LogFlusher

前面提到，數(shù)據(jù)以KeyValue形式到達(dá)HRegionServer，將寫入WAL，之后，寫入一個(gè)SequenceFile?？催^去沒問題，但是因?yàn)閿?shù)據(jù)流在寫入文件系統(tǒng)時(shí)，經(jīng)常會(huì)緩存以提高性能。這樣，有些本以為在日志文件中的數(shù)據(jù)實(shí)際在內(nèi)存中。這里，我們提供了一個(gè)LogFlusher的類。它調(diào)用HLog.optionalSync(),后者根據(jù)“hbase.regionserver.optionallogflushinterval”(默認(rèn)是10秒)，定期調(diào)用Hlog.sync()。另外，HLog.doWrite()也會(huì)根據(jù)“hbase.regionserver.flushlogentries”(默認(rèn)100秒)定期調(diào)用Hlog.sync()。Sync() 本身調(diào)用HLog.Writer.sync()，它由SequenceFileLogWriter實(shí)現(xiàn)。

LogRoller

Log的大小通過$HBASE_HOME/conf/hbase-site.xml 的“hbase.regionserver.logroll.period”限制，默認(rèn)是一個(gè)小時(shí)。所以每60分鐘，會(huì)打開一個(gè)新的log文件。久而久之，會(huì)有一大堆的文件需要維護(hù)。首先，LogRoller調(diào)用HLog.rollWriter()，定時(shí)滾動(dòng)日志，之后，利用HLog.cleanOldLogs()可以清除舊的日志。它首先取得存儲(chǔ)文件中的最大的sequence number，之后檢查是否存在一個(gè)log所有的條目的“sequence number”均低于這個(gè)值，如果存在，將刪除這個(gè)log。

Replay

 當(dāng)HRegionServer啟動(dòng)，打開所管轄的region，它將檢查是否存在剩余的log文件，如果存在，將調(diào)用Store.doReconstructionLog()。重放一個(gè)日志只是簡單地讀入一個(gè)日志，將日志中的條目加入到Memstore中。最后，flush操作將Memstore中數(shù)據(jù)flush到硬盤中。

舊日志往往由region server 崩潰所產(chǎn)生。當(dāng)HMaster啟動(dòng)或者檢測到region server 崩潰，它將日志文件拆分為多份文件，將其存儲(chǔ)在region所屬的文件夾。之后，根據(jù)上面提到的方法，將日志重放。需要指出的是，崩潰的服務(wù)器中的region只有在日志被拆分和拷貝之后才能被重新分配。拆分日志利用HLog.splitLog()。舊日志被讀入主線程內(nèi)存中，之后，利用線程池將其寫入所有的region文件夾中，一個(gè)線程對應(yīng)于一個(gè)region。

問題

1. 為什么要一個(gè)RegionServer 對應(yīng)于一個(gè)HLog。為什么不是一個(gè)region對應(yīng)于一個(gè)log file？

引用BigTable中的一段話，

如果我們每一個(gè)“tablet”（對應(yīng)于HBase的region）都提交一個(gè)日志文件，會(huì)需要并發(fā)寫入大量的文件到GFS，這樣，根據(jù)每個(gè)GFS server所依賴的文件系統(tǒng)，寫入不同的日志文件會(huì)造成大量的磁盤操作。

HBase依照這樣的原則。在日志被回滾和安全刪除之前，將會(huì)有大量的文件。如果改成一個(gè)region對應(yīng)于一個(gè)文件，將會(huì)不好擴(kuò)展，遲早會(huì)引發(fā)問題。

2. 潛在問題

1)      當(dāng)server崩潰，HBase需要將其log切分成合適的片。然而，由于所有的條目混雜在日志中，HMaster只有在將log完全分配到每一個(gè)server后，才能將崩潰server中的region重新分配。這個(gè)時(shí)間可能很長。

2)      數(shù)據(jù)安全。你希望能保存你所有的數(shù)據(jù)，雖然你能將flush的時(shí)間調(diào)到盡可能的低，你依然依賴于上面提到的文件系統(tǒng)。那些用于存儲(chǔ)數(shù)據(jù)依舊有可能沒寫到磁盤而發(fā)生數(shù)據(jù)丟失。

很明顯，需要log來保證數(shù)據(jù)安全。最好是能讓一個(gè)日志保持1個(gè)小時(shí)（或長）的打開狀態(tài)。當(dāng)數(shù)據(jù)來時(shí)，將新的key/value對寫入SequenceFile中，并定期flush數(shù)據(jù)到磁盤中。但是Hadoop不是這樣工作的。他提供了一個(gè)API，允許打開一個(gè)文件，寫入大量的數(shù)據(jù)，然后馬上關(guān)閉文件，成為一個(gè)對其他人只讀的文件。只有當(dāng)文件關(guān)閉時(shí)才是對其他人可讀的。那么，如果一個(gè)進(jìn)程在寫入文件時(shí)僵死，那么，數(shù)據(jù)很可能會(huì)丟失。因此，我們需要一個(gè)功能，能取到一個(gè)離崩潰服務(wù)器寫入數(shù)據(jù)盡可能近的點(diǎn)。

雖然append對于HDFS很有用，但并沒有用在HBase中。HBase用了hflush，它可以在log寫完成后將所有數(shù)據(jù)寫入磁盤。當(dāng)服務(wù)器崩潰，我們可以安全地將“臟”文件讀到最后一次改動(dòng)。Hadoop 0.19.0中，利用Hadoop fsck /可以根據(jù)HBase打開的日志文件數(shù)目報(bào)告DFS的破損程度。

結(jié)論是，在Hadoop 0.21.0之前，你非常容易遇到數(shù)據(jù)丟失。在Hadoop 0.21.0之后，你將得到頂尖的系統(tǒng)（有點(diǎn)吹牛啦，譯者注）。

改善計(jì)劃

在HBase0.21.0中，WAL構(gòu)架會(huì)有相當(dāng)大的改進(jìn)，這里強(qiáng)調(diào)幾點(diǎn)

1. 替換SequenceFile

WAL的核心之一就是存儲(chǔ)格式。SequenceFile有不少問題，最大的性能問題就是所有的寫入都是同步的（HBase-2105）。

在HBase 0.20.0中，HFile替換了MapFile，所以，可以考慮一個(gè)完全的替換。首先要做的是HBase獨(dú)立于底層的文件系統(tǒng)。HBase-2059使log的實(shí)現(xiàn)方式可配。

另一個(gè)想法是完全換一種序列化方式。HBase-2055提出利用Hadoop的Avro作為底層系統(tǒng)。Avro也可能成為Hadoop新的RPC格式，希望有越來越多的人熟悉它。

2. Append/Sync

 頻繁的調(diào)用hflush()會(huì)導(dǎo)致系統(tǒng)變慢。之前的測試發(fā)現(xiàn)，如果每一個(gè)記錄都調(diào)用舊的syncFs()，將大大降低系統(tǒng)的性能。HBase-1939提出一種“組提交”的方法，可以批量flush數(shù)據(jù)。另外，HBase-1944中提出將“延時(shí)flush log”最為一個(gè)Column Family 的參數(shù)。設(shè)為“true”,將同步改動(dòng)到log的工作交給新的LogSyncer類和線程。最后，在HBASE-2041中，將flushlogentries 設(shè)置為1， optinallogflushinterval 設(shè)為1000毫秒。.META.每次改變都會(huì)被同步，用戶表可以根據(jù)需要類配置。

3.分布式日志切分

之前談過，當(dāng)region需要被重新分配時(shí)，切分日志將成為一個(gè)問題。一個(gè)方法就是在zookeeper中維護(hù)一個(gè)regions的列表。這個(gè)方法至少能保證所有“干凈”的region能被快速地分配。剩下那些需要等待日志被切分的條目。

剩下的問題就是如何更快地切分日志。這里，BigTable有如下的描述：

改進(jìn)方案

這就是他的原理。在HMaster rewrite （HBASE-1816）中，也提到了日志拆分。HBASE-1364中，將日志拆分打包成一個(gè)問題。但我覺得會(huì)引入更多的需要討論的細(xì)節(jié)。