HBase的 rowkey 設計原則

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時要充分利用這點。比如視訊網站上對影片《泰坦尼克号》的彈幕資訊，這個彈幕是按照時間倒排序展示視訊裡，這個時候我們設計的Rowkey要和時間順序相關。可以使用"Long.MAX_VALUE - 彈幕發表時間"的 long 值作為 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。

反轉Rowkey的例子通常以手機舉例，可以将手機号反轉後的字元串作為Rowkey，這樣的就避免了以手機号那樣比較固定開頭(137x、15x等)導緻熱點問題，這樣做的缺點是犧牲了Rowkey的有序性。

2、Salt加鹽

Salt是将每一個Rowkey加一個字首，字首使用一些随機字元，使得資料分散在多個不同的Region，達到Region負載均衡的目标。

比如在一個有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、列族、列名都會導緻整體的存儲量成倍增加。