HBase數據庫原理解析

1.HBase 數據庫介紹

1.1產生背景

自 1970 年以來，關係數據庫用於數據存儲和維護有關問題的解決方案。大數據的出現後， 好多公司實現處理大數據並從中受益，並開始選擇像 Hadoop 的解決方案。Hadoop 使用分 布式文件系統，用於存儲大數據，並使用 MapReduce 來處理。Hadoop 擅長於存儲各種格式 的龐大的數據，任意的格式甚至非結構化的處理。

Hadoop 的限制

Hadoop 只能執行批量處理，並且只以順序方式訪問數據。這意味着必須搜索整個數據集， 即使是最簡單的搜索工作。 當處理結果在另一個龐大的數據集，也是按順序處理一個巨大的數據集。在這一點上，一個 新的解決方案，需要訪問數據中的任何點（隨機訪問）單元。

Hadoop 隨機存取數據庫

應用程序，如 HBase，Cassandra，CouchDB，Dynamo 和 MongoDB 都是一些存儲大量數據和 以隨機方式訪問數據的數據庫。

總結：

（1）海量數據量存儲成爲瓶頸，單臺機器無法負載大量數據

（2）單臺機器 IO 讀寫請求成爲海量數據存儲時候高併發大規模請求的瓶頸

（3）隨着數據規模越來越大，大量業務場景開始考慮數據存儲橫向水平擴展，使得存儲服 務可以增加/刪除，而目前的關係型數據庫更專注於一臺機器

1.2簡介

官網：http://HBase.apache.org/

1. Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.

2. Use Apache HBase™ when you need random, realtime read/write access to your Big Data.

3. This project’s goal is the hosting of very large tables – billions of rows X millions of columns – atop clusters of commodity hardware.

4. Apache HBase is an open-source, distributed, versioned, non-relational database modeled after Google’s Bigtable: A Distributed Storage System for Structured Data by Chang et al. Just as Bigtable leverages the distributed data storage provided by the Google File System, Apache HBase provides Bigtable-like capabilities on top of Hadoop and HDFS.

HBase 是 BigTable 的開源（源碼使用 Java 編寫）版本。是 Apache Hadoop 的數據庫，是建 立在 HDFS 之上，被設計用來提供高可靠性、高性能、列存儲、可伸縮、多版本的 NoSQL 的分佈式數據存儲系統，實現對大型數據的實時、隨機的讀寫訪問。

HBase 依賴於 HDFS 做底層的數據存儲，BigTable 依賴 Google GFS 做數據存儲

HBase 依賴於 MapReduce 做數據計算，BigTable 依賴 Google MapReduce 做數據計算

HBase 依賴於 ZooKeeper 做服務協調，BigTable 依賴 Google Chubby 做服務協調

NoSQL = NO SQL

NoSQL = Not Only SQL：會有一些把 NoSQL 數據的原生查詢語句封裝成 SQL

比如 HBase 就有 Phoenix 工具

關係型數據庫 和 非關係型數據庫的典型代表：

NoSQL：HBase, redis, mongodb

RDBMS：mysql,oracle,sql server,db2

以下五點是 HBase 這個 NoSQL 數據庫的要點：

① 它介於 NoSQL 和 RDBMS 之間，僅能通過主鍵(rowkey)和主鍵的 range 來檢索數據

② HBase 查詢數據功能很簡單，不支持 join 等複雜操作

③ 不支持複雜的事務，只支持行級事務(可通過 hive 支持來實現多表 join 等複雜操作)。

④ HBase 中支持的數據類型：byte[]（底層所有數據的存儲都是字節數組）

⑤ 主要用來存儲結構化和半結構化的鬆散數據。

結構化：數據結構字段含義確定，清晰，典型的如數據庫中的表結構

半結構化：具有一定結構，但語義不夠確定，典型的如 HTML 網頁，有些字段是確定的(title)， 有些不確定(table)

非結構化：雜亂無章的數據，很難按照一個概念去進行抽取，無規律性

