最近在網(wǎng)上看到一篇很好的講 HBase 架構(gòu)的文章(原文：https://mapr.com/blog/in-depth-look-hbase-architecture/)，簡潔明了，圖文并茂，所以這里將其翻譯成中文分享。圖片引用的是原文中的，技術(shù)性術(shù)語會盡量使用英文，在比較重要的段落后面都會加上我個人理解的點評。

HBase 架構(gòu)組件

物理上，Hbase 是由三種類型的 server 組成的的主從式(master-slave)架構(gòu)：

• Region Server?負(fù)責(zé)處理數(shù)據(jù)的讀寫請求，客戶端請求數(shù)據(jù)時直接和 Region Server 交互。

• HBase Master?負(fù)責(zé) Region 的分配，DDL(創(chuàng)建，刪除 table)等操作。

• Zookeeper，作為 HDFS 的一部分，負(fù)責(zé)維護(hù)集群狀態(tài)。

當(dāng)然底層的存儲都是基于 Hadoop HDFS 的：

• Hadoop?DataNode?負(fù)責(zé)存儲 Region Server 所管理的數(shù)據(jù)。所有的 HBase 數(shù)據(jù)都存儲在 HDFS 文件中。Region Server 和 HDFS DataNode 往往是分布在一起的，這樣 Region Server 就能夠?qū)崿F(xiàn)數(shù)據(jù)本地化(data locality，即將數(shù)據(jù)放在離需要者盡可能近的地方)。HBase 的數(shù)據(jù)在寫的時候是本地的，但是當(dāng) region 被遷移的時候，數(shù)據(jù)就可能不再滿足本地性了，直到完成?compaction，才能又恢復(fù)到本地。

• Hadoop?NameNode?維護(hù)了所有 HDFS 物理 data block 的元信息。

Regions

HBase?表(Table)根據(jù)?rowkey?的范圍被水平拆分成若干個?region。每個 region 都包含了這個region 的?start key?和?end key?之間的所有行(row)。Regions 被分配給集群中的某些節(jié)點來管理，即?Region Server，由它們來負(fù)責(zé)處理數(shù)據(jù)的讀寫請求。每個 Region Server 大約可以管理 1000 個 regions。

HBase Master

也叫?HMaster，負(fù)責(zé) Region 的分配，DDL(創(chuàng)建，刪除表)等操作：

統(tǒng)籌協(xié)調(diào)所有 region server：

• 啟動時分配 regions，在故障恢復(fù)和負(fù)載均衡時重分配?regions

• 監(jiān)控集群中所有 Region Server 實例(從 Zookeeper 獲取通知信息)

管理員功能：

• 提供創(chuàng)建，刪除和更新 HBase Table 的接口

Zookeeper

HBase 使用 Zookeeper 做分布式管理服務(wù)，來維護(hù)集群中所有服務(wù)的狀態(tài)。Zookeeper 維護(hù)了哪些 servers 是健康可用的，并且在 server 故障時做出通知。Zookeeper 使用一致性協(xié)議來保證分布式狀態(tài)的一致性。注意這需要三臺或者五臺機(jī)器來做一致性協(xié)議。

這些組件是如何一起工作的

Zookeeper 用來協(xié)調(diào)分布式系統(tǒng)中集群狀態(tài)信息的共享。Region Servers 和 在線 HMaster(active HMaster)和 Zookeeper 保持會話(session)。Zookeeper 通過心跳檢測來維護(hù)所有臨時節(jié)點(ephemeral nodes)。

每個 Region Server 都會創(chuàng)建一個 ephemeral 節(jié)點。HMaster 會監(jiān)控這些節(jié)點來發(fā)現(xiàn)可用的 Region Servers，同樣它也會監(jiān)控這些節(jié)點是否出現(xiàn)故障。

HMaster 們會競爭創(chuàng)建 ephemeral 節(jié)點，而 Zookeeper 決定誰是第一個作為在線 HMaster，保證線上只有一個 HMaster。在線 HMaster(active HMaster) 會給 Zookeeper 發(fā)送心跳，不在線的待機(jī) HMaster (inactive HMaster) 會監(jiān)聽 active HMaster 可能出現(xiàn)的故障并隨時準(zhǔn)備上位。

