HBase 架構與工做原理5 - Region 的部分特性

本文系轉載，若有侵權，請聯繫我：likui0913@gmail.com

Region

Region 是表格可用性和分佈的基本元素，由列族（Column Family）構成的 Store 組成。對象的層次結構以下：

- Table
    - Region
        - Store         （由每一個 Region 中的列族組成的存儲塊）
            - MemStore  （每一個 Region 中存儲在內存中的 Store）
            - StoreFile （每一個 Region 中被持久化後的 Store）
                - Block （StoreFile 內被分塊存儲後的塊）

其中 StoreFile 在 HDFS 中的存儲路徑爲：

/hbase
    /data
        /<Namespace>                    (Namespaces in the cluster)
            /<Table>                    (Tables in the cluster)
                /<Region>               (Regions for the table)
                    /<ColumnFamily>     (ColumnFamilies for the Region for the table)
                        /<StoreFile>    (StoreFiles for the ColumnFamily for the Regions for the table)

1. Region 數量

一般而言，HBase 被設計成每臺服務器運行一個數量較小的（20 - 200）但大小相對較大（5 - 20 GB）的 Region。那麼爲何應該保持 Region 數量較低？

如下是保持較低 Region 數量的一些緣由：

1. 每一個 MemStore 須要 2MB 的 MSLAB（MemStore-local 分配的 buffer）- 至關於每一個 Region 的每一個列族（ClounmFamily）須要 2MB 的 MSLAB。那麼 1000 個有 2 個列族的 Region 將使用 2MB * 1000 * 2 = 4000MB ~= 3.9GB 的堆內存，甚至都尚未開始存儲數據。注：MSLAB 的大小是可配置的，默認爲 2MB.

2. 若是以相同的速率填充全部的 Region，則全局內存使用狀況會在由於 Region 太多而產生 compaction 操做時，強制進行微小的刷新。舉個例子：平均填充1000個Region（有一個列族），假若有5GB的全局 MemStore 使用的下限（RegionServer有一個大的堆），一旦它達到5GB，它將強制刷新最大的 Region，那時每一個 Region 大約都是 5MB 的數據，因此它會刷新這個 Region。稍後再插入 5MB，它將刷新另外一個 Region，依次類推。目前這個是 Region 數量的主要限制因素。更多請參閱。。。

   舉個實例來講：目前的一個集羣單臺 RegionServer 分配的內存大小爲 32GB，其中全部的 MemStore 的最大大小比例設置爲 0.4，即最大大小爲 32GB * 0.4 = 12.8GB

3. Master 很討厭太多的 Region，由於這可能須要大量的時間分配並批量移動。

4. 在比較舊版本的 HBase（HFile v2, 0.90 以前的版本）中，幾個 RegionServer 上的大量的 Region 會致使存儲文件索引上升，增長堆使用量，並可能在 RS 致使內存壓力或 OOME。

5. 另一個問題是 Region 數量對 MapReduce 做業的影響。每一個 HBase Region 都有一個映射器是很典型的，所以，每一個 RS 僅託管 5 個 Region 可能不足以得到足夠數量的 MapReduce 做業任務，可是 1000 個 Region 又將生成太多的任務。

請參考Determining region count and size配置 Region 數量。

2. Region-RegionServer 的分配

當 HBase 啓動 RegionServer 分配時，簡要過程以下：

1. Master 在啓動時調用 AssignmentManager；
2. AssignmentManager 查看 hbase:meta 中的現有 Region 分配；
3. 若是 Region 分配仍然有效（即，若是 RegionServer 仍處於聯機狀態），則保留分配；
4. 若是分配無效，則調用 LoadBalancerFactory 來分配 Region。負載均衡器將 Region 分配給 RegionServer；
5. hbase:meta 使用 RegionServer 分配（若是須要）和 RegionServer 的開始碼（RegionServer進程的開始時間）在 RegionServer 打開 Region 時進行更新。

3. 故障轉移

當 RegionServer 失敗時：

1. 因爲 RegionServer 關閉，它上面的 Region 會當即變得不可用；
2. Master 將檢測到 RegionServer 失敗；
3. Region 分配將被視做無效，並將像啓動順序一個被從新分配；
4. 從新嘗試進行中的查詢，不會丟失；
5. 在如下時間段內，操做將切換到新的 RegionServer：

   ZooKeeper session timeout + split time + assignment/replay time

4. 負載平衡

Region 能夠被負載平衡器（LoadBalancer）按期的移動。

5. 狀態轉換

HBase 維持每一個 Region 的狀態，並將它們的狀態保存在 hbase:meat 表中，hbase:meta 的 Region 狀態則保存在 Zookeeper 中。在 Master Web UI 中能夠查看轉換中的 Region 狀態。如下是可能的 Region 狀態列表：

• OFFLINE: 該 Region 處於離線狀態，沒法打開
• OPENING: 該 Region 正在打開
• OPEN: 該 Region 已經打開，而且 RegionServer 已經通知 Master
• FAILED_OPEN: RegionServer 打開該 Region 失敗
• CLOSING: 該 Region 正在關閉
• CLOSED: RegionServer 關閉了該 Region，並通知了 Master
• FAILED_CLOSE: RegionSever 關閉該 Region 失敗
• SPLITTING: RegionServer 通知 Master Region 正在分裂（splitting）
• SPLIT: RegionServer 通知 Master Region 已經完成分裂
• SPLITTING_NEW: 該 Region 正在進行經過分裂建立新的 Region
• MERGING: RegionServer 通知 master 該 region 正在與另一個 region 合併
• MERGED: RegionServer 通知 master 該 region 已經合併完成
• MERGING_NEW: 該 Region 由兩個 Region 合併完成

