HBase官方文檔 之 Region的相關知識

HBase是以Region爲最小的存儲和負載單元（這裏可不是HDFS的存儲單元），所以Region的負載管理，關係到了數據讀寫的性能。先拋開Region如何切分不說，看看Region是如何分配到各個RegionServer的吧。

更多內容參考——個人大數據學習之路

Region在HBase中的角色

Table                    (HBase表)
    Region               (Region)
        Store            (每一個Region的每一個列族獨立存儲)
            MemStore     (MemStore每一個Store有一個，用於在內存中保存數據)
            StoreFile    (StoreFiles對應於Store，是具體存儲在磁盤的文件)
                Block    (Blocks是HDFS上的存儲單元)

Region的管理

通常來講對於每一個Region Server，官方推薦最好是控制Region的數量在20-200個、大小在5-20Gb左右。

爲何要控制region的數量呢？

1. 默認MemStore須要2MB的空間用來存儲數據，若是一臺機器上有1000個Region，每一個有兩個列族，那就須要3.9GB的數據。
2. 若是同時以某個相同的頻率更新全部的Region，當同時進行數據持久化的時候也會有問題
3. Master對於維護大量的Region有很大的性能問題，由於在平衡Region的時候，在ZK中的操做都是同步的。
4. Region Server須要維護Region的索引信息

那麼Region Server是如何管理Region的呢？

啓動

1. Master建立AssignmentManager
2. AssignmentManager查看當前的Region分配信息
3. 知足條件後，經過LoadBalancerFactory建立LoadBalancer，1.0後的版本默認是StochasticLoadBalancer
4. 判斷是否須要進行負載平衡，並更新相關信息

容錯

1. 若是平衡負載的時候報錯，RegionServer會直接關閉
2. Master檢測到resgion Server異常
3. 重啓Region server
4. 請求進行重試；超時會請求其餘的節點

Region的狀態機

Hbase中每一個Region本身維護其在hbase:meta表中的信息。

狀態機中包括下面幾種狀態：

• offline：region離線沒有開啓
• opening：region正在被打開
• open：region正在打開，而且region server通知了master
• failed_open：regionserver打開失敗
• closing：region正在被關閉
• closed：regionserver正在關閉，而且已經通知了master
• failed_close：regionserver關閉失敗了
• splitting：region server通知master，region正在被切分
• split：region server通知master，region已經被切分完了
• spliting_new：region是切分過程當中新建的文件
• merging：regionserver通知master region正在合併
• merged：regionserver通知master region合併完了
• merging_new：region是合併新建出來的

不一樣的顏色是不一樣含義：

• 棕色：離線狀態，屬於一種短暫的瞬間狀態（好比關閉後開啓的中間狀態）、中止狀態或者初始化的時候的狀態
• 綠色：正常的狀態，能夠支持請求訪問
• 藍色：短暫的狀態
• 紅色：失敗
• 黃色：合併或者切分的狀態
• 灰色：剛開始的狀態

各個序號表明不一樣的操做場景：

1. Master向region server發起region從offline到openning的狀態請求，regionserver若是沒有收到，master會嘗試重試幾回。RegionServer接收到請求後，regin狀態變成opening
2. 若是Master發起的open請求超過次數，那麼不管region server是否已經打開region，master都會命令region server關閉文件，狀態變爲closing
3. 當region server打開region後，會嘗試通知master，讓他把region狀態修改成open，並通知regsion server。這樣region才能變爲open狀態
4. 若是region server打開四百，會嘗試通知master。master會把region的狀態變動爲closed，而且嘗試去其餘的region server打開region
5. 若是master嘗試幾回後，都沒有打開region，就會把狀態變動爲failed_open
6. master通知region server關閉region，若是沒有反應，會重試
7. 若是region server沒有在線，會拋出異常。而後region的狀態會變成closing
8. 若是region server在線，可是好幾回都沒響應，就會更新狀態爲failed_close
9. 若是region server收到請求，而且關閉了region，那麼會通知master把region狀態修改成closed。而且把region分配給其餘的server
10. 在分配以前，master會先把region從closed狀態轉換爲offline
11. 若是region server正在切分region，會通知mastere。master把region狀態由open變爲splitting，而且把新增兩個region的信息，這兩個region都是splitting_new狀態
12. 若是region切分紅功，當前的region狀態從splitting變成split；新增的兩個region狀態從splitting_new變成open
13. 若是切分失敗，狀態從splitting回到open，兩個region也從splitting_new變成offline
14. 若是region server想要合併兩個region，那麼也會先通知master。master把兩個region從open變成merging，而後增長一個新的region，狀態爲merging_new
15. 若是合併成功, 舊的region從merging變爲merged，新的region從merging_new變爲open
16. 若是合併失敗，region的狀態從merging變回open，新建的一個region狀態又變成offline
17. 若是管理員經過hbase shell操做分配region，master會嘗試把失敗的狀態變成close

