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 包含 MD5、sha1、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