HBase的構成

物理上來說，HBase是由三種類型的服務器以主從模式構成的。這三種服務器分別是：Region server，HBase HMaster，ZooKeeper。

其中Region server負責數據的讀寫服務。用戶通過溝通Region server來實現對數據的訪問。

HBase HMaster負責Region的分配及數據庫的創建和刪除等操作。

ZooKeeper作為HDFS的一部分，負責維護集群的狀態(某臺服務器是否在線，服務器之間數據的同步操作及master的選舉等)。

另外，Hadoop DataNode負責存儲所有Region Server所管理的數據。HBase中的所有數據都是以HDFS文件的形式存儲的。出于使Region server所管理的數據更加本地化的考慮，Region server是根據DataNode分布的。HBase的數據在寫入的時候都存儲在本地。但當某一個region被移除或被重新分配的時候，就可能產生數據不在本地的情況。這種情況只有在所謂的compaction之后才能解決。

NameNode負責維護構成文件的所有物理數據塊的元信息(metadata)。

HBase結構如下圖所示：

 

Regions

HBase中的表是根據row key的值水平分割成所謂的region的。一個region包含表中所有row key位于region的起始鍵值和結束鍵值之間的行。集群中負責管理Region的結點叫做Region server。Region server負責數據的讀寫。每一個Region server大約可以管理1000個region。Region的結構如下圖所示：

 

HBase的HMaster

HMaster負責region的分配，數據庫的創建和刪除操作。

具體來說，HMaster的職責包括：

• 調控Region server的工作
• 在集群啟動的時候分配region，根據恢復服務或者負載均衡的需要重新分配region。
• 監控集群中的Region server的工作狀態。(通過監聽zookeeper對于ephemeral node狀態的通知)。
• 管理數據庫
• 提供創建，刪除或者更新表格的接口。

HMaster的工作如下圖所示：

 

ZooKeeper

HBase利用ZooKeeper維護集群中服務器的狀態并協調分布式系統的工作。ZooKeeper維護服務器是否存活，是否可訪問的狀態并提供服務器故障/宕機的通知。ZooKeeper同時還使用一致性算法來保證服務器之間的同步。同時也負責Master選舉的工作。需要注意的是要保證良好的一致性及順利的Master選舉，集群中的服務器數目必須是奇數。例如三臺或五臺。

ZooKeeper的工作如下圖所示：

 

HBase各組成部分之間的合作

ZooKeeper用來協調分布式系統的成員之間共享的狀態信息。Region Server及HMaster也與ZooKeeper連接。ZooKeeper通過心跳信息為活躍的連接維持相應的ephemeral node。如下圖所示：

 

每一個Region server都在ZooKeeper中創建相應的ephemeral node。HMaster通過監控這些ephemeral node的狀態來發現正常工作的或發生故障下線的Region server。HMaster之間通過互相競爭創建ephemeral node進行Master選舉。ZooKeeper會選出區中***個創建成功的作為唯一一個活躍的HMaster?；钴S的HMaster向ZooKeeper發送心跳信息來表明自己在線的狀態。不活躍的HMaster則監聽活躍HMaster的狀態，并在活躍HMaster發生故障下線之后重新選舉，從而實現了HBase的高可用性。

如果Region server或者HMaster不能成功向ZooKeeper發送心跳信息，則其與ZooKeeper的連接超時之后與之相應的ephemeral node就會被刪除。監聽ZooKeeper狀態的其他節點就會得到相應node不存在的信息，從而進行相應的處理?；钴S的HMaster監聽Region Server的信息，并在其下線后重新分配Region server來恢復相應的服務。不活躍的HMaster監聽活躍HMaster的信息，并在起下線后重新選出活躍的HMaster進行服務。

HBase的***次讀寫

HBase中有一個特殊的起目錄作用的表格，稱為META table。META table中保存集群region的地址信息。ZooKeeper中會保存META table的位置。

當用戶***次想HBase中進行讀或寫操作時，以下步驟將被執行：

• 客戶從ZooKeeper中得到保存META table的Region server的信息。
• 客戶向該Region server查詢負責管理自己想要訪問的row key的所在的region的Region server的地址?？蛻魰彺孢@一信息以及META table所在位置的信息。
• 客戶與負責其row所在region的Region Server通信，實現對該行的讀寫操作。

在未來的讀寫操作中，客戶會根據緩存尋找相應的Region server地址。除非該Region server不再可達。這時客戶會重新訪問META table并更新緩存。這一過程如下圖所示：

 

HBase的META table

• META table中保存了HBase中所有region的信息。
• META table的格式類似于B tree。
• META table的結構如下：
• 鍵：region的起始鍵，region id。
• 值：Region server

如下圖所示：

 

Region Server的組成

運行在HDFS DataNode上的Region server包含如下幾個部分：

