作者 |?阿丸筆記

?責編 | 徐威龍

封圖|?CSDN 下載于視覺中國

在網上看過很多HBaes架構相關的文章，內容深淺不一，直到發現了一篇MapR官網的文章，寫得實在太生動了。

https://mapr.com/blog/in-depth-look-hbase-architecture/#.VdMxvWSqqko，

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

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的相關信息

深入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的序列號，然后最大的序列號會被用來作為新的起始序列號。

深入HFile

3.1 HFile的寫入

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

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

HFile的邏輯結構如圖：

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

• Scanned block p：表示掃描HFile時，這部分所有數據塊都會被讀取，包括Leaf Index Block和Bloom Block。

• Non-scanned block p：表示在掃描HFile時不會被讀取，主要包括Meta Block和Intermediate Level Data Index Blocks兩部分。

• Load-on-open-p：表示在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。

推薦閱讀：2020 年最新版 68 道Redis面試題，20000 字干貨，趕緊收藏起來備用！ 我最喜歡的云 IDE 推薦！ 應聘蘋果數據科學家，你需要知道些什么？ 最近一個名為 BTCU 的比特幣分叉，準備用新分叉解決比特幣網絡的舊問題 Soul App 高管被捕，惡意舉報導致競品被下架 2.2版本發布！TensorFlow推出開發者技能證書 真香，朕在看了！

總結

以上是生活随笔為你收集整理的从零单排HBase 02：全面认识HBase架构（建议收藏）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。