1.為什么 Rowkey 這么重要

1.1 RowKey 到底是什么

我們常說看一張 HBase 表設計的好不好，就看它的 RowKey 設計的好不好。可見 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特點 如下:

類似于 MySQL、Oracle 中的主鍵，用于標示唯一的行;

完全是由用戶指定的一串不重復的字符串;

HBase 中的數據永遠是根據 Rowkey 的字典排序來排序的。

1.2 RowKey 的作用

讀寫數據時通過 RowKey 找到對應的 Region;

MemStore 中的數據按 RowKey 字典順序排序;

HFile 中的數據按 RowKey 字典順序排序。

1.3 Rowkey 對查詢的影響

如果我們的 RowKey 設計為 uid+phone+name，那么這種設計可以很好的支持
以下的場景:
uid = 111 AND phone = 123 AND name = iteblog uid = 111 AND phone = 123
uid = 111 AND phone = 12?
uid = 111
難以支持的場景:
phone = 123 AND name = iteblog phone = 123
name = iteblog

1.4 Rowkey 對 Region 劃分影響

HBase表的數據是按照 Rowkey 來分散到不同 Region，不合理的 Rowkey 設計會導致熱點問題。熱點問題是大量的 Client 直接訪問集群的一個或極少數個節點，而集群中的其他節點卻處于相對空閑狀態。

如上圖，Region1 上的數據是 Region 2 的 5 倍，這樣會導致 Region1 的訪問 頻率比較高，進而影響這個 Region 所在機器的其他 Region。

2.RowKey 設計技巧

我們如何避免上面說到的熱點問題呢?這就是這章節談到的三種方法。

2.1 避免熱點的方法 – Salting

這里的加鹽不是密碼學中的加鹽，而是在 rowkey 的前面增加隨機數。具體就是給 rowkey 分配一個隨機前綴以使得它和之前排序不同。分配的前綴種類數量應該和你想使數據分散到不同的 region 的數量一致。 如果你有一些 熱點 rowkey 反復出現在其他分布均勻的 rwokey 中，加鹽是很有用的。考慮下面的例子:它將寫請求分散到多個RegionServers，但是對讀造成了一些負面影響。
假如你有下列 rowkey，你表中每一個 region 對應字母表中每一個字母。以 'a' 開頭是同一個 region, 'b'開頭的是同一個 region。在表中，所有以 'f'開頭的都在 同一個 region， 它們的 rowkey 像下面這樣:

現在，假如你需要將上面這個 region 分散到 4 個 region。你可以用 4 個不同 的鹽:'a', 'b', 'c', 'd'.在這個方案下，每一個字母前綴都會在不同的 region 中。 加鹽之后，你有了下面的 rowkey:

所以，你可以向 4 個不同的 region 寫，理論上說，如果所有人都向同一個 region 寫的話，你將擁有之前 4 倍的吞吐量。
現在，如果再增加一行，它將隨機分配 a,b,c,d 中的一個作為前綴，并以一個現有行作為尾部結束:

因為分配是隨機的，所以如果你想要以字典序取回數據，你需要做更多工作。加鹽這種方式增加了寫時的吞吐量，但是當讀時有了額外代價。

2.2 避免熱點的方法 - Hashing

Hashing 的原理是計算 RowKey 的 hash 值，然后取 hash 的部分字符串和原來的 RowKey 進行拼接。這里說的 hash 包含 MD5、sha1、sha256 或 sha512 等算法。比如我們有如下的 RowKey:

我們使用 md5 計算這些 RowKey 的 hash 值，然后取前 6 位和原來的 RowKey 拼接得到新的 RowKey:

優缺點:可以一定程度打散整個數據集，但是不利于 Scan;比如我們使用 md5 算法，來計算 Rowkey 的 md5 值，然后截取前幾位的字符串。subString(MD5(設備ID),0,x)+ 設備ID，其中x一般取5或6。

2.3 避免熱點的方法 - Reversing

Reversing 的原理是反轉一段固定長度或者全部的鍵。比如我們有以下 URL ， 并作為 RowKey:

這些 URL 其實屬于同一個域名，但是由于前面不一樣，導致數據不在一起存放。 我們可以對其進行反轉，如下:

經過這個之后，這些 URL 的數據就可以放一起了。

2.4 RowKey 的長度

RowKey 可以是任意的字符串，最大長度 64KB(因為 Rowlength 占 2 字節)。 建議越短越好，原因如下:

數據的持久化文件 HFile 中是按照 KeyValue 存儲的，如果 rowkey 過長，比 如超過 100 字節，1000w 行數據，光 rowkey 就要占用 100*1000w=10 億個字 節，將近 1G 數據，這樣會極大影響 HFile 的存儲效率;

MemStore 將緩存部分數據到內存，如果 rowkey 字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率;

目前操作系統都是 64 位系統，內存 8 字節對齊，控制在 16 個字節，8 字節的整數倍利用了操作系統的最佳特性。

3.RowKey 設計案例剖析

3.1 交易類表 Rowkey 設計

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

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

根據訂單號查詢 orderNo
如果某個商家賣了很多商品，可以如下設計 Rowkey 實現快速搜索salt+sellerId + timestamp 其中，salt 是隨機數。
可以支持的場景:

全表 Scan

按照 sellerId 查詢

按照 sellerId + timestamp 查詢

3.2 金融風控 Rowkey 設計

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

prefix + uid

prefix + idcard

prefix + tele
其中 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard 以及 tele 分別表示 用戶唯一標識符、身份證、手機號碼。

3.3 車聯網 Rowkey 設計 查詢某輛車在某個時間范圍的交易記錄
carId + timestamp
某批次的車太多，造成熱點
prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)

3.4 查詢最近的數據
查詢用戶最新的操作記錄或者查詢用戶某段時間的操作記錄，RowKey 設計如下: uid + Long.Max_Value - timestamp
支持的場景

查詢用戶最新的操作記錄
Scan [uid] startRow uid stopRow uid

查詢用戶某段時間的操作記錄
Scan [uid] startRow uid stopRow uid

如果 RowKey 無法滿足我們的需求，可以嘗試二級索引。Phoenix、Solr 以及 ElasticSearch 都可以用于構建二級索引。

總結

以上是生活随笔為你收集整理的案例篇-HBase RowKey 设计指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。