與 Hadoop 一樣，HBase 目標主要依靠橫向擴展，通過不斷增加廉價的商用服務器，來增加 計算和存儲能力。

HBase 中的表特點

1. 大：一個表可以有上十億行，上百萬列

2. 面向列：面向列(族)的存儲和權限控制，列(簇)獨立檢索。

3. 稀疏：對於爲空(null)的列，並不佔用存儲空間，因此，表可以設計的非常稀疏。

4. 無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一 張表中不同的行可以有截然不同的列

1.3表結構邏輯視圖

HBase 以表的形式存儲數據。表由行和列組成。列劃分爲若干個列簇 (Column Family)

1.3.1行鍵（RowKey）

與 NoSQL 數據庫們一樣，rowkey 是用來檢索記錄的主鍵。訪問 HBase Table 中的行，只有三 種方式：

1. 通過單個 row key 訪問

2. 通過 row key 的 range

3. 全表掃描

rowkey 行鍵可以是任意字符串(最大長度是 64KB，實際應用中長度一般爲 10-100bytes)，最好是 16。在 HBase 內部，rowkey 保存爲字節數組。HBase 會對錶中的數據按照 rowkey 排序 (字典順序)

存儲時，數據按照 rowkey 的字典序(byte order)排序存儲。設計 key 時，要充分排序存儲這 個特性，將經常一起讀取的行存儲放到一起。(位置相關性)

注意：

字典序對 int 排序的結果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,„,9,91,92,93,94,95,96,97,98,99。

要保持整形的自然序，行鍵必須用 0 作左填充。

行的一次讀寫是原子操作(不論一次讀寫多少列)。這個設計決策能夠使用戶很容易的理解程 序在對同一個行進行併發更新操作時的行爲。

1.3.2列簇（Column Family）

HBase 表中的每個列，都歸屬與某個列簇。列簇是表的 Schema 的一部分(而列不是)，必須 在使用表之前定義好，而且定義好了之後就不能更改。

列名都以列簇作爲前綴。例如 courses:history，courses:math 都屬於 courses 這個列簇。 訪問控制、磁盤和內存的使用統計等都是在列簇層面進行的。

列簇越多，在取一行數據時所要參與 IO、搜尋的文件就越多，所以，如果沒有必要，不要 設置太多的列簇（最好就一個列簇）

1.3.3時間戳（TimeStamp）

HBase 中通過 rowkey 和 columns 確定的爲一個存儲單元稱爲 cell。每個 cell 都保存着同一份 數據的多個版本。版本通過時間戳來索引。時間戳的類型是 64 位整型。時間戳可以由 HBase(在數據寫入時自動)賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也可以由 客戶顯式賦值。如果應用程序要避免數據版本衝突，就必須自己生成具有唯一性的時間戳。 每個 cell 中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。

爲了避免數據存在過多版本造成的的管理 (包括存貯和索引)負擔，HBase 提供了兩種數據版 本回收方式：

保存數據的最後 n 個版本

保存最近一段時間內的版本（設置數據的生命週期 TTL）

用戶可以針對每個列簇進行設置。

1.3.4單元格（Cell）

由{rowkey, column( = + ), version} 唯一確定的單元。 Cell 中的數據是沒有類型的，全部是字節碼形式存貯。

1.4HBase 應用場景

1. 半結構化或非結構化數據

   對於數據結構字段不夠確定或雜亂無章很難按一個概念去進行抽取的數據適合用 HBase。而 且 HBase 是面向列的，HBase 支持動態增加字段

2. 記錄非常稀疏

   RDBMS 的行有多少列是固定的，爲 null 的列浪費了存儲空間。而 HBase 爲 null 的 Column 是不會被存儲的，這樣既節省了空間又提高了讀性能。

3. 多版本數據

   對於需要存儲變動歷史記錄的數據，使用 HBase 就再合適不過了。HBase 根據 Row key 和 Column key 定位到的 Value 可以有任意數量的版本值。

