1. 程式人生 > >【HBase】HBase筆記:HBase的Region機制

【HBase】HBase筆記:HBase的Region機制

        HBase 的機制裡包含了許多優秀的演算法,如 Region 定位、Region 分配、Region Server的上線和下線、Master 的上線和下線。在談到這些之前,先把 HBase 的基本架構裡的一些概念列在這裡。

一、HBase組成

1.Client:利用 RPC 機制與 HMaster 和HRegionServer通訊;

2.Zookeeper: 協調,避免 HMaster 單點問題;HMaster沒有單點問題,HBase 中可以啟動多個HMaster,通過 ZooKeeper 的 Master Election 機制保證總有一個 Master 在執行。

3.HMaster

:負責 Table 和 Region 的管理工作;

(1) 管理使用者對 Table 的 CRUD 操作;

(2) 管理 HRegionServer的負載均衡,調整Region 分佈;

(3) 在 RegionSplit 後,負責新Region 分配;

(4) 在 HRegionServer停機後,負責失效 HRegionServer 上的Region 遷移;

4.HRegionServer:HBase 最核心模組,響應使用者IO請求,向 HDFS 中讀寫資料;


        HRegionServer 內部管理了一系列 HRegion物件,每個 HRegion 對應 Table 中的一個Region,HRegion 由多個 HStore 組成,每個 HStore 對應 Table 中的一個 Column Familiy 的儲存。

        HStore 是 HBase 儲存的核心,其中由兩部分構成,一部分是 MemStore,一部分是 StoreFile。StoreFile 檔案數量增長到一定閾值後,會觸發 Compact合併操作,將多個StoreFile 合併成一個 StoreFile,合併過程中會進行版本合併和資料刪除。StoreFile 在完成 Compact 合併操作後,會逐步形成越來越大的 StoreFile,當單個StoreFile 大小超過一定閾值後,會觸發 Split 操作,同時把當前Region 分裂成2個Region,父Region 會下線,新分裂出的2個孩子Region 會被 HMaster 分配到相應的 HRegionServer 上,使得原先1個Region 壓力得以分流到2個Region 上。

二、Table 與Region

Region HBase叢集分佈資料的最小單位

        Region 是部分資料,所以是所有資料的一個自己,但Region包括完整的行,所以Region 是行為單位表的一個子集。

          每個Region 有三個主要要素:

    • 它所屬於哪張表
    • 它所包含的的第一行(第一個Region 沒有首行)
    • 他所包含的最後一行(末一個Region 沒有末行)

        當表初寫資料時,此時表只有一個Region,當隨著資料的增多,Region 開始變大,等到它達到限定的閥值大小時,變化把Region 分裂為兩個大小基本相同的Region,而這個閥值就是StoreFile 的設定大小(引數:hbase.hRegion.max.filesize 新版本預設10G) ,在第一次分裂Region之前,所有載入的資料都放在原始區域的那臺伺服器上,隨著表的變大,Region 的個數也會相應的增加,而Region HBase叢集分佈資料的最小單位

         (但Region 也是由block組成,Region是屬於單一的RegionServer,除非這個RegionServer 宕機,或者其它方式掛掉,再或者執行balance時,才可能會將這部分Region的資訊轉移到其它機器上。)

        這也就是為什麼 Region比較少的時候,導致Region 分配不均,總是分派到少數的節點上,讀寫併發效果不顯著,這就是HBase 讀寫效率比較低的原因。

三、元資料表 .META.和 -ROOT-

         HBase內部維護著兩個元資料表,分別是-ROOT- 和 .META. 表。他們分別維護者當前叢集所有Region 的列表、狀態和位置。

(1) .META. 記錄使用者表的 Region 資訊,可以有多個 Region,.META.會隨需要被Split

(2) -ROOT- 記錄 .META. 表的 Region 資訊,只有一個 Region,-ROOT-永不會被Split

(3) ZooKeeper 中記錄 -ROOT- 表的 Location,.META. 和 -ROOT- 的關係見下圖。


        -ROOT- 表包含.META. 表的Region 列表,因為.META. 表可能會因為超過Region 的大小而進行分裂,所以-ROOT-才會儲存.META.表的Region索引,-ROOT-表是不會分裂的。而.META. 表中則包含所有使用者Region(user-space Region)的列表。表中的項使用Region 名作為鍵。Region 名由所屬的表名、Region 的起始行、建立的時間以及對其整體進行MD5 hash值。

四、Region 定位流程

      演算法:B+樹定位,通過ZooKeeper 來查詢 -ROOT-,然後是.META.,然後找到Table裡的Region。

       Client 訪問使用者資料之前需要訪問 ZooKeeper,然後訪問 -ROOT- 表,接著訪問 .META. 表,最後才能找到使用者資料的位置去訪問。中間需要多次網路操作,不過 Client 端會執行 Cache 快取。

(1) 客戶端client首先連線到ZooKeeper這是就要先查詢-ROOT-的位置。

(2) 然後client通過-ROOT-獲取所請求行所在範圍所屬的.META.Region的位置。

(3) client接著查詢.META.Region來獲取user-space Region所在的節點和位置。

(4) 接著client就可以直接和管理者那個RegionRegionServer進行互動。

        每個行操作可能要訪問三次遠端節點,為了節省這些代價,client會快取他們遍歷-ROOT-和.META. 的位置以及user-space Region的開始行和結束行,這樣每次訪問就不會再從表中去查詢了,但如果變動了怎麼辦?卻是存在這個問題,這樣的話client 會出現錯誤,那此時Region毫無疑問是移動了,這時,client 會再次從.META.查詢Region 的新位置並再次將其放入到快取中去,周而復始。同樣道理如果.META.的Region移動了,client 也才會去-ROOT-表查詢.META.Region的新位置。