Hbase優化之預分割槽設計
1. 背景
HBase建表時預設只有一個region，這個region的rowkey是沒有邊界的，即沒有startkey和endkey。在資料寫入時，所有資料都會寫入這個預設的region。隨著資料量的不斷增加，這個預設的region會越來越大，當達到某個閾值會自動split成為2個region。此外，頻繁的region split操作會嚴重影響Hbase叢集的效能。
所以，一般推薦在建表時進行預分割槽，充分考慮rowkey的分佈做出合理的預分割槽方案。
2. 不使用預分割槽存在的問題
2.1 寫熱點問題（所有新資料都往一個region上寫）；
首先，是熱點寫，我們總是會往最大的start-key所在的region寫東西，因為我們的rowkey總是會比之前的大，並且hbase的是按升序方式排序的。所以寫操作總是被定位到無上界的那個region中。
其次，由於寫熱點，我們總是往最大start-key的region寫記錄，之前分裂出來的region不會再被寫資料，有點被打進冷宮的趕腳，它們都處於半滿狀態，這樣的分佈也是不利的。
2.2 region split會消耗寶貴的叢集I/O資源
如果在寫比較頻率的場景下，資料增長快，split的次數也會增多，由於split是比較耗時耗資源的，所以我們並不希望這種事情經常發生。
3. Hbase預分割槽
Hbase預分割槽是指，在建表的時候建立多個空region，並確定每個region的start-key和end-key，這樣只需保證rowkey能夠均勻的分佈在每個Region中，就能有效避免寫熱點問題。例如，使用隨機雜湊與預分割槽結合的方式，預分割槽一開始就預建好了一部分region，這些region都維護著自已的start-end keys，再配合上隨機雜湊，寫資料能均等地命中這些預建的region，就能解決上面的問題，大大地提高效能。
4. 預分割槽的設計
4.1 設計原則
Hbase的預分割槽主要根據Rowkey的分佈情況來確認，結合Hbase叢集配置情況來確定。
4.2 Region個數上限
RegionServer的region數目取決於memstore的記憶體使用。memstore的數量由hstore決定，Hstore的資料由建立表時的指定的列族個數決定。所以，每個region的memstore的個數 = 表的列族的個數 。可以通過配置來修改memstore佔用記憶體的大小，一般設定在 128 M – 256M之間，預設為128M。
每一個Region都儲存著一些列(a set of rows)。根據其列族的不同，將這些列資料儲存在相應的列族中(Column Family，簡寫CF)。不同的CFs中的資料儲存在各自的HStore中，HStore由一個Memstore及一系列HFile組成。Memstore位於RS的主記憶體中，而HFiles被寫入到HDFS中。
大資料量情況下越發需要並行處理，因此我們往往希望源表的region的個數多一些。但是同時也要考慮叢集的承載能力，HBase的region個數上限可以參考官網給出的如下公式：
((RS Xmx) *hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size *(# column families))
((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))
其中，RS Xmx是regionserver的記憶體堆疊大小，官網建議每臺20~24或更小，因為過大的記憶體會導致GC時間過長。
注意：
實際測試發現大於這個數一兩倍也沒太大的問題。 一個HBase表包含一至多個region，那麼表的數目上限也是可以估算出來的。
例如：
如果 一個RegionServer配置的記憶體是16G，使用預設配置（ hbase預設regionserver分給memstore的比例是0.4 ， 預設的menstore的佔用128M記憶體 ）， 一個列族，那麼這個regionServer下的region的個數大約為 16384 * 0.4 / （128*1） = 51個，實際測試大於這個數一兩倍也沒太大的問題。 一個HBase表包含一至多個region，那麼表的數目上限也是可以估算出來的。
4.3 Region的大小
對於生產場景中大表，最大的region大小主要是受compactions 的限制，大量大HFile的compact會降低群集效能。目前，該建議的最大region大小為10-20GB，而5-10GB是最優。