4. 超大數據量

   當數據量越來越大，RDBMS 數據庫撐不住了，就出現了讀寫分離策略，通過一個 Master 專 門負責寫操作，多個 Slave 負責讀操作，服務器成本倍增。隨着壓力增加，Master 撐不住了， 這時就要分庫了，把關聯不大的數據分開部署，一些 join 查詢不能用了，需要藉助中間層。 隨着數據量的進一步增加，一個表的記錄越來越大，查詢就變得很慢，於是又得搞分表，比 如按 ID 取模分成多個表以減少單個表的記錄數。經歷過這些事的人都知道過程是多麼的折 騰。採用 HBase 就簡單了，只需要加機器即可，HBase 會自動水平切分擴展，跟 Hadoop 的 無縫集成保障了其數據可靠性（HDFS）和海量數據分析的高性能（MapReduce）。

2.HBase 集羣結構

region：是 HBase 中對錶進行切割的單元，由 regionserver 負責管理

hamster：HBase 的主節點，負責整個集羣的狀態感知，負載分配、負責用戶表的元數據(schema)管理（可以配置多個用來實現 HA）,hmaster 負載壓力相對於 hdfs 的 namenode 會小很多

regionserver：HBase 中真正負責管理 region 的服務器，也就是負責爲客戶端進行表數據讀寫 的服務器每一臺 regionserver 會管理很多的 region，同一個 regionserver 上面管理的所有的 region 不屬於同一張表

zookeeper：整個 HBase 中的主從節點協調，主節點之間的選舉，集羣節點之間的上下線感 知„„都是通過 zookeeper 來實現

HDFS：用來存儲 HBase 的系統文件，或者表的 region

3.HBase 和 Hive 的比較

3.1相同點

1. HBase 和 Hive 都是架構在 Hadoop 之上，用 HDFS 做底層的數據存儲，用 MapReduce 做 數據計算

3.2不同點

1. Hive 是建立在 Hadoop 之上爲了降低 MapReduce 編程複雜度的 ETL 工具。 HBase 是爲了彌補 Hadoop 對實時操作的缺陷

2. Hive 表是純邏輯表，因爲 Hive 的本身並不能做數據存儲和計算，而是完全依賴 Hadoop HBase 是物理表，提供了一張超大的內存 Hash 表來存儲索引，方便查詢

3. Hive 是數據倉庫工具，需要全表掃描，就用 Hive，因爲 Hive 是文件存儲 HBase 是數據庫，需要索引訪問，則用 HBase，因爲 HBase 是面向列的 NoSQL 數據庫

4. Hive 表中存入數據（文件）時不做校驗，屬於讀模式存儲系統 HBase 表插入數據時，會和 RDBMS 一樣做 Schema 校驗，所以屬於寫模式存儲系統

5. Hive 不支持單行記錄操作，數據處理依靠 MapReduce，操作延時高 HBase 支持單行記錄的 CRUD，並且是實時處理，效率比 Hive 高得多

4.HBase內部原理

4.1系統架構

Client 職責

1. HBase 有兩張特殊表：

   .meta.：記錄了用戶表的 Region 信息，.META.可以有多個 regoin

   -root-：記錄了.META.表的 Region 信息，-ROOT-只有一個 region

2. Client 訪問用戶數據前需要首先訪問 zookeeper，找到-root-表的 region 所在的位置，然後 訪問-root-表，接着訪問.meta.表，最後才能找到用戶數據的位置去訪問，中間需要多次網絡 操作，不過 client 端會做 cache 緩存。

ZooKeeper 職責

1、ZooKeeper 爲 HBase 提供 Failover 機制，選舉 master，避免單點 master 單點故障問題

2、存儲所有 Region 的尋址入口：-root-表在哪臺服務器上。-root-這張表的位置信息

3、實時監控 RegionServer 的狀態，將 RegionServer 的上線和下線信息實時通知給 Master

4、存儲 HBase 的 schema，包括有哪些 table，每個 table 有哪些 column family

Master 職責

1. 爲 RegionServer 分配 region

2. 負責 RegionServer 的負載均衡

3. 發現失效的 RegionServer 並重新分配其上的 region

4. HDFS 上的垃圾文件（HBase）回收

