Hbase 設計原則

hbase 所謂的三維有序儲存的三維是指：rowkey（行主鍵），column key(columnFamily+qualifier)，timestamp(時間戳)三部分組成的三維有序儲存。

rowkey是行的主鍵，而且hbase只能用個rowkey，或者一個rowkey範圍即scan來查詢資料。所以 rowkey的設計是至關重要的，關係到你 應用層 的查詢效率。

rowkey是以字典順序排序的，儲存的是 位元組碼。

Rowkey設計原則

1.Rowkey的唯一原則

必須在設計上保證其唯一性。 由於在HBase中資料儲存是Key-Value形式，若HBase中同一表插入相同Rowkey，則原先的資料會被覆蓋掉(如果表的version設定為1的話)，所以務必保證Rowkey的唯一性.

2.Rowkey的排序原則

HBase的Rowkey是按照ASCII有序設計的，我們在設計Rowkey時要充分利用這點。

3.Rowkey的雜湊原則

我們設計的Rowkey應均勻的分佈在各個HBase節點上。

拿常見的時間戳舉例，假如Rowkey是按系統時間戳的方式遞增，Rowkey的第一部分如果是時間戳資訊的話將造成所有新資料都在一個RegionServer上堆積的熱點現象，也就是通常說的Region熱點問題， 熱點發生在大量的client直接訪問集中在個別RegionServer上（訪問可能是讀，寫或者其他操作），導致單個RegionServer機器自身負載過高，引起效能下降甚至Region不可用，常見的是發生jvm full gc或者顯示region too busy異常情

況，當然這也會影響同一個RegionServer上的其他Region。

Region熱點問題

1、Reverse反轉

針對固定長度的Rowkey反轉後儲存，這樣可以使Rowkey中經常改變的部分放在最前面，可以有效的隨機Rowkey。

2、Salt加鹽

比如在一個有4個Region(注：以 [ ,a)、[a,b)、[b,c)、[c, )為Region起至)的HBase表中， 加Salt前的Rowkey：abc001、abc002、abc003
我們分別加上a、b、c字首，加Salt後Rowkey為：a-abc001、b-abc002、c-abc003

可以看到，加鹽前的Rowkey預設會在第2個region中，加鹽後的Rowkey資料會分佈在3個region中，

理論上處理後的吞吐量應是之前的3倍。由於字首是隨機的，讀這些資料時需要耗費更多的時間，所以Salt增加了寫操作的吞吐量。

3、Hash雜湊或者Mod

用Hash雜湊來替代隨機Salt字首的好處是能讓一個給定的行有相同的字首，這在分散了Region負載的同時，使讀操作也能夠推斷。確定性Hash(比如md5後取前4位做字首)能讓客戶端重建完整RowKey，可以使用get操作直接get想要的行。

4.Rowkey的長度原則

Rowkey長度設計原則：Rowkey是一個二進位制，Rowkey的長度被很多開發者建議說設計在10~100個位元組，建議是越短越好。

原因有兩點：

其一是HBase的持久化檔案HFile是按照KeyValue儲存的，如果Rowkey過長比如500個位元組，1000萬列資料光Rowkey就要佔用500*1000萬=50億個位元組，將近1G資料，這會極大影響HFile的儲存效率；

其二是MemStore快取部分資料到記憶體，如果Rowkey欄位過長記憶體的有效利用率會降低，系統無法快取更多的資料，這會降低檢索效率；

需要指出的是不僅Rowkey的長度是越短越好，而且列族名、列名等儘量使用短名字，因為HBase屬於列式資料庫，這些名字都是會寫入到HBase的持久化檔案HFile中去，過長的Rowkey、列族、列名都會導致整體的儲存量成倍增加。

推薦閱讀：

https://blog.csdn.net/zjjcchina/article/details/122620415