从零单排HBase 02：全面认识HBase架构（建议收藏）
作者 |?阿丸筆記
?責編 | 徐威龍
封圖|?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架构（建议收藏）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里云宣布3年再投2000亿
- 下一篇： 我是如何用6个月，从0编程经验变成数据科