5. 處理 schema 更新請求（表的創建，刪除，修改，列簇的增加等等）

RegionServer 職責

1. RegionServer 維護 Master 分配給它的 region，處理對這些 region 的 IO 請求

2. RegionServer 負責 Split 在運行過程中變得過大的 region，負責 Compact 操作

可以看到，client 訪問 HBase 上數據的過程並不需要 master 參與（尋址訪問 zookeeper 和 RegioneServer，數據讀寫訪問 RegioneServer），master 僅僅維護者 table 和 region 的元數據 信息，負載很低。

.meta. 存的是所有的 region 的位置信息，那麼 RegioneServer 當中 region 在進行分裂之後 的新產生的 region，是由 master 來決定發到哪個 RegioneServer，這就意味着，只有 master 知道 new region 的位置信息，所以，由 master 來管理.meta.這個表當中的數據的 CRUD

所以結合以上兩點表明，在沒有 region 分裂的情況，master 宕機一段時間是可以忍受的。

4.2物理存儲

4.2.1整體物理結構

1. Table 中的所有行都按照 row key 的字典序排列。

2. Table 在行的方向上分割爲多個 Hregion。

3. Hregion 按大小分割的(默認 10G)，每個表一開始只有一個 Hregion，隨着數據不斷插入表， Hregion 不斷增大，當增大到一個閥值的時候，Hregion 就會等分會兩個新的 Hregion。當表 中的行不斷增多，就會有越來越多的 Hregion。

4. **Hregion 是 HBase 中分佈式存儲和負載均衡的最小單元。**最小單元就表示不同的 Hregion 可以分佈在不同的 HRegion server 上。但一個 Hregion 是不會拆分到多個 server 上的。

5. HRegion 雖然是負載均衡的最小單元，但並不是物理存儲的最小單元。事實上，HRegion 由一個或者多個 Store 組成，每個 Store 保存一個 Column Family。每個 Strore 又由一個 memStore 和 0 至多個 StoreFile 組成

4.2.2StoreFile 和 HFile 結構

StoreFile 以 HFile 格式保存在 HDFS 上，請看下圖 HFile 的數據組織格式：

首先 HFile 文件是不定長的，長度固定的只有其中的兩塊：Trailer 和 FileInfo。

正如圖中所示：

Trailer 中有指針指向其他數據塊的起始點。

FileInfo 中記錄了文件的一些 Meta 信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY 等。

HFile 分爲六個部分：

Data Block 段 – 保存表中的數據，這部分可以被壓縮

Meta Block 段(可選的) – 保存用戶自定義的 kv 對，可以被壓縮。

File Info 段 – Hfile 的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。

Data Block Index 段 – Data Block 的索引。每條索引的 key 是被索引的 block 的第一條記錄的 key。

Meta Block Index 段 (可選的) – Meta Block 的索引。

Trailer 段 – 這一段是定長的。保存了每一段的偏移量，讀取一個 HFile 時，會首先讀取 Trailer， Trailer保存了每個段的起始位置(段的Magic Number用來做安全check)，然後，DataBlock Index 會被讀取到內存中，這樣，當檢索某個 key 時，不需要掃描整個 HFile，而只需從內存中找 到key所在的block，通過一次磁盤io將整個block讀取到內存中，再找到需要的key。DataBlock Index 採用 LRU 機制淘汰。 HFile 的 Data Block，Meta Block 通常採用壓縮方式存儲，壓縮之後可以大大減少網絡 IO 和磁 盤 IO，隨之而來的開銷當然是需要花費 cpu 進行壓縮和解壓縮。 目標 Hfile 的壓縮支持兩種方式：Gzip，LZO。

Data Index 和 Meta Index 塊記錄了每個 Data 塊和 Meta 塊的起始點。

