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
現在，假如你需要將上面這個 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 都可以用於構建二級索引。
機器學習小案例篇 關於RFM模型的小案例
import pandas as pdin 75 trad flow pd.read csv d python script rfm trad flow.csv encoding gbk 編碼格式需要進行修改 trad flow.head 預設前五行out 75 transid cumid time...
專案經驗 資料庫SQLSERVER篇（許可權設計）
在許可權設計中，主要還是給使用者賦角色，給角色賦許可權的主流方式，按 功能組劃分許可權的主流方案，對於熟悉這種方法的人可以略過本次講解，這次主要是面對一些初級使用者。具體資料庫設計方案如圖 功能組定義表 集標識 集名稱 父 集標識 子系統唯一編號 集類別 程式集url 模組編號 等功能角色定義表 功...
值得收藏的品牌案例 到集設，靈感即到
集設 為設計師呈現最優秀的作品，提供優質創意 用作品打動世界，更讓你的原創設計 作品展示給世界。枯燥無靈感動力時，盡情瀏覽集設。推薦設計師在賞析中學習，在學習中進步。汽車品牌案例欣賞 品牌形象價值是企業的一種無形資產，優秀的品牌形象設計能為消費者帶來新穎獨特的感官感覺。要想在行業中突顯出別具一格的品...