前面文章講到 Region 的概念，它是 HBase 集群的負載均衡和數據分發的基本單元。當 HBase中 表的容量非常龐大時，用戶就需要將表中的內容分佈到多臺機器上。那麼，需要根據行鍵的值對錶中的行進行劃分，每個行區間構成一個 Region，一個 Region 包含了位於某個閾值區間的所有數據。
下面將介紹 Region 在集群運行過程中進行合併、拆分及分配的過程。
HFile 合併
每個 RegionServer 包含多個 Region，而每個 Region 又對應多個 Store，每一個 Store 對應表中一個列族的存儲，且每個 Store 由一個 MemStore 和多個 StoreFile 文件組成。
StoreFile 在底層文件系統中由 HFile 實現，也可以把 Store 看作由一個 MemStore 和多個 HFile 文件組成。MemStore 充當內存寫緩存，默認大小 64MB，當 MemStore 超過閾值時，MemStore 中的數據會刷新到一個新的 HFile 文件中來持久化存儲。
久而久之，每個 Store 中的 HFile 文件會越來越多，I/O 操作的速度也隨之變慢，讀寫也會延時，導致慢操作。因此，需要對 HFile 文件進行合併，讓文件更緊湊，讓系統更有效率。
HFile 的合併分為兩種類型，分別是 Minor 合併和 Major 合併。這兩種合併都發生在 Stow 內部，不是 Region 的合併，如下圖所示。
Minor 合併
Minor 合併是把多個小 HFile 合併生成一個大的 HFile。
執行合併時，HBase 讀出已有的多個 HFile 的內容，把記錄寫入一個新文件中。然後把新文件設置為激活狀態，並標記舊文件為刪除。
在 Minor 合併中，這些標記為刪除的舊文件是沒有被移除的，仍然會出現在 HFile 中，只有在進行 Major 合併時才會移除這些舊文件。對需要進行 Minor 合併的文件的選擇是觸發式的，當達到觸發條件才會進行 Minor 合併，而觸發條件有很多，例如， 在將 MemStore 的數據刷新到 HFile 時會申請對 Store下符合條件的 HFile 進行合併，或者定期對 Store 內的 HFile 進行合併。
另外對選擇合併的 HFile 也是有條件的，如下表所示。
在執行 Minor 合併時，系統會根據上述配置參數選擇合適的 HFile 進行合併。Minor 合併對 HBase 的性能是有輕微影響的，因此，合併的 HFile 數量是有限的，默認最多為 10 個。
Major 合併
Major 合併針對的是給定 Region 的一個列族的所有 HFile，如圖 1 所示。它將 Store 中的所有 HFile 合併成一個大文件，有時也會對整個表的同一列族的 HFile 進行合併，這是一個耗時和耗費資源的操作，會影響集群性能。
一般情況下都是做 Minor 合併，不少集群是禁止 Major 合併的，只有在集群負載較小時進行手動 Major 合併操作，或者配置 Major 合併週期，默認為 7 天。另外，Major 合併時會清理 Minor 合併中被標記為刪除的 HFile。
Region 拆分
Region 拆分是 HBase 能夠擁有良好擴展性的最重要因素。一旦 Region 的負載過大或者超過閾值時，它就會被分裂成兩個新的 Region，如圖 2 所示。
這個過程是由 RegionServer 完成的，其拆分流程如下。
- 將需要拆分的 Region下線，阻止所有對該 Region 的客戶端請求，Master 會檢測到 Region 的狀態為 SPLITTING。
- 將一個 Region 拆分成兩個子 Region，先在父 Region下建立兩個引用文件，分別指向 Region 的首行和末行，這時兩個引用文件並不會從父 Region 中複製數據。
- 之後在 HDFS 上建立兩個子 Region 的目錄，分別複製上一步建立的引用文件，每個子 Region 分別佔父 Region 的一半數據。複製登錄完成後刪除兩個引用文件。
- 完成子 Region 創建後，向 Meta 表發送新產生的 Region 的元數據信息。
- 將 Region 的拆分信息更新到 HMaster，並且每個 Region 進入可用狀態。
以上是 Region 的拆分過程，那麼，Region 在什麼時候才會觸發拆分呢？常用的拆分策略如下表所示
上表中列舉的拆分策略中，拆分點的定義是一致的，即當 Region 中最大 Store 的大小大於設置閾值之後才會觸發拆分。而在不同策略中，閾值的定義是不同的，且對集群中 Region 的分佈有很大的影響。
Region 合併
從 Region 的拆分過程中可以看到，隨著表的增大，Region 的數量也越來越大。如果有很多 Region，它們中 MemStore 也過多，會頻繁出現數據從內存被刷新到 HFile 的操作，從而會對用戶請求產生較大的影響，可能阻塞該 Region 服務器上的更新操作。過多的 Region 會增加 ZooKeeper 的負擔。
因此，當 Region 服務器中的 Region 數量到達閾值時，Region 服務器就會發起 Region 合併，其合併過程如下。
- 客戶端發起 Region 合併處理，併發送 Region 合併請求給 Master。
- Master 在 Region 服務器上把 Region 移到一起，併發起一個 Region 合併操作的請求。
- Region 服務器將準備合併的 Region下線，然後進行合併。
- 從 Meta 表刪除被合併的 Region 元數據，新的合併了的 Region 的元數據被更新寫入 Meta 表中。
- 合併的 Region 被設置為上線狀態並接受訪問，同時更新 Region 信息到 Master。
Region 負載均衡
當 Region 分裂之後，Region 服務器之間的 Region 數量差距變大時，Master 便會執行負載均衡來調整部分 Region 的位置，使每個 Region 服務器的 Region 數量保持在合理範圍之內，負載均衡會引起 Region 的重新定位，使涉及的 Region 不具備數據本地性。
Region 的負載均衡由 Master 來完成，Master 有一個內置的負載均衡器，在默認情況下，均衡器每 5 分鐘運行一次，用戶可以配置。負載均衡操作分為兩步進行：首先生成負載均衡計劃表， 然後按照計劃表執行 Region 的分配。
執行負載均衡前要明確，在以下幾種情況時，Master 是不會執行負載均衡的。
- 均衡負載開關關閉。
- Master 沒有初始化。
- 當前有 Region 處於拆分狀態。
- 當前集群中有 Region 服務器出現故障。
Master 內部使用一套集群負載評分的算法，來評估 HBase 某一個表的 Region 是否需要進行重新分配。這套算法分別從 Region 服務器中 Region 的數目、表的 Region 數、MenStore 大小、 StoreFile 大小、數據本地性等幾個維度來對集群進行評分，評分越低代表集群的負載越合理。
確定需要負載均衡後，再根據不同策略選擇 Region 進行分配，負載均衡策略有三種，如下表所示。
根據上述策略選擇分配 Region 後再繼續對整個表的所有 Region 進行評分，如果依然未達到標準，循環執行上述操作直至整個集群達到負載均衡的狀態。
閱讀更多 會飛的魚go 的文章