Data Block 是 HBase I/O 的基本單元，爲了提高效率，HRegionServer 中有基於 LRU 的 Block Cache 機制。每個 Data 塊的大小可以在創建一個 Table 的時候通過參數指定，大號的 Block 有利於順序 Scan，小號 Block 利於隨機查詢。 每個 Data 塊除了開頭的 Magic 以外就是一個 個 KeyValue 對拼接而成, Magic 內容就是一些隨機數字，目的是防止數據損壞。 HFile 裏面的每個 KeyValue 對就是一個簡單的 byte 數組。但是這個 byte 數組裏麪包含了很 多項，並且有固定的結構。我們來看看裏面的具體結構：

開始是兩個固定長度的數值，分別表示 Key 的長度和 Value 的長度。緊接着是 Key，開始是 固定長度的數值，表示 RowKey 的長度，緊接着是 RowKey，然後是固定長度的數值，表示 Family 的長度，然後是 Family，接着是 Qualifier，然後是兩個固定長度的數值，表示 Time Stamp 和 Key Type（Put/Delete）。Value 部分沒有這麼複雜的結構，就是純粹的二進制數據了。

4.2.3MemStore 和 StoreFile

一個 Hregion 由多個 Store 組成，每個 Store 包含一個列族的所有數據

Store 包括位於內存的一個 memstore 和位於硬盤的多個 storefile 組成

寫操作先寫入 memstore，當 memstore 中的數據量達到某個閾值，HRegionServer 啓動 flushcache 進程寫入 storefile，每次寫入形成單獨一個 Hfile

當總 storefile 大小超過一定閾值後，會把當前的 region 分割成兩個，並由 HMaster 分配給相 應的 region 服務器，實現負載均衡

客戶端檢索數據時，先在 memstore 找，找不到再找 storefile

4.2.4HLog(WAL)

WAL 意爲 Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，類似 mysql 中的 binlog，用來做災難恢復之用，Hlog 記錄數據的所有變更，一旦數據修改，就可以從 log 中 進行恢復。

每個 Region Server 維護一個 Hlog,而不是每個 Region 一個。這樣不同 region(來自不同 table) 的日誌會混在一起，這樣做的目的是不斷追加單個文件相對於同時寫多個文件而言，可以減 少磁盤尋址次數，因此可以提高對 table 的寫性能。帶來的麻煩是，如果一臺 region server 下線，爲了恢復其上的 region，需要將 region server 上的 log 進行拆分，然後分發到其它 region server 上進行恢復。

HLog 文件就是一個普通的 Hadoop Sequence File：

1. HLog Sequence File 的 Key 是 HLogKey 對象，HLogKey 中記錄了寫入數據的歸屬信息，除 了 table 和 region 名字外，同時還包括 sequence number 和 timestamp，timestamp 是”寫入 時間”，sequence number 的起始值爲 0，或者是最近一次存入文件系統中 sequence number。

2. HLog Sequece File 的 Value 是 HBase 的 KeyValue 對象，即對應 HFile 中的 KeyValue

4.3尋址機制

現在假設我們要從 user_info 裏面尋找一條 RowKey 是 rk0001 的數據。那麼我們應該遵循以 下步驟：

1. 從.META.表裏面查詢哪個 Region 包含這條數據。
2. 獲取管理這個 Region 的 RegionServer 地址。
3. 連接這個 RegionServer，查到這條數據。

系統如何找到某個 RowKey (或者某個 RowKey range)所在的 region

bigtable 使用三層類似 B+樹的結構來保存 region 位置。

• 第一層是 zookeeper 裏面保存的數據，它持有 root region 的位置。

• 第二層 root region 是.META.表的第一個 region 其中保存了.META.表其它 region 的位置。通過 root region，我們就可以訪問.META.表的數據。

• 第三層是.META.，它是一個特殊的表，保存了 HBase 中所有數據表的 region 位置信息。

說明：

1. root region 永遠不會被 split，保證了最多需要三次跳轉，就能定位到任意 region。

2. .META.表每行保存一個 region 的位置信息，rowkey 採用表名+表的最後一行編碼而成。

3. 爲了加快訪問，.META.表的全部 region 都保存在內存中。

4. client 會將查詢過的位置信息保存緩存起來，緩存不會主動失效，因此如果 client 上的緩 存全部失效，則需要進行最多 6 次網絡來回，才能定位到正確的 region(其中三次用來發現 緩存失效，另外三次用來獲取位置信息)。

