為什么Rowkey這么重要
RowKey 到底是什么
我們常說看一張 HBase 表設計的好不好，就看它的 RowKey 設計的好不好。可見 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么？RowKey 的特點如下：
- 類似於 MySQL、Oracle中的主鍵，用於標示唯一的行；
- 完全是由用戶指定的一串不重復的字符串；
- HBase 中的數據永遠是根據 Rowkey 的字典排序來排序的。
- 讀寫數據時通過 RowKey 找到對應的 Region；
- MemStore 中的數據按 RowKey 字典順序排序；
- HFile 中的數據按 RowKey 字典順序排序。
RowKey的作用
Rowkey對查詢的影響
如果我們的 RowKey 設計為 uid+phone+name，那么這種設計可以很好的支持以下的場景：
- uid = 111 AND phone = 123 AND name = zengsm
- uid = 111 AND phone = 123
- uid = 111 AND phone = 12?
- uid = 111
難以支持的場景：
- phone = 123 AND name = zengsm
- phone = 123
- name = zengsm
Rowkey對Region划分影響
HBase 表的數據是按照 Rowkey 來分散到不同 Region，不合理的 Rowkey 設計會導致熱點問題。熱點問題是大量的 Client 直接訪問集群的一個或極少數個節點，而集群中的其他節點卻處於相對空閑狀態。
如上圖，Region1 上的數據是 Region 2 的5倍，這樣會導致 Region1 的訪問頻率比較高，進而影響這個 Region 所在機器的其他 Region。
RowKey設計技巧
我們如何避免上面說到的熱點問題呢？這就是這章節談到的三種方法。
避免熱點的方法 - 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中的一個作為前綴，並以一個現有行作為尾部結束：
|
|
因為分配是隨機的，所以如果你想要以字典序取回數據，你需要做更多工作。加鹽這種方式增加了寫時的吞吐量，但是當讀時有了額外代價。
避免熱點的方法 - 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。
避免熱點的方法 - Reversing
Reversing 的原理是反轉一段固定長度或者全部的鍵。比如我們有以下 URL ，並作為 RowKey：
|
|
這些 URL 其實屬於同一個域名，但是由於前面不一樣，導致數據不在一起存放。我們可以對其進行反轉，如下：
|
|
經過這個之后，這些 URL 的數據就可以放一起了。
RowKey的長度
RowKey 可以是任意的字符串，最大長度64KB（因為 Rowlength 占2字節）。建議越短越好，原因如下：
- 數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節，1000w行數據，光rowkey就要占用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率；
- MemStore將緩存部分數據到內存，如果rowkey字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率；
- 目前操作系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操作系統的最佳特性。
RowKey 設計案例剖析
交易類表 Rowkey 設計
- 查詢某個賣家某段時間內的交易記錄
sellerId + timestamp + orderId - 查詢某個買家某段時間內的交易記錄
buyerId + timestamp ＋orderId - 根據訂單號查詢
orderNo - 如果某個商家賣了很多商品，可以如下設計 Rowkey 實現快速搜索
salt + sellerId + timestamp 其中，salt 是隨機數。
可以支持的場景：- 全表 Scan
- 按照 sellerId 查詢
- 按照 sellerId + timestamp 查詢
金融風控 Rowkey 設計
查詢某個用戶的用戶畫像數據
-
- prefix + uid
- prefix + idcard
- prefix + tele
其中 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard以及 tele 分別表示用戶唯一標識符、身份證、手機號碼。
車聯網 Rowkey 設計
- 查詢某輛車在某個時間范圍的交易記錄
carId + timestamp - 某批次的車太多，造成熱點
prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)
查詢最近的數據
查詢用戶最新的操作記錄或者查詢用戶某段時間的操作記錄，RowKey 設計如下：
uid + Long.Max_Value - timestamp
支持的場景
- 查詢用戶最新的操作記錄
Scan [uid] startRow [uid][000000000000] stopRow [uid][Long.Max_Value - timestamp] - 查詢用戶某段時間的操作記錄
Scan [uid] startRow [uid][Long.Max_Value – startTime] stopRow [uid][Long.Max_Value - endTime]
OpenTSDB 的 Rowkey 設計
參見 《OpenTSDB 底層 HBase 的 Rowkey 是如何設計的》
如果 RowKey 無法滿足我們的需求，可以嘗試二級索引。Phoenix、Solr 以及 ElasticSearch 都可以用於構建二級索引。
轉載自 過往記憶（https://www.iteblog.com/）