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

本文系轉載,若有侵權,請聯繫我:likui0913@gmail.comhtml

Region

Region 是表格可用性和分佈的基本元素,由列族(Column Family)構成的 Store 組成。對象的層次結構以下:shell

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

其中 StoreFile 在 HDFS 中的存儲路徑爲:apache

/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 數量的一些緣由:session

  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.8GBide

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

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

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

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

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 合併完成

狀態轉換圖以下:

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_OPENFAILED_CLOSE狀態的Region,Master在經過HBase Shell從新分配它們時嘗試再次關閉它們。

可能產生的影響

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

參考連接

相關文章
相關標籤/搜索