4.4讀寫過程

4.4.1讀請求過程

1. 客戶端通過 zookeeper 以及-root-表和.meta.表找到目標數據所在的 regionserver(就是數據 所在的 region 的主機地址)

2. 聯繫 regionserver 查詢目標數據

3. regionserver 定位到目標數據所在的 region，發出查詢請求

4. region 先在 memstore 中查找，命中則返回

5. 如 果 在 memstore 中 找 不 到 ， 則 在 storefile 中 掃 描 （ 可 能 會 掃 描 到 很 多 的 storefile----BloomFilter） （BloomFilter，布隆過濾器：迅速判斷一個元素是不是在一個龐大的集合內，但是他有一個 弱點：它有一定的誤判率） （誤判率：原本不存在與該集合的元素，布隆過濾器有可能會判斷說它存在，但是，如果 布隆過濾器，判斷說某一個元素不存在該集合，那麼該元素就一定不在該集合內）

4.4.2寫請求過程

1. client 先根據 rowkey 找到對應的 region 所在的 regionserver

2. client 向 regionserver 提交寫請求

3. regionserver 找到目標 region

4. region 檢查數據是否與 schema 一致

5. 如果客戶端沒有指定版本，則獲取當前系統時間作爲數據版本

6. 將更新寫入 WAL log

7. 將更新寫入 Memstore

8. 判斷 Memstore 的是否需要 flush 爲 Store 文件。

HBase 在做數據插入操作時，首先要找到 rowkey 所對應的的 region，怎麼找到的？其實這個 簡單，因爲.META.表存儲了每張表每個 region 的起始 rowkey 了。

建議：在做海量數據的插入操作，避免出現遞增 rowkey 的 put 操作

如果 put 操作的所有 rowkey 都是遞增的，那麼試想，當插入一部分數據的時候剛好進行分 裂，那麼之後的所有數據都開始往分裂後的第二個 region 插入，就造成了數據熱點現象。

細節描述： HBase 使用 MemStore 和 StoreFile 存儲對錶的更新。

數據在更新時首先寫入 HLog(WAL log)和內存(MemStore)中，MemStore 中的數據是排序的， 當 MemStore 累計到一定閾值時，就會創建一個新的 MemStore，並且將老的 MemStore 添 加到 flush 隊列，由單獨的線程 flush 到磁盤上，成爲一個 StoreFile。於此同時，系統會在 zookeeper 中記錄一個 redo point，表示這個時刻之前的變更已經持久化了。當系統出現意外 時，可能導致內存(MemStore)中的數據丟失，此時使用 HLog(WAL log)來恢復 checkpoint 之 後的數據。

StoreFile是隻讀的，一旦創建後就不可以再修改。因此HBase的更新其實是不斷追加的操作。 當一個 Store 中的 StoreFile 達到一定的閾值後，就會進行一次合併(minor_compact, major_compact)，將對同一個 key 的修改合併到一起，形成一個大的 StoreFile，當 StoreFile 的大小達到一定閾值後，又會對 StoreFile 進行 split，等分爲兩個 StoreFile。由於對錶的更 新是不斷追加的，compact 時，需要訪問 Store 中全部的 StoreFile 和 MemStore，將他們按 row key 進行合併，由於 StoreFile 和 MemStore 都是經過排序的，並且 StoreFile 帶有內存中 索引，合併的過程還是比較快。

major_compact 和 minor_compact 的區別

minor_compact 僅僅合併小文件（HFile）

major_compact 合併一個 region 內的所有文件