如果有一個 Region Server 或者 HMaster 出現(xiàn)故障或各種原因?qū)е掳l(fā)送心跳失敗，它們與 Zookeeper 的 session 就會過期，這個 ephemeral 節(jié)點就會被刪除下線，監(jiān)聽者們就會收到這個消息。Active HMaster 監(jiān)聽的是 region servers 下線的消息，然后會恢復(fù)故障的 region server 以及它所負(fù)責(zé)的 region 數(shù)據(jù)。而 Inactive HMaster 關(guān)心的則是 active HMaster 下線的消息，然后競爭上線變成 active HMaster。

點評：這一段非常重要，涉及到分布式系統(tǒng)設(shè)計中的一些核心概念，包括集群狀態(tài)、一致性等。可以看到?Zookeeper?是溝通一切的橋梁，所有的參與者都和 Zookeeper 保持心跳會話，并從 Zookeeper 獲取它們需要的集群狀態(tài)信息，來管理其它節(jié)點，轉(zhuǎn)換角色，這也是分布式系統(tǒng)設(shè)計中很重要的思想，由專門的服務(wù)來維護(hù)分布式集群狀態(tài)信息。

第一次讀和寫操作

有一個特殊的 HBase Catalog 表叫?Meta table(它其實是一張?zhí)厥獾?HBase 表)，包含了集群中所有 regions 的位置信息。Zookeeper 保存了這個 Meta table 的位置。

當(dāng) HBase 第一次讀或者寫操作到來時：

• 客戶端從 Zookeeper 那里獲取是哪一臺 Region Server 負(fù)責(zé)管理 Meta table。

• 客戶端會查詢那臺管理 Meta table 的 Region Server，進(jìn)而獲知是哪一臺 Region Server 負(fù)責(zé)管理本次數(shù)據(jù)請求所需要的 rowkey。客戶端會緩存這個信息，以及 Meta table 的位置信息本身。

• 然后客戶端回去訪問那臺 Region Server，獲取數(shù)據(jù)。

對于以后的的讀請求，客戶端可以從緩存中直接獲取 Meta table 的位置信息(在哪一臺 Region Server 上)，以及之前訪問過的 rowkey 的位置信息(哪一臺 Region Server 上)，除非因為 Region 被遷移了導(dǎo)致緩存失效。這時客戶端會重復(fù)上面的步驟，重新獲取相關(guān)位置信息并更新緩存。

點評：客戶端讀寫數(shù)據(jù)，實際上分了兩步：第一步是定位，從 Meta table 獲取 rowkey 屬于哪個 Region Server 管理；第二步再去相應(yīng)的 Region Server 讀寫數(shù)據(jù)。這里涉及到了兩個 Region Server，要理解它們各自的角色功能。關(guān)于 Meta table 下面會詳細(xì)介紹。

HBase Meta Table

Meta table 是一個特殊的 HBase table，它保存了系統(tǒng)中所有的 region 列表。這張 table 類似一個 b-tree，結(jié)構(gòu)大致如下：

• Key：table, region start key, region id

• Value：region server

Region Server 組成

Region Server 運行在 HDFS DataNode 上，由以下組件組成：

• WAL：Write Ahead Log 是分布式文件系統(tǒng)上的一個文件，用于存儲新的還未被持久化存儲的數(shù)據(jù)，它被用來做故障恢復(fù)。

• BlockCache：這是讀緩存，在內(nèi)存中存儲了最常訪問的數(shù)據(jù)，是 LRU(Least Recently Used)緩存。

• MemStore：這是寫緩存，在內(nèi)存中存儲了新的還未被持久化到硬盤的數(shù)據(jù)。當(dāng)被寫入硬盤時，數(shù)據(jù)會首先被排序。注意每個 Region 的每個 Column Family 都會有一個 MemStore。

• HFile?在硬盤上(HDFS)存儲 HBase 數(shù)據(jù)，以有序 KeyValue?的形式。

點評：這一段是重中之重，理解 Region Server 的組成對理解 HBase 的架構(gòu)至關(guān)重要，要充分認(rèn)識 Region Server 的功能，以及每個組件的作用，這些組件的行為和功能在后續(xù)的段落中都會一一展開。

HBase 寫數(shù)據(jù)步驟

當(dāng)客戶端發(fā)起一個寫數(shù)據(jù)請求(Put 操作)，第一步首先是將數(shù)據(jù)寫入到 WAL 中：

