HBase Rowkey設計規範

1.Rowkey是什麼

能夠理解爲關係型數據庫MySQL Oracle的主鍵,用於標識惟一的行。
徹底是由用戶指定的一串不重複的字符串。
HBase中的數據永遠是根據Rowkey的字典排序來排序的。

2.Rowkey的做用

讀寫數據時 經過 RowKey 找到 對應 的 Region，例如須要查找一條數據確定須要知道他的RowKey ，寫數據的時候也要根據RowKey 來寫。
MemStore中的數據按Rowkey字典順序排序，寫數據的時候會先將數據放到MemStore也就是內存，內存中的數據是按照Rowkey字典順序排序的。
HFile中的數據按RowKey字典順序排序，內存中的數據最後也會持久化到磁盤中，磁盤的數據HFile也是按RowKey字典順序排序。

3.RowKey對查詢的影響

例：RowKey由uid+phone+name組成

1.能夠很好的支持的場景

• uid=111 AND phone = 123 AND name = abc

• uid=111 AND phone = 123

• uid=111 AND phone = 12?

• uid=111

  這種場景下咱們都指定了uid部分,也就是RowKey的第一部分,第一種查詢的RowKey是完整的格式,因此查詢效率是最好的,後邊的三個雖然沒有指定完整RowKey,可是查詢的支持度也還不錯.

2.難支持的場景

• phone = 123 AND name = abc

• phone = 123

• name = abc

  這種場景下並無指定RowKey的第一部分uid,只經過phone跟name去作查詢,也就是不指定先導部分,那麼這種場景會致使HBase的查詢的時候去進行全表掃描,下降了查詢效率.

4.RowKey對Region劃分影響

HBase表的數據是按照RowKey來分散到不一樣的Region,不合理的RowKey設計會致使熱點問題,熱點問題是大量的Client直接訪問集羣的一個或極少數個節點,而集羣中的其餘節點卻處於相對空閒的狀態,從而影響對HBase表的讀寫性能.

5.RowKey的設計技巧

1.Salting(加鹽)

Salting的原理是將固定長度的隨機數放在行鍵的起始處,具體就是給 rowkey 分配一個隨機前綴 以使得它和以前排序不一樣。分配的前綴種類數量應該和你想使數據分散到不一樣的 region 的數量一致。 若是你有一些 熱點 rowkey 反覆出如今其餘分佈均勻的 rwokey 中，加鹽是頗有用的。

例:假如你有下列 rowkey，你表中每個 region 對應字母表中每個字母。 以 ‘a’ 開頭是同一個region, 'b’開頭的是同一個region。在表中，全部以 'f’開頭的都在同一個 region， 它們的 rowkey 像下面這樣：

foo0001 a-foo0001

foo0002 ===>    b-foo0002

foo0003 c-foo0003

foo0004 d-foo0004

假如你須要將上面這個 region 分散到 4個 region。你能夠用4個不一樣的鹽：‘a’, ‘b’, ‘c’, ‘d’.在這個方案下，每個字母前綴都會在不一樣的 region 中。加鹽以後，就像上邊的例子.

因此，你能夠向4個不一樣的 region 寫，理論上說，若是全部人都向同一個region 寫的話，你將擁有以前4倍的吞吐量。

優缺點:因爲前綴是隨機生成的,所以想要按照字典順序找到這些行,則須要作更多的工做,從這個角度上看,salting增長了寫操做的吞吐量,卻也增長了讀操做的開銷.

2.Hashing

Hashing 的原理是計算 RowKey 的 hash 值，而後取 hash 的部分字符串和原來的 RowKey 進行拼接。這裏說的 hash 包含 MD五、sha一、sha256或sha512等算法,並非僅限於Java的Hash值計算。

例:好比咱們有以下的 RowKey：

foo0001                 95f18cfoo0001

                foo0002     ===>        6ccc20foo0002

                foo0003                 b61d00foo0003

                foo0004                 1a7475foo0004

咱們使用 md5 計算這些 RowKey 的 hash 值，而後取前 6 位和原來的 RowKey 拼接獲得新的 RowKey,如上