Client 寫入 -> 存入 MemStore，一直到 MemStore 滿 -> Flush 成一個 StoreFile，直至增長到 一定閾值 -> 觸發 Compact 合併操作 -> 多個 StoreFile 合併成一個 StoreFile，同時進行版本 合併和數據刪除 -> 當 StoreFiles Compact 後，逐步形成越來越大的 StoreFile -> 單個 StoreFile大小超過一定閾值後，觸發 Split 操作，把當前 Region Split 成 2 個 Region，Region 會下線， 新 Split 出的 2 個孩子 Region 會被 HMaster 分配到相應的 HRegionServer 上，使得原先 1 個 Region 的壓力得以分流到 2 個 Region 上由此過程可知，HBase 只是增加數據，有所得更新 和刪除操作，都是在 Compact 階段做的，所以，用戶寫操作只需要進入到內存即可立即返 回，從而保證 I/O 高性能。

寫入數據的過程補充：

工作機制：每 個 HRegionServer 中都會有一個 HLog 對象，HLog 是一個實現 Write Ahead Log 的類，每次用戶操作寫入 Memstore 的同時，也會寫一份數據到 HLog 文件，HLog 文件定期 會滾動出新，並刪除舊的文件(已持久化到 StoreFile 中的數據)。當 HRegionServer 意外終止 後，HMaster 會通過 Zookeeper 感知，HMaster 首先處理遺留的 HLog 文件，將不同 region 的 log 數據拆分，分別放到相應 region 目錄下，然後再將失效的 region（帶有剛剛拆分的 log） 重新分配，領取到這些 region 的 HRegionServer 在 Load Region 的過程中，會發現有歷史 HLog 需要處理，因此會 Replay HLog 中的數據到 MemStore 中，然後 flush 到 StoreFiles，完成數據 恢復。

4.5RegionServer 工作機制

1. region 分配 任何時刻，一個 region 只能分配給一個 region server。master 記錄了當前有哪些可用的 region server。以及當前哪些 region 分配給了哪些 region server，哪些 region 還沒有分配。當需要 分配的新的 region，並且有一個 region server 上有可用空間時，master 就給這個 region server 發送一個裝載請求，把 region 分配給這個 region server。region server 得到請求後，就開始 對此 region 提供服務。

2. region server 上線 master 使用 zookeeper 來跟蹤 region server 狀態。當某個 region server 啓動時，會首先在 zookeeper 上的 server 目錄下建立代表自己的 znode。由於 master 訂閱了 server 目錄上的變 更消息，當 server 目錄下的文件出現新增或刪除操作時，master 可以得到來自 zookeeper 的 實時通知。因此一旦 region server 上線，master 能馬上得到消息。

3. region server 下線 當 region server 下線時，它和 zookeeper 的會話斷開，zookeeper 而自動釋放代表這臺 server 的文件上的獨佔鎖。master 就可以確定：

   • region server 和 zookeeper 之間的網絡斷開了。

   • region server 掛了。

     無論哪種情況，region server 都無法繼續爲它的 region 提供服務了，此時 master 會刪除 server 目錄下代表這臺 region server 的 znode 數據，並將這臺 region server 的 region 分配給其它還 活着的同志。

4.6.Master 工作機制

master 上線

master 啓動進行以下步驟:

1. 從zookeeper上獲取唯一一個代表 active master 的鎖，用來阻止其它 master 成爲 master。
2. 掃描 zookeeper 上的 server 父節點，獲得當前可用的 region server 列表。
3. 和每個 region server 通信，獲得當前已分配的 region 和 region server 的對應關係。
4. 掃描.META.region 的集合，計算得到當前還未分配的 region，將他們放入待分配 region 列表。

master 下線

由於 master 只維護表和 region 的元數據，而不參與表數據 IO 的過程，master 下線僅導 致所有元數據的修改被凍結(無法創建刪除表，無法修改表的 schema，無法進行 region 的負 載均衡，無法處理 region 上下線，無法進行 region 的合併，唯一例外的是 region 的 split 可 以正常進行，因爲只有 region server 參與)，表的數據讀寫還可以正常進行。因此 master 下 線短時間內對整個 HBase 集羣沒有影響。

從上線過程可以看到，master 保存的信息全是可以冗餘信息（都可以從系統其它地方 收集到或者計算出來）

因此，一般 HBase 集羣中總是有一個 master 在提供服務，還有一個以上的 master 在等 待時機搶佔它的位置。