• 新數(shù)據(jù)會被追加到 WAL 文件尾部。

• WAL 用來在故障恢復(fù)時恢復(fù)還未被持久化的數(shù)據(jù)。

數(shù)據(jù)被寫入 WAL 后，會被加入到 MemStore 即寫緩存。然后服務(wù)端就可以向客戶端返回 ack 表示寫數(shù)據(jù)完成。

點評：注意數(shù)據(jù)寫入時 WAL 和 MemStore 更新的順序，不能調(diào)換，必須先 WAL 再 MemStore。如果反過來，先更新完 MemStore，此時 Region Server 發(fā)生 crash，內(nèi)存中的更新就丟失了，而此時數(shù)據(jù)還未被持久化到 WAL，就無法恢復(fù)了。理論上 WAL 就是 MemStore 中數(shù)據(jù)的一個鏡像，應(yīng)該保持一致，除非發(fā)生系統(tǒng) crash。另外注意更新 WAL 是在文件尾部追加的方式，這種磁盤操作性能很高，不會太影響請求的整體響應(yīng)時間。

HBase MemStore

MemStore 在內(nèi)存中緩存 HBase 的數(shù)據(jù)更新，以有序 KeyValues 的形式，這和 HFile 中的存儲形式一樣。每個 Column Family 都有一個 MemStore，所有的更新都以 Column Family 為單位進(jìn)行排序。

HBase Region Flush

MemStore 中累積了足夠多的的數(shù)據(jù)后，整個有序數(shù)據(jù)集就會被寫入一個新的 HFile 文件到 HDFS 上。HBase 為每個 Column Family 都創(chuàng)建一個 HFile，里面存儲了具體的?Cell，也即 KeyValue 數(shù)據(jù)。隨著時間推移，HFile 會不斷產(chǎn)生，因為 KeyValue 會不斷地從 MemStore 中被刷寫到硬盤上。

注意這也是為什么 HBase 要限制 Column Family 數(shù)量的一個原因。每個 Column Family 都有一個 MemStore；如果一個 MemStore 滿了，所有的 MemStore 都會被刷寫到硬盤。同時它也會記錄最后寫入的數(shù)據(jù)的最大序列號(sequence number)，這樣系統(tǒng)就能知道目前為止哪些數(shù)據(jù)已經(jīng)被持久化了。

最大序列號是一個 meta 信息，被存儲在每個 HFile 中，來表示持久化進(jìn)行到哪條數(shù)據(jù)了，應(yīng)該從哪里繼續(xù)。當(dāng) region 啟動時，這些序列號會被讀取，取其中最大的一個，作為基礎(chǔ)序列號，后面的新的數(shù)據(jù)更新就會在該值的基礎(chǔ)上遞增產(chǎn)生新的序列號。

點評：這里有個序列號的概念，每次 HBase 數(shù)據(jù)更新都會綁定一個新的自增序列號。而每個 HFile 則會存儲它所保存的數(shù)據(jù)的最大序列號，這個元信息非常重要，它相當(dāng)于一個 commit point，告訴我們在這個序列號之前的數(shù)據(jù)已經(jīng)被持久化到硬盤了。它不僅在 region 啟動時會被用到，在故障恢復(fù)時，也能告訴我們應(yīng)該從 WAL 的什么位置開始回放數(shù)據(jù)的歷史更新記錄。

HBase HFile

數(shù)據(jù)存儲在 HFile 中，以 Key/Value 形式。當(dāng) MemStore 累積了足夠多的數(shù)據(jù)后，整個有序數(shù)據(jù)集就會被寫入一個新的 HFile 文件到 HDFS 上。整個過程是一個順序?qū)懙牟僮?#xff0c;速度非常快，因為它不需要移動磁盤頭。(注意 HDFS 不支持隨機(jī)修改文件操作，但支持 append 操作。)

HBase HFile 文件結(jié)構(gòu)

HFile 使用多層索引來查詢數(shù)據(jù)而不必讀取整個文件，這種多層索引類似于一個 B+ tree：

• KeyValues 有序存儲。

• rowkey 指向 index，而 index 則指向了具體的 data block，以 64 KB 為單位。

• 每個 block 都有它的葉索引。

• 每個 block 的最后一個 key 都被存儲在中間層索引。

