【從零單排HBase 02】全面認識HBase架構（建議收藏）

在網上看過很多HBaes架構相關的文章，內容深淺不一，直到發現了一篇MapR官網的文章https://mapr.com/blog/in-depth-look-hbase-architecture/#.VdMxvWSqqko，寫得實在太sheng dong了。

因此，以這篇文章作爲骨架，翻譯了許多原文的內容，同時對一些細節進行自己的擴展，形成本文。

1.HBase架構組成

從物理結構上，HBase包含了三種類型的server，zookeeper、HMaster、region server，採用一種主從模式的結構。

• region server主要用來服務讀和寫操作。當用戶通過client訪問數據時，client會和HBase RegionServer 進行直接通信。
• HMaster主要進行region server的管理、DDL（創建、刪除表）操作等。
• Zookeeper是HDFS（Hadoop Distributed File System）的一部分，主要用來維持整個集羣的存活，保障了HA，故障自動轉移。

而底層的存儲，還是依賴於HDFS的。

• Hadoop的DataNode存儲了Region Server所管理的數據，所有HBase的數據都是存在HDFS中的。
• Hadoop的NameNode維護了所有物理數據塊的metadata。

1.1 region server

HBase 的tables根據rowkey的範圍進行水平切分，切分後分配到各個regions。一個region包含一個表在start key和end key所有行。region會被分配到集羣中的各個region server，而用戶都是跟region server進行讀寫交互。一個region一般建議大小在5-10G。

1.2 HBase HMaster

一般也叫作HMaster，HMaster主要職責包括兩個方面：

• 與region server的交互，對region server進行統一管理：
• 啓動時region的分配 崩潰後恢復的region重新分配 負載均衡的region重新分配
• Admin相關功能：
• 創建、刪除、更新表結構等DDL操作
  

1.3 Zookeeper

HBase使用Zookeeper作爲分佈式協調服務，來維護集羣內的server狀態。

Zookeeper通過 heartbeat 維護了哪些server是存活並可用的，並提供server的故障通知。同時，使用一致性協議來保證各個分佈式節點的一致性。

這裏，需要特別關注，zookeeper負責來HMaster的選舉工作，如果一個HMater節點宕機了，就會選擇另一個HMaster節點進入active狀態。

1.4 這些組件如何一起協調工作

Zookeeper用來共享分佈式系統中成員的狀態，它會和region server、HMaster（active）保持會話，通過heartbeat維持與這些ephemeral node（zk中的臨時節點概念）的活躍會話。

下面，我們可以看到，zk在其中起到了最核心的作用。

多個HMaster會去競爭成爲zookeeper上的臨時節點，而zookeeper會將第一個創建成功的HMaster作爲唯一當前active的HMaster，其他HMater進入stand by的狀態。這個active的HMaster會不斷髮送heartbeat給zk，其他stand by狀態的HMaster節點會監聽這個active HMaster的故障信息。一旦發現active HMaster宕機了，就會重新競爭新的active HMaster。這就實現了HMaster的高可用。

每個region server會創建一個ephemeral node。HMaster會監視這些節點來確認哪些region server是可用的，哪些節點發生了故障宕機了。

如果一個region server或者active的HMaster 沒有發送heatbeat給zk，那麼和zk之間的會話將會過期，並且zk上會刪掉這個臨時節點，認爲這個節點發生故障需要下線了。

其他監聽者節點會收到這個故障節點被刪除的消息。比如actvie的HMaster會監聽region server的消息，如果發現某個region server下線了，那麼就會重新分配region server來恢復相應的region數據。再比如，stand by的HMaster節點會監聽active 的HMaster節點，一旦收到故障通知，就會競爭上線成爲新的active HMaster。

1.5 第一次訪問HBase

有一個特殊的HBase目錄表，叫做META table，保存了集羣中各個region的位置。zookeeper中保存了這個meta table 的位置信息。

當我們第一次訪問HBase集羣時，會做以下操作：

1）客戶端從zk中獲取保存meta table的位置信息，知道meta table保存在了哪個region server，並在客戶端緩存這個位置信息；

2）client會查詢這個保存meta table的特定的region server，查詢meta table信息，在table中獲取自己想要訪問的row key所在的region在哪個region server上。

3）客戶端直接訪問目標region server，獲取對應的row

進一步，我們瞭解一下meta table的存儲結構。

• Meta table保存了所有region信息的一張表
• Meta table存儲的數據形式類似一顆b樹
• 以keyvalue形式保存數據
• Key: region的table name, start key等信息 Values: region server的相關信息
  

2.深入region server

一個region server運行在一個HDFS的data node上，並且擁有以下組件：