• WAL：既Write Ahead Log。WAL是HDFS分布式文件系統中的一個文件。WAL用來存儲尚未寫入***性存儲區中的新數據。WAL也用來在服務器發生故障時進行數據恢復。
• Block Cache：Block cache是讀緩存。Block cache將經常被讀的數據存儲在內存中來提高讀取數據的效率。當Block cache的空間被占滿后，其中被讀取頻率***的數據將會被殺出。
• MemStore：MemStore是寫緩存。其中存儲了從WAL中寫入但尚未寫入硬盤的數據。MemStore中的數據在寫入硬盤之前會先進行排序操作。每一個region中的每一個column family對應一個MemStore。
• Hfiles：Hfiles存在于硬盤上，根據排序號的鍵存儲數據行。

Region server的結構如下圖所示：

 

HBase的寫操作步驟

步驟一

當HBase的用戶發出一個PUT請求時(也就是HBase的寫請求)，HBase進行處理的***步是將數據寫入HBase的write-ahead log(WAL)中。

• WAL文件是順序寫入的，也就是所有新添加的數據都被加入WAL文件的末尾。WAL文件存在硬盤上。
• 當server出現問題之后，WAL可以被用來恢復尚未寫入HBase中的數據(因為WAL是保存在硬盤上的)。

如下圖所示：

 

步驟二

當數據被成功寫入WAL后，HBase將數據存入MemStore。這時HBase就會通知用戶PUT操作已經成功了。

過程如下圖所示：

 

HBase的MemStore

Memstore存在于內存中，其中存儲的是按鍵排好序的待寫入硬盤的數據。數據也是按鍵排好序寫入HFile中的。每一個Region中的每一個Column family對應一個Memstore文件。因此對數據的更新也是對應于每一個Column family。

如下圖所示：

 

HBase Region Flush

當MemStore中積累了足夠多的數據之后，整個Memcache中的數據會被一次性寫入到HDFS里的一個新的HFile中。因此HDFS中一個Column family可能對應多個HFile。這個HFile中包含了相應的cell，或者說鍵值的實例。這些文件隨著MemStore中積累的對數據的操作被flush到硬盤上而創建。

需要注意的是，MemStore存儲在內存中，這也是為什么HBase中Column family的數目有限制的原因。每一個Column family對應一個MemStore，當MemStore存滿之后，里面所積累的數據就會一次性flush到硬盤上。同時，為了使HDFS能夠知道當前哪些數據已經被存儲了，MemStore中還保存***一次寫操作的序號。

每個HFile中***的序號作為meta field存儲在其中，這個序號標明了之前的數據向硬盤存儲的終止點和接下來繼續存儲的開始點。當一個region啟動的時候，它會讀取每一個HFile中的序號來得知當前region中***的操作序號是什么(***的序號)。

如下圖所示：

 

HFile

HBase中的鍵值數據對存儲在HFile中。上面已經說過，當MemStore中積累足夠多的數據的時候就會將其中的數據整個寫入到HDFS中的一個新的HFile中。因為MemStore中的數據已經按照鍵排好序，所以這是一個順序寫的過程。由于順序寫操作避免了磁盤大量尋址的過程，所以這一操作非常高效。

如下圖所示：

 

HFile的結構

HFile中包含了一個多層索引系統。這個多層索引是的HBase可以在不讀取整個文件的情況下查找數據。這一多層索引類似于一個B+樹。

• 鍵值對根據鍵大小升序排列。
• 索引指向64KB大小的數據塊。
• 每一個數據塊還有其相應的葉索引(leaf-index)。
• 每一個數據塊的***一個鍵作為中間索引(intermediate index)。
• 根索引(root index)指向中間索引。

文件結尾指向meta block。因為meta block是在數據寫入硬盤操作的結尾寫入該文件中的。文件的結尾同時還包含一些別的信息。比如bloom filter及時間信息。Bloom filter可以幫助HBase加速數據查詢的速度。因為HBase可以利用Bloom filter跳過不包含當前查詢的鍵的文件。時間信息則可以幫助HBase在查詢時跳過讀操作所期望的時間區域之外的文件。

如下圖所示：

 

HFile的索引

HFile的索引在HFile被打開時會被讀取到內存中。這樣就可以保證數據檢索只需一次硬盤查詢操作。

如下圖所示：

 

HBase的讀合并(Read Merge)以及讀放大(Read amplification)

通過上面的論述，我們已經知道了HBase中對應于某一行數據的cell可能位于多個不同的文件或存儲介質中。比如已經存入硬盤的行位于硬盤上的HFile中，新加入或更新的數據位于內存中的MemStore中，最近讀取過的數據則位于內存中的Block cache中。所以當我們讀取某一行的時候，為了返回相應的行數據，HBase需要根據Block cache，MemStore以及硬盤上的HFile中的數據進行所謂的讀合并操作。

• HBase會首先從Block cache(HBase的讀緩存)中尋找所需的數據。
• 接下來，HBase會從MemStore中尋找數據。因為作為HBase的寫緩存，MemStore中包含了***版本的數據。
• 如果HBase從Block cache和MemStore中沒有找到行所對應的cell所有的數據，系統會接著根據索引和bloom filter從相應的HFile中讀取目標行的cell的數據。

如下圖所示：

 

這里一個需要注意的地方是所謂的讀放大效應(Read amplification)。根據前文所說，一個MemStore對應的數據可能存儲于多個不同的HFile中(由于多次的flush)，因此在進行讀操作的時候，HBase可能需要讀取多個HFile來獲取想要的數據。這會影響HBase的性能表現。

