依然是Hadoop組件的講解，今天說到HBase 架構，都是一字一句打出來的，希望各位轉發加關注，會一直給大家寫優質的內容。

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

• Region Server，負責處理數據的讀寫請求，客戶端請求數據時直接和 Region Server 交互。
• HBase Master，負責 Region 的分配，DDL(創建，刪除 table)等操作。
• Zookeeper，作為 HDFS 的一部分，負責維護集群狀態。

當然底層的存儲都是基于 Hadoop HDFS 的：

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

Hadoop NameNode 維護了所有 HDFS 物理 data block 的元信息。 

Regions

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

HBase Master

也叫 HMaster，負責 Region 的分配，DDL(創建，刪除表)等操作：

統籌協調所有 region server：

• 啟動時分配 regions，在故障恢復和負載均衡時重分配 regions
• 監控集群中所有 Region Server 實例(從 Zookeeper 獲取通知信息)

管理員功能：

• 提供創建，刪除和更新 HBase Table 的接口 

Zookeeper

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

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

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

每個 Region Server 都會創建一個 ephemeral 節點。HMaster 會監控這些節點來發現可用的 Region Servers，同樣它也會監控這些節點是否出現故障。

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

如果有一個 Region Server 或者 HMaster 出現故障或各種原因導致發送心跳失敗，它們與 Zookeeper 的 session 就會過期，這個 ephemeral 節點就會被刪除下線，監聽者們就會收到這個消息。Active HMaster 監聽的是 region servers 下線的消息，然后會恢復故障的 region server 以及它所負責的 region 數據。而 Inactive HMaster 關心的則是 active HMaster 下線的消息，然后競爭上線變成 active HMaster。

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

第一次讀和寫操作

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

當 HBase 第一次讀或者寫操作到來時：

• 客戶端從 Zookeeper 那里獲取是哪一臺 Region Server 負責管理 Meta table。
• 客戶端會查詢那臺管理 Meta table 的 Region Server，進而獲知是哪一臺 Region Server 負責管理本次數據請求所需要的 rowkey。客戶端會緩存這個信息，以及 Meta table 的位置信息本身。
• 然后客戶端回去訪問那臺 Region Server，獲取數據。

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

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

HBase Meta Table

Meta table 是一個特殊的 HBase table，它保存了系統中所有的 region 列表。這張 table 類似一個 b-tree，結構大致如下：

• Key：table, region start key, region id
• Value：region server 

Region Server 組成

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

• WAL：Write Ahead Log 是分布式文件系統上的一個文件，用于存儲新的還未被持久化存儲的數據，它被用來做故障恢復。
• BlockCache：這是讀緩存，在內存中存儲了最常訪問的數據，是 LRU(Least Recently Used)緩存。
• MemStore：這是寫緩存，在內存中存儲了新的還未被持久化到硬盤的數據。當被寫入硬盤時，數據會首先被排序。注意每個 Region 的每個 Column Family 都會有一個 MemStore。

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

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

HBase 寫數據步驟

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

• 新數據會被追加到 WAL 文件尾部。
• WAL 用來在故障恢復時恢復還未被持久化的數據。 

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

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

HBase MemStore

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

HBase Region Flush

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

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

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

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

HBase HFile

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

HBase HFile 文件結構

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

• KeyValues 有序存儲。
• rowkey 指向 index，而 index 則指向了具體的 data block，以 64 KB 為單位。
• 每個 block 都有它的葉索引。
• 每個 block 的最后一個 key 都被存儲在中間層索引。
• 索引根節點指向中間層索引。

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

HFile 索引

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

HBase Read 合并

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

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

然后 scanner 讀取 MemStore，即寫緩存，包含了最近更新的數據。

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

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

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

HBase Minor Compaction

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

HBase Major Compaction

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

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

HDFS數據備份

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

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

HBase 故障恢復

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

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

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

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

點評：故障恢復是 HBase 可靠性保障的一個重要特性。WAL 在這里扮演了關鍵角色，在分割 WAL 時，數據會根據 region 分配到對應的新的 region server 上，然后 region server 負責回放這一部分數據到 MemStore 中。