Region的數據本地性

數據本地性經過來自於hdfs client和hdfs block存儲的節點差別性，針對數據備份來講，會按照下面的機制進行：

1. 第一個備份會優先卸載本地node節點上
2. 第二個備份會隨機選擇一個不一樣的機架
3. 第三個備份會在第二個備份所在的機架上，再隨機選擇一個節點
4. 若是還有其餘的備份節點，就在集羣中隨機選擇了。

這樣Hbase在刷新或者壓縮時，能夠體現數據的本地性。若是一個region server出現故障，那麼就沒有數據本地性可言了，由於它的備份都在其餘的節點上。

Region的切分

HBase會配置一個切分的閾值，當到達閾值後，就會執行region的切分。Master不會參與Region的切分，切分由Region Server獨立完成。執行切分的時候，會先把region下線，而後在meta表中增長子region的信息，最後通知給master。

默認使用的切分策略是IncreasingToUpperBoundRegionSplitPolicy（1.2.0版本），經過修改配置能夠切換切分規則：

<property>
 <name>hbase.regionserver.region.split.policy</name>
 <value>org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy</value>
</property>

也能夠經過Admin API指定規則:

HTableDescriptor tableDesc = new HTableDescriptor("test");
tableDesc.setValue(HTableDescriptor.SPLIT_POLICY, ConstantSizeRegionSplitPolicy.class.getName());
tableDesc.addFamily(new HColumnDescriptor(Bytes.toBytes("cf1")));
admin.createTable(tableDesc);

或者經過HBase shell管理：

hbase> create 'test', {METHOD => 'table_att', CONFIG => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},
{NAME => 'cf1'}

也能夠經過HBaseConfiguration來配置：

HTableDescriptor myHtd = ...;
myHtd.setValue(HTableDescriptor.SPLIT_POLICY, MyCustomSplitPolicy.class.getName());

Region的手動切分

Region的切分能夠在表建立的時候來執行，也可已在後期來作。最好是在設計表結構的時候，就把切分的規則考慮進去。由於：

• 若是你的數據rowkey是隨着時間自增加的，那麼全部的新數據都會寫在最後一個Region中，這樣會致使老是最後一個region是熱點，而其餘的全部region基本都閒置了。
• 有的時候是一些意外的狀況致使的熱點問題，好比table中存儲的是每一個網頁對應的點擊日誌，若是一個網頁很受歡迎，那麼它對應的region將會成爲熱點。
• 當集羣的region不少的時候，想要加快加載數據的速度
• 在批量導入的時候，可能會形成region熱點寫

設計切分點

默認HBase都是基於Rowkey的字符進行切分的。若是rowkey是經過數字開頭，那麼會按照數字的範圍進行切分；若是是字母，則會經過它的ASCII碼進行切分。用戶也能夠自定義切分的算法，好比HexStringSplit經過轉換成十六進制進行切分。

Region的合併

Master和RegionServer都會參與Region的合併。通常是Client發送合併的請求到Master，而後Master把須要合併的region移動到須要移動比例最高的那個Regsion Server上。好比如今有ABC3個Region Server，A有2個Region，B和C都只有一個，那麼會把Region都轉移到A Server，再執行合併操做。跟切分的過程同樣，也須要先將region設置離線，而後執行合併，再去更新meta表信息。

下面是Hbase shell中合併的例子：

$ hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME'
$ hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME', true

合併操做是異步操做，發送請求後，客戶端這邊不須要登到合併結束。

第三個參數，表示是否強制合併。由於默認合併操做只能針對相鄰的region，force參數能夠強制跨Region的合併。