HBase之Rowkey設計總結及方舟實戰篇

1、引言
HBase因爲其存儲和讀寫的高性能，在OLAP即時分析中愈來愈發揮重要的做用，在易觀精細化運營產品--易觀方舟也有普遍的應用。做爲Nosql數據庫的一員，HBase查詢只能經過其Rowkey來查詢(Rowkey用來表示惟一一行記錄)，Rowkey設計的優劣直接影響讀寫性能。HBase中的數據是按照Rowkey的ASCII字典順序進行全局排序的,有夥伴可能對ASCII字典序印象不夠深入，下面舉例說明：
假若有5個Rowkey："012", "0", "123", "234", "3"，按ASCII字典排序後的結果爲："0", "012", "123", "234", "3"。（注：文末附經常使用ASCII碼錶）
Rowkey排序時會先比對兩個Rowkey的第一個字節，若是相同，而後會比對第二個字節，依次類推... 對比到第X個字節時，已經超出了其中一個Rowkey的長度，短的Rowkey排在前面。

因爲HBase是經過Rowkey查詢的，通常Rowkey上都會存一些比較關鍵的檢索信息，咱們須要提早想好數據具體須要如何查詢，根據查詢方式進行數據存儲格式的設計，要避免作全表掃描，由於效率特別低。

2、Rowkey設計原則
Rowkey設計應遵循如下原則：
1.Rowkey的惟一原則

必須在設計上保證其惟一性。因爲在HBase中數據存儲是Key-Value形式，若HBase中同一表插入相同Rowkey，則原先的數據會被覆蓋掉(若是表的version設置爲1的話)，因此務必保證Rowkey的惟一性

1. Rowkey的排序原則

   HBase的Rowkey是按照ASCII有序設計的，咱們在設計Rowkey時要充分利用這點。好比視頻網站上對影片《泰坦尼克號》的彈幕信息，這個彈幕是按照時間倒排序展現視頻裏，這個時候咱們設計的Rowkey要和時間順序相關。可使用"Long.MAX_VALUE - 彈幕發表時間"的 long 值做爲 Rowkey 的前綴

2. Rowkey的散列原則

   咱們設計的Rowkey應均勻的分佈在各個HBase節點上。拿常見的時間戳舉例，假如Rowkey是按系統時間戳的方式遞增，Rowkey的第一部分若是是時間戳信息的話將形成全部新數據都在一個RegionServer上堆積的熱點現象，也就是一般說的Region熱點問題， 熱點發生在大量的client直接訪問集中在個別RegionServer上（訪問多是讀，寫或者其餘操做），致使單個RegionServer機器自身負載太高，引發性能降低甚至Region不可用，常見的是發生jvm full gc或者顯示region too busy異常狀況，固然這也會影響同一個RegionServer上的其餘Region。

一般有3種辦法來解決這個Region熱點問題：
ΩΩ一、Reverse反轉

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

反轉Rowkey的例子一般以手機舉例，能夠將手機號反轉後的字符串做爲Rowkey，這樣的就避免了以手機號那樣比較固定開頭(137x、15x等)致使熱點問題，
這樣作的缺點是犧牲了Rowkey的有序性。

ΩΩ二、Salt加鹽

Salting是將每個Rowkey加一個前綴，前綴使用一些隨機字符，使得數據分散在多個不一樣的Region，達到Region負載均衡的目標。
好比在一個有4個Region(注：以 [ ,a)、[a,b)、[b,c)、[c, )爲Region起至)的HBase表中，
加Salt前的Rowkey：abc00一、abc00二、abc003
咱們分別加上a、b、c前綴，加Salt後Rowkey爲：a-abc00一、b-abc00二、c-abc003 
能夠看到，加鹽前的Rowkey默認會在第2個region中，加鹽後的Rowkey數據會分佈在3個region中，理論上處理後的吞吐量應是以前的3倍。因爲前綴是隨機的，讀這些數據時須要耗費更多的時間，因此Salt增長了寫操做的吞吐量，不過缺點是同時增長了讀操做的開銷。