HBase框架基礎（五）

* HBase框架基礎（五）

本節主要介紹HBase中關於分區的一些知識。

* HBase的RowKey設計

咱們爲何要討論rowKey的設計？或者說爲何不少工做崗位要求有rowKey的優化設計經驗？這個咱們須要簡單的談一談HBase的存儲情景。

 

 

簡單討論：

** 一個Table表能夠劃分爲多個Region

** 每一個Regin維護着不一樣的範圍的rowKey，如何維護呢？Region提供了StartKey和EndKey來表示某一個範圍內的rowKey，好比，咱們有3個Region，維護的rowKey範圍是：

 

 

假設，當新插入一條數據的rowKey是15時，該條數據就會自動的進入Region2進行保存，覺得15這個rowKey符合11~20這個維護範圍。

好，明白了這個原理後，問題來了。在以前咱們歷來沒有作過什麼StartKey、EndKey啊，那麼在這樣的狀況下，全部的rowKey就會被混在一塊兒存儲，可是Region愈來愈大怎麼辦呢，不是會分割麼，混在一切怎麼分割呢？接下來咱們對每個可能的疑問進行簡單說明；

Question：如何分割？

Answer：一刀從中間劈開，從而將一個Region變成了兩個Region。

Question：它怎麼知道哪裏是中間？

Answer：HBase會將存儲的RowKey進行升序排序，因此它知道哪裏是中間（注意這個排序不僅是數字，字符串等等也是能夠的）。

Question：那我默認用的挺爽啊，沒啥問題啊，設計範圍幹嗎玩意？

Answer：好，假設你如今存了不少數據，rowKey在不停地增大，大到必定程度，劈開！而後又有新的數據進來，會put到劈開後的Region裏，而後再劈開，你懂得，最後就會致使每次越日後Region的分區越臃腫，而前邊的Region就會比較靜止，明顯出現負載分配不均的狀況。

設計方式：

其實設計這個東西主要是可以讓數據平均分配到全部的Region中，那這就意味着應該讓rowKey的StartKey和EndKey分佈的儘量隨機。

一、生成隨機數、Hash、散列值

好比：

本來rowKey爲1001的，MD5後變成：b8c37e33defde51cf91e1e03e51657da

本來rowKey爲3001的，MD5後變成：908c9a564a86426585b29f5335b619bc

本來rowKey爲5001的，MD5後變成：03b264c595403666634ac75d828439bc

在作此操做以前，通常咱們會選擇從數據集中抽取樣本，來決定什麼樣的rowKey來Hash後做爲每一個分區的臨界值。

二、字符串反轉

好比：

20170524000001轉成10000042507102

20170524000002轉成20000042507102

這樣也能夠在必定程度上散列逐步put進來的數據。

三、字符串拼接

好比：

20170524000001_a12e

20170524000001_93i7

等等

* HBase的預分區

在想好怎麼設計rowKey後，就能夠開始預分區了。

方式一：

hbase> create 'table1','partition1',SPLITS => ['1000', '2000', '3000', '4000']

建立後，來到網頁段查看：

 

留意紅藍框內容，出現了5個分區

再點進去看一下：

 

尚未插入數據，已經出現了5個預分區，分佈在不一樣的集羣節點上

方式二：

hbase> create 'table2','partition2',SPLITS_FILE => 'splits.txt'

splits.txt文件中對應的內容好比：

aaaa

bbbb

cccc

dddd

成功後，如圖：

 

注意觀察一下分區的分佈狀況

方式三：

hbase> create 'table3', 'partition3', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'} 

這種方式生成了一個16進制的字符串來做爲分區字段，如圖：

 

 

方式四：

Java API

 

 

 

 

* 總結

咱們仔細研究rowKey的預分區，主要是爲了不出現熱點話題這樣的現象，以此來提升集羣存儲性能，後面我將根據一些項目來進一步說明此設計理念。

---

我的微博：http://weibo.com/seal13

QQ大數據技術交流羣（廣告勿入）：476966007

做者：Z盡際連接：https://www.jianshu.com/p/1613df3a3436來源：簡書著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。