狀態轉換圖以下：

圖示說明：

• 棕色：離線狀態，一種特殊狀態，能夠是暫時的（打開以前關閉後）、最終的（被 disabled 表的 regions）或者初始的（新建表的 region）
• 淡綠色：在線狀態，region 能夠爲請求提供服務
• 淡藍色：過渡狀態，瞬時的
• 紅色：失敗狀態，須要管理員關注，一般沒法寫入數據可能就是它照成的
• 黃金：regions split/merged 後的最終狀態
• 灰色：經過 split/merged 並建立的新的 region 的初始狀態

過渡狀態描述

1. Master將Region從OFFLINE轉換成OPENING狀態，並嘗試將該區域分配給RegionServer。RegionServer可能收到也可能未收到開放Region的請求。Master會重試將打開Region請求發送RegionServer，直到RPC經過或Master用完重試。在RegionServer收到打開Region請求後，RegionServer開始打開Region；

2. 若是Master重試超時，則即便RegionServer正在打開Region，Master也會經過將Region轉換爲CLOSING狀態並嘗試關閉它來阻止RegionServer繼續打開該Region；

3. RegionServer打開該Region後，它將繼續嘗試通知Master，直到Master將該Region轉換爲OPEN狀態並通知RegionServer，該Region纔算打開；

4. 若是RegionServer沒法打開Region，它會通知Master。而後Master將該Region轉換爲CLOSED狀態，並嘗試在其它的RegionServer上打開該Region；

5. 若是Master沒法打開某個Region，則會將Region轉換爲FAILED_OPEN狀態，而且在管理員使用HBase shell操做以前或服務器死亡以前不會採起進一步的操做；

6. Master將Region從OPEN轉換爲CLOSING狀態。持有Region的RegionServer可能已經或可能未收到關閉Region請求。Maater將重試向服務器發送關閉請求，直到RPC經過或Master用盡重試；

7. 若是RegionServer不在線或引起NotServingRegionException，則Master將該Region轉換爲OFFLINE狀態，並將其從新分配給其它的RegionServer；

8. 若是RegionServer處於聯機狀態，但在Master用完重試以後沒法訪問，則Master會將該Region移至FAILED_CLOSE狀態，而且不會採起進一步的操做，直到操做員從HBase shell進行干預或服務器死亡；

9. 若是RegionServer得到關閉Region請求，它會關閉該Region並通知Master。Master將該Reguib移至CLOSED狀態並從新分配給其它的RegionServer；

10. 在分配Region以前，若是Region處於CLOSED狀態，Master會自動將Region轉換爲OFFLINE狀態；

11. 當一個RegionServer即將分裂（split）一個Region時，它通知Master，Master將Region從OPEN轉換爲SPLITTING狀態，並將要建立的兩個新Region添加到RegionServer。這兩個Region最初處於SPLITTING_NEW狀態。

12. 在通知Master後，RegionServer開始分裂Region。一旦通過了不返回的地方，RegionServer會再次通知Master，以便Master能夠更新hbase:meta表。無論怎樣，在服務器通知分裂完成以前，Master不會更新Region的狀態。若是分裂成功，則分裂的Region從SPLITTING轉換爲SPLIT狀態，而且兩個新的Region從SPLITTING_NEW轉換爲OPEN狀態。

13. 若是分裂失敗，則分裂Region將從SPLITTING回到OPEN狀態，而且建立的兩個新的Region將從SPLITTING_NEW轉換爲OFFLINE狀態；

14. 當一個RegionServer即將合併（merge）兩個Region時，它首先通知Master，Master將兩個待合併的Region從OPEN轉換爲MERGING狀態，並將擁有兩個合併的Region內容的新的Region添加到並添加到RegionServer。新的Region最初處於MERGING_NEW狀態。

15. 通知Master後，RegionServer開始合併這兩個Region。一旦通過不返回的地方，RegionServer再次通知Master，以便Master能夠更新META表。可是，Master不會更新Region狀態，直到RegionServer通知合併已完成。若是合併成功，則兩個合併的 Region將從MERGING狀態變爲MERGED狀態，而且新的 Region 將從MERGING_NEW轉換爲OPEN狀態；

16. 若是合併失敗，則將兩個合併的Region從MERGING更改回OPEN狀態，而且建立的用於容納合並Region內容的新的Region將從MERGING_NEW轉換爲OFFLINE狀態。

17. 對於處於FAILED_OPEN或FAILED_CLOSE狀態的Region，Master在經過HBase Shell從新分配它們時嘗試再次關閉它們。

可能產生的影響

瞭解Region的狀態變化過程十分重要，由於Region的狀態在發生更改時，若是發生異常，極可能須要管理員人工介入。而在人工介入以前，頗有可能會影響到部分表的正常使用，示例可參見：(HBase 部分表沒法寫入數據的異常處理)[https://blog.csdn.net/t894690230/article/details/78508862]

參考連接

• Apache HBase ™ Reference Guide