• 索引根節(jié)點指向中間層索引。

trailer 指向原信息數(shù)據(jù)塊，它是在數(shù)據(jù)持久化為 HFile 時被寫在 HFile 文件尾部。trailer 還包含例如布隆過濾器和時間范圍等信息。布隆過濾器用來跳過那些不包含指定 rowkey 的文件，時間范圍信息則是根據(jù)時間來過濾，跳過那些不在請求的時間范圍之內(nèi)的文件。

HFile 索引

剛才討論的索引，在 HFile 被打開時會被載入內(nèi)存，這樣數(shù)據(jù)查詢只要一次硬盤查詢。

HBase Read 合并

我們已經(jīng)發(fā)現(xiàn)，每行(row)的 KeyValue cells 可能位于不同的地方，這些 cell 可能被寫入了 HFile，可能是最近剛更新的，還在 MemStore 中，也可能最近剛讀過，緩存在 Block Cache 中。所以，當(dāng)你讀一行 row 時，系統(tǒng)怎么將對應(yīng)的 cells 返回呢？一次 read 操作會將 Block Cache，MemStore 和 HFile 中的 cell 進(jìn)行合并：

• 首先 scanner 從 Block Cache 讀取 cells。最近讀取的 KeyValue 都被緩存在這里，這是 一個 LRU 緩存。

• 然后 scanner 讀取 MemStore，即寫緩存，包含了最近更新的數(shù)據(jù)。

• 如果 scanner 沒有在 BlockCache 和 MemStore 都沒找到對應(yīng)的 cells，則 HBase 會使用 Block Cache 中的索引和布隆過濾器來加載對應(yīng)的 HFile 到內(nèi)存，查找到請求的 row cells。

之前討論過，每個 MemStore 可能會有多個 HFile，所以一次 read 請求可能需要多讀個文件，這可能會影響性能，這被稱為讀放大(read amplification)。

點評：從時間軸上看，一個個的 HFile 也是有序的，本質(zhì)上它們保存了每個 region 的每個 column family 的數(shù)據(jù)歷史更新。所以對于同一個 rowkey 的同一個 cell，它可能也有多個版本的數(shù)據(jù)分布在不同的 HFile 中，所以可能需要讀取多個 HFiles，這樣性能開銷會比較大，尤其是當(dāng)不滿足 data locality 時這種 read amplification 情況會更加嚴(yán)重。這也是后面會講到的?compaction?必要的原因。

HBase Minor Compaction

HBase 會自動合并一些小的 HFile，重寫成少量更大的 HFiles。這個過程被稱為?minor compaction。它使用歸并排序算法，將小文件合并成大文件，有效減少 HFile 的數(shù)量。

HBase Major Compaction

Major Compaction?合并重寫每個 Column Family 下的所有的 HFiles，成為一個單獨的大 HFile，在這個過程中，被刪除的和過期的 cell 會被真正從物理上刪除，這能提高讀的性能。但是因為 major compaction 會重寫所有的 HFile，會產(chǎn)生大量的硬盤 I/O 和網(wǎng)絡(luò)開銷。這被稱為寫放大(Write Amplification)。

Major compaction 可以被設(shè)定為自動調(diào)度。因為存在 write amplification 的問題，major compaction 一般都安排在周末和半夜。MapR 數(shù)據(jù)庫對此做出了改進(jìn)，并不需要做 compaction。Major compaction 還能將因為服務(wù)器 crash 或者負(fù)載均衡導(dǎo)致的數(shù)據(jù)遷移重新移回到離 Region Server 的地方，這樣就能恢復(fù)?data locality。

Region = Contiguous Keys

我們再來回顧一下 region 的概念：

• HBase Table 被水平切分成一個或數(shù)個 regions。每個 region 包含了連續(xù)的，有序的一段 rows，以 start key 和 end key 為邊界。

• 每個 region 的默認(rèn)大小為 1GB。

• region 里的數(shù)據(jù)由 Region Server 負(fù)責(zé)讀寫，和 client 交互。

• 每個 Region Server 可以管理約 1000 個 regions(它們可能來自一張表或者多張表)。

Region 分裂