優缺點：能夠必定程度打散整個數據集，可是不利於 Scan；好比咱們使用 md5 算法，來計算Rowkey的md5值，而後截取前幾位的字符串。
常見用法:subString(MD5(設備ID), 0, x) + 設備ID，其中x通常取5或6。

3.Reversing(反轉)

Reversing 的原理是反轉一段固定長度或者所有的鍵。

例:好比咱們有如下 URL ，並做爲 RowKey：

flink.iteblog.com                           moc.golbeti.knilf
                www.iteblog.com          ===>               moc.golbeti.www
                carbondata.iteblog.com                      moc.golbeti.atadnobrac
                def.iteblog.com                             moc.golbeti.fed

這些 URL 其實屬於同一個域名，可是因爲前面不同，致使數據不在一塊兒存放。咱們能夠對其進行反轉,如上,通過這個以後，前綴就相同了,這些 URL 的數據就能夠放一塊兒了。

優缺點:有效的打亂了行鍵,可是卻犧牲了行排序的屬性.

6.RowKey的長度

RowKey 能夠是任意的字符串，最大長度64KB（由於 Rowlength 佔2字節）。建議越短越好，緣由以下：

• 數據的持久化文件HFile中是按照KeyValue存儲的，若是rowkey過長，好比超過100字節，1000w行數據，光rowkey就要佔用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率；
• MemStore將緩存部分數據到內存，若是rowkey字段過長，內存的有效利用率就會下降，系統不能緩存更多的數據，這樣會下降檢索效率；
• 目前操做系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操做系統的最佳特性。

7.設計案例剖析

1.交易類表 Rowkey 設計

• 查詢某個賣家某段時間內的交易記錄
  sellerId + timestamp + orderId

• 查詢某個買家某段時間內的交易記錄
  buyerId + timestamp ＋orderId

• 根據訂單號查詢
  orderNo

若是某個商家賣了不少商品，按第一種方式,就有可能會有大量RowKey前綴相同的數據在相同的Region上,形成熱點問題,能夠以下設計 Rowkey 實現快速搜索 salt + sellerId + timestamp 其中，salt 是隨機數。

咱們在原來的結構以前進行了一步加鹽salt操做,例如加上一個隨機數,這樣就能夠把這些數據分散到不一樣的Region上去了.

能夠支持的場景：

• 全表 Scan,由於進行了加鹽操做,數據分散到了不一樣的Region上,Scan的時候就會去不一樣的Region上去Scan,這樣就提高高併發,也就提高檢索效率.
• 按照 sellerId 查詢
• 按照 sellerId + timestamp 查詢

2.金融風控 Rowkey 設計

查詢某個用戶的用戶畫像數據

prefix + uid

prefix + idcard

prefix + tele

其中前綴的生成 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard以及 tele 分別表示用戶惟一標識符、×××、手機號碼。

3.車聯網 Rowkey 設計

• 查詢某輛車在某個時間範圍的數據,例如發動機數據
  carId + timestamp

• 某批次的車太多，形成熱點
  prefix + carId + timestamp

其中 prefix = substr(md5(uid),0 ,x)

4.倒序時間戳(時間倒排)

查詢用戶最新的操做記錄或者查詢用戶某段時間的操做記錄，RowKey 設計以下：
uid + Long.Max_Value - timestamp

支持的場景

• 查詢用戶最新的操做記錄
  Scan [uid] startRow [uid][00000000000] stopRow [uid][uid][Long.Max_Value - timestamp]

  這樣就能查出好比說最近100條數據

• 查詢用戶某段時間的操做記錄
  Scan [uid] startRow [uid][Long.Max_Value - startTime] stopRow uid [uid][Long.Max_Value - endTime]

5.二級索引

例:有一張HBase表結構及數據以下

問:如何查找phone=13111111111的用戶?

遇到這種需求的時候,HBase的設計確定是知足不了的,這時候就要引入二級索引,將phone當作RowKey,uid/name當作列名構建二級索引.

若是不依賴第三方組建的話,能夠本身編碼實現二級索引,同時也能夠經過Phoenix或者Solr建立二級索引.

SQL+OLTP ==> Phonenix

全文檢索+二級索引 ==> Solr/ES