• WAL：全稱Write Ahead Log， 屬於分佈式系統上的文件。主要用來存儲還未被持久化到磁盤的新數據。如果新數據還未持久化，節點發生宕機，那麼就可以用WAL來恢復這些數據。
• BlockCache：是一個讀緩存。它存儲了被高頻訪問的數據。當這個緩存滿了後，會清除最近最少訪問的數據。
• MenStore: 是一個寫緩存。它存儲了還未被寫入磁盤的數據。它會在寫入磁盤前，對自身數據進行排序，從而保證數據的順序寫入。每個region的每個colum family會有一份對應的memstore。（沒錯，如果節點宕機了，存在這個緩存裏的數據沒有落盤，可以通過WAL保證這些數據不會丟失）
• HFiles：按照字典序存儲各個row的鍵值。

2.1 HBase寫數據與region server的交互

整個寫的過程更加複雜，而與region server的交互式最重要的一部分，這裏只介紹跟region server的交互。

主要分爲兩個步驟，寫WAL 和 寫緩存。

“實際上，這裏除了保證數據不丟，還跟提高寫入效率有關，具體後續專門寫一個相關文檔進行展開說明”

1）寫WAL

當客戶端提交了一個put 請求，那麼在region server上需要首先寫WAL(write-ahead-log)。

需要注意三點

• Hlog是一個region server上一個，並不是一個region一個
• 寫入數據是添加在log尾部
• log上的數據主要爲了保證沒有落盤的數據能在server崩潰後不丟失
  

2）寫緩存

數據寫入WAL成功，纔會繼續寫入MemStore。

然後纔會返回ack給客戶端，表示寫入成功了。

2.2 HBase MemStroe

MemStore主要保存數據更新在內存中，以字典序的KeyValue形式，跟HFile裏面保存的一樣。

每一個column family會有一個對應的memstore

更新的數據會在memstore中以key-value形式排好序存儲，注意看圖，按字典序排，同時按version的倒序排列。

我們可以看到，key的組成包括rowkey-cf-col-version。

2.3 HBase region flush

當MemStore存儲了足夠多的數據，整個有序集會被寫入一個新的HFile文件中，保存在HDFS。

HBase中每個colum family會有多個HFile，用來存儲實際的keyValue。

注意，這裏解釋了爲什麼HBase中columfaily的數量是有限制的（具體是多少？）。

每一個cf有一個對應的MemStore，當一個MemStore滿了，所屬region的所有memstore都會被flush到磁盤。所以MemStore的flush的最小單位是一個region，而不是一個MemStore。

flush的同時，它還會存儲一些額外的信息，比如最後一個寫的序列號，讓系統知道它當前持久化到什麼位置了。

最大的序列號作爲元數據，會被存儲在每個HFile中，表示持久化到哪個位置了，下一次持久化應該從哪裏繼續。一個region啓動時，會讀取每個HFile的序列號，然後最大的序列號會被用來作爲新的起始序列號。

3. 深入HFile

3.1 HFile的寫入

HBase中，數據以有序KV的形式，存儲在HFile中。當MemStore存儲了足夠的數據，全部kv對被寫入HFile存入HDFS。

這裏寫文件的過程是順序寫，避免了硬盤大量移動磁頭的過程，比隨機寫高效很多。

HFile的邏輯結構如圖

主要分爲四個部分：Scanned block section，Non-scanned block section，Opening-time data section和Trailer。

• Scanned block section：表示掃描HFile時，這部分所有數據塊都會被讀取，包括Leaf Index Block和Bloom Block。
• Non-scanned block section：表示在掃描HFile時不會被讀取，主要包括Meta Block和Intermediate Level Data Index Blocks兩部分。
• Load-on-open-section：表示在HBase的region server啓動時，會被加載到內存中。包括FileInfo、Bloom filter block、data block index和meta block index。
• Trailer：表示HFile的基本信息、各個部分的偏移值和尋址信息。

文件中採用類似b+樹都多層索引：

• Kv對按遞增順序存儲；
• Root index指向非葉子結點
• 每個數據塊的最後一個key被放入中間索引(b+樹的非葉子結點)
• 每個數據塊有自己的葉子索引（b+樹的葉子結點）
• 葉子索引通過row key指向64kb的kv數據塊

文件的末尾有個trailer節點，指向了meta block。trailer節點還擁有其他信息，比如布隆過濾器和時間範圍信息。

布隆過濾器幫助我們過濾那些不包含在這個HFilfe中的rowkey。

時間範圍信息用來跳過那些不在這個HFilie時間範圍內的row。

因此，當一個HFile被讀取後，HFile的索引信息就會被緩存在BlockCache中，這樣使得查詢只需要一次磁盤查詢操作，後續查找只需要讀取blockcache內的索引信息即可。

region server上的實體結構關係如下：

regionserver : region = 1 : n，每個region server上有多個region。

region : store= 1 ： n，每個region裏面有多個store

store : memstore = 1 : 1。

Memstore:Hfile = 1:n。

看到這裏了，原創不易，點個贊吧，你最好看了～

知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph （歷史文章查閱非常方便）