如下圖所示：

 

HBase的Compaction

Minor Compaction

HBase會自動選取一些較小的HFile進行合并，并將結果寫入幾個較大的HFile中。這一過程稱為Minor compaction。Minor compaction通過Merge sort的形式將較小的文件合并為較大的文件，從而減少了存儲的HFile的數量，提升HBase的性能。

這一過程如下圖所示：

 

Major Compaction

所謂Major Compaction指的是HBase將對應于某一個Column family的所有HFile重新整理并合并為一個HFile，并在這一過程中刪除已經刪除或過期的cell，更新現有cell的值。這一操作大大提升讀的效率。但是因為Major compaction需要重新整理所有的HFile并寫入一個HFile，這一過程包含大量的硬盤I/O操作以及網絡數據通信。這一過程也稱為寫放大(Write amplification)。在Major compaction進行的過程中，當前Region基本是處于不可訪問的狀態。

Major compaction可以配置在規定的時間自動運行。為避免影響業務，Major compaction一般安排在夜間或周末進行。

需要注意的一點事，Major compaction會將當前Region所服務的所有遠程數據下載到本地Region server上。這些遠程數據可能由于服務器故障或者負載均衡等原因而存儲在于遠端服務器上。

這一過程如下圖所示：

 

Region的分割(Region split)

首先我們快速復習一下Region：

• HBase中的表格可以根據行鍵水平分割為一個或幾個region。每個region中包含了一段處于某一起始鍵值和終止鍵值之間的連續的行鍵。
• 每一個region的默認大小為1GB。
• 相應的Region server負責向客戶提供訪問某一region中的數據的服務。
• 每一個Region server能夠管理大約1000個region(這些region可能來自同一個表格，也可能來自不同的表格)。

如下圖所示：

 

每一個表格最初都對應于一個region。隨著region中數據量的增加，region會被分割成兩個子region。每一個子region中存儲原來一半的數據。同時Region server會通知HMaster這一分割。出于負載均衡的原因，HMaster可能會將新產生的region分配給其他的Region server管理(這也就導致了Region server服務遠端數據的情況的產生)。

如下圖所示：

 

讀操作的負載均衡(Read Load Balancing)

Region的分割最初是在Region server本地發生的。但是出于負載均衡的原因，HMaster可能會將新產生的region分配給其他的Region server進行管理。這也就導致了Region server管理存儲在遠端服務器上的region情況的產生。這一情況會持續至下一次Major compaction之前。如上文所示，Major compaction會將任何不在本地的數據下載至本地。

也就是說，HBase中的數據在寫入時總是存儲在本地的。但是隨著region的重新分配(由于負載均衡或數據恢復)，數據相對于Region server不再一定是本地的。這種情況會在Major compaction后得到解決。

如下圖所示：

 

HDFS的數據備份(Data Replication)

HDFS中所有的數據讀寫操作都是針對主節點進行的。HDFS會自動備份WAL和HFile。HBase以來HDFS來提供可靠的安全的數據存儲。當數據被寫入HDFS本地時，另外兩份備份數據會分別存儲在另外兩臺服務器上。

如下圖所示：

 

HBase的異常恢復(Crash Recovery)

WAL文件和HFile都存儲于硬盤上且存在備份，因此恢復它們是非常容易的。那么HBase如何恢復位于內存中的MemStore呢?

 

當Region server宕機的時候，其所管理的region在這一故障被發現并修復之前是不可訪問的。ZooKeeper負責根據服務器的心跳信息來監控服務器的工作狀態。當某一服務器下線之后，ZooKeeper會發送該服務器下線的通知。HMaster收到這一通知之后會進行恢復操作。

HMaster會首先將宕機的Region server所管理的region分配給其他仍在工作的活躍的Region server。然后HMaster會將該服務器的WAL分割并分別分配給相應的新分配的Region server進行存儲。新的Region server會讀取并順序執行WAL中的數據操作，從而重新創建相應的MemStore。

如下圖所示：

 

數據恢復(Data Recovery)

WAL文件之中存儲了一系列數據操作。每一個操作對應WAL中的一行。新的操作會順序寫在WAL文件的末尾。

那么當MemStore中存儲的數據因為某種原因丟失之后應該如何恢復呢?HBase以來WAL對其進行恢復。相應的Region server會順序讀取WAL并執行其中的操作。這些數據被存入內存中當前的MemStore并排序。最終當MemStore存滿之后，這些數據被flush到硬盤上。

如下圖所示：

 

Apache HBase的優缺點

優點

• 強一致性模型
• 當一個寫操作得到確認時，所有的用戶都將讀到同一個值。
• 可靠的自動擴展
• 當region中的數據太多時會自動分割。
• 使用HDFS分布存儲并備份數據。
• 內置的恢復功能
• 使用WAL進行數據恢復。
• 與Hadoop集成良好
• MapReduce在HBase上非常直觀。

缺點

• WAL回復較慢。
• 異?；謴蛷碗s且低效。
• 需要進行占用大量資源和大量I/O操作的Major compaction。