分區概念

接觸過HBase的同學都知道，HBase每張表在底層存儲上是由至少一個Region組成，Region實際上就是HBase表的分區。HBase新建一張表時默認Region即分區的數量為1，一般在生產環境中我們都會手動給Table提前做 "預分區"，使用合適的分區策略創建好一定數量的分區并使分區均勻分布在不同regionserver上。一個分區在達到一定大小時會自動Split，一分為二。

通常情況下，生產環境的每個regionserver節點上會有很多Region存在，我們一般比較關心每個節點上的Region數量，主要為了防止HBase分區過多影響到集群的穩定性。 

分區過多的影響

分區過多會帶來很多不好的影響，主要體現在以下幾個方面。 

1. 頻繁刷寫

我們知道Region的一個列族對應一個MemStore，假設HBase表都有統一的1個列族配置，則每個Region只包含一個MemStore。通常HBase的一個MemStore默認大小為128 MB，見參數hbase.hregion.memstore.flush.size。當可用內存足夠時，每個MemStore可以分配128 MB空間。當可用內存緊張時，假設每個Region寫入壓力相同，則理論上每個MemStore會平均分配可用內存空間。

因此，當節點Region過多時，每個MemStore分到的內存空間就會很小。這個時候，寫入很小的數據量就會被強制Flush到磁盤，將會導致頻繁刷寫。頻繁刷寫磁盤，會對集群HBase與HDFS造成很大的壓力，可能會導致不可預期的嚴重后果。 

2. 壓縮風暴

因Region過多導致的頻繁刷寫，將在磁盤上產生非常多的HFile小文件，當小文件過多的時候HBase為了優化查詢性能就會做Compaction操作，合并HFile減少文件數量。當小文件一直很多的時候，就會出現 "壓縮風暴"。Compaction非常消耗系統io資源，還會降低數據寫入的速度，嚴重的會影響正常業務的進行。 

3. MSLAB內存消耗較大

MSLAB（MemStore-local allocation buffer）存在于每個MemStore中，主要是為了解決HBase內存碎片問題，默認會分配 2 MB 的空間用于緩存最新數據。如果Region數量過多，MSLAB總的空間占用就會比較大。比如當前節點有1000個包含1個列族的Region，MSLAB就會使用1.95GB的堆內存，即使沒有數據寫入也會消耗這么多內存。 

4. Master Assign Region 時間較長

HBase Region過多時Master分配Region的時間將會很長。特別體現在重啟HBase時Region上線時間較長，嚴重的會達到小時級，造成業務長時間等待的后果。

5. 影響MapReduce并發數

當使用MapReduce操作HBase時，通常Region數量就是MapReduce的任務數，Region數量過多會導致并發數過多，產生過多的任務。任務太多將會占用大量資源，當操作包含很多Region的大表時，占用過多資源會影響其他任務的執行。

計算合理分區數量

關于每個regionserver節點分區數量大致合理的范圍，HBase官網上也給出了定義：

Generally less regions makes for a smoother running cluster (you can always manually split the big regions later (if necessary) to spread the data, or request load, over the cluster); 20-200 regions per RS is a reasonable range.

可見，通常情況下每個節點擁有20~200個Region是比較正常的。借鑒于20~200這個區間范圍，我們接下來具體討論。

實際上，每個RegionServer的最大Region數量由總的MemStore內存大小決定。我們知道每個Region的每個列族對應一個MemStore，假設HBase表都有統一的1個列族配置，那么每個Region只包含一個MemStore。一個MemStore大小通常在128~256 MB，見參數hbase.hregion.memstore.flush.size。默認情況下，RegionServer會將自身堆內存的40%（見參數hbase.regionserver.global.memstore.size）供給節點上所有MemStore使用，如果所有MemStore的總大小達到該配置大小，新的更新將會被阻塞并且會強制刷寫磁盤。因此，每個節點最理想的Region數量應該由以下公式計算（假設HBase表都有統一的列族配置）：

Region.nums = ((RS memory) * (total memstore fraction)) / ((memstore size)*(column families))

其中：

• RS memory：表示regionserver堆內存大小，即HBASE_HEAPSIZE。

• total memstore fraction：表示所有MemStore占HBASE_HEAPSIZE的比例，HBase0.98版本以后由hbase.regionserver.global.memstore.size參數控制，老版本由hbase.regionserver.global.memstore.upperLimit參數控制，默認值0.4。

• memstore size：即每個MemStore的大小，原生HBase中默認128M。

• column families：即表的列族數量，通常情況下只設置1個，最多不超過3個。

舉個例子，假如一個集群中每個RegionServer的堆內存是32GB，那么節點上最理想的Region數量應該是32768*0.4/128 ≈ 102，所以，當前環境中單節點理想情況下大概有102個Region。

這種最理想情況是假設每個Region上的填充率都一樣，包括數據寫入的頻次、寫入數據的大小，但實際上每個Region的負載各不相同，可能有的Region特別活躍負載特別高，有的Region則比較空閑。所以，通常我們認為2~3倍的理想Region數量也是比較合理的，針對上面舉例來說，大概200~300個Region算是合理的。

如果實際的Region數量比2~3倍的計算值還要多，就要實際觀察Region的刷寫、壓縮情況了，Region越多則風險越大。經驗告訴我們，如果單節點Region數量過千，集群可能存在較大風險。