一開始每個 table 默認(rèn)只有一個 region。當(dāng)一個 region 逐漸變得很大時，它會分裂(split)成兩個子 region，每個子 region 都包含了原來 region 一半的數(shù)據(jù)，這兩個子 region 并行地在原來這個 region server 上創(chuàng)建，這個分裂動作會被報告給 HMaster。處于負(fù)載均衡的目的，HMaster 可能會將新的 region 遷移給其它 region server。

Read 負(fù)載均衡

Splitting?一開始是發(fā)生在同一臺 region server 上的，但是出于負(fù)載均衡的原因，HMaster 可能會將新的 regions?遷移給它 region server，這會導(dǎo)致那些 region server 需要訪問離它比較遠(yuǎn)的 HDFS 數(shù)據(jù)，直到?major compaction?的到來，它會將那些遠(yuǎn)方的數(shù)據(jù)重新移回到離 region server 節(jié)點附近的地方。

點評：注意這里的遷移的概念，只是邏輯上的遷移，即將某個 region 交給另一個 region server 管理。

HDFS數(shù)據(jù)備份

所有的讀寫都發(fā)生在 HDFS 的主 DataNode 節(jié)點上。HDFS 會自動備份 WAL 和 HFile 的文件 blocks。HBase 依賴于 HDFS 來保證數(shù)據(jù)完整安全。當(dāng)數(shù)據(jù)被寫入 HDFS 時，一份會寫入本地節(jié)點，另外兩個備份會被寫入其它節(jié)點。

WAL 和 HFiles 都會持久化到硬盤并備份。那么 HBase 是怎么恢復(fù) MemStore 中還未被持久化到 HFile 的數(shù)據(jù)呢？下面的章節(jié)會討論這個問題。

HBase 故障恢復(fù)

當(dāng)某個 Region Server 發(fā)生 crash 時，它所管理的 region 就無法被訪問了，直到 crash 被檢測到，然后故障恢復(fù)完成，這些 region 才能恢復(fù)訪問。Zookeeper 依靠心跳檢測發(fā)現(xiàn)節(jié)點故障，然后 HMaster 會收到 region server 故障的通知。

當(dāng) HMaster 發(fā)現(xiàn)某個 region server 故障，HMaster 會將這個 region server 所管理的 regions 分配給其它健康的 region servers。為了恢復(fù)故障的 region server 的 MemStore 中還未被持久化到 HFile 的數(shù)據(jù)，HMaster 會將 WAL 分割成幾個文件，將它們保存在新的 region server 上。每個 region server 然后回放各自拿到的 WAL 碎片中的數(shù)據(jù)，來為它所分配到的新 region 建立 MemStore。

WAL 包含了一系列的修改操作，每個修改都表示一個 put 或者 delete 操作。這些修改按照時間順序依次寫入，持久化時它們被依次寫入 WAL 文件的尾部。

當(dāng)數(shù)據(jù)仍然在 MemStore 還未被持久化到 HFile 怎么辦呢？WAL 文件會被回放。操作的方法是讀取 WAL 文件，排序并添加所有的修改記錄到 MemStore，最后 MemStore 會被刷寫到 HFile。

點評：故障恢復(fù)是 HBase 可靠性保障的一個重要特性。WAL 在這里扮演了關(guān)鍵角色，在分割 WAL 時，數(shù)據(jù)會根據(jù) region 分配到對應(yīng)的新的 region server 上，然后 region server 負(fù)責(zé)回放這一部分?jǐn)?shù)據(jù)到 MemStore 中。

Apache HBase 架構(gòu)的優(yōu)點

• 強(qiáng)一致性：當(dāng) write 返回時，所有的 reader 都會讀到同樣的值。

• 自動擴(kuò)展性：數(shù)據(jù)變大時 region 會分裂。使用 HDFS 存儲備份數(shù)據(jù)。

• 內(nèi)置恢復(fù)功能：使用?Write?Ahead?Log?(類似于文件系統(tǒng)中的日志)

• 與 Hadoop 結(jié)合：使用 MapReduce 處理 HBase 數(shù)據(jù)會非常直觀。

Apache HBase 也有問題

• WAL 回放很慢。

• 故障恢復(fù)很慢。

• Major Compaction 時候 I/O 會飆升。

轉(zhuǎn)載自：https://segmentfault.com/a/1190000019959411

總結(jié)

以上是生活随笔為你收集整理的hbase 客户端_全网最细致的 HBase 内核解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。