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就可以直接和管理者那個Region的RegionServer進行交互。
每個行操作可能要訪問三次遠程節點，爲了節省這些代價，client會緩存他們遍歷-ROOT-和.META. 的位置以及user-space Region的開始行和結束行，這樣每次訪問就不會再從表中去查詢了，但如果變動了怎麼辦？卻是存在這個問題，這樣的話client 會出現錯誤，那此時Region毫無疑問是移動了，這時，client 會再次從.META.查找Region 的新位置並再次將其放入到緩存中去，週而復始。同樣道理如果.META.的Region移動了，client 也纔會去-ROOT-表查詢.META.Region的新位置。