我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。
那麼 rowkey 到底是什麼？rowkey 的特點如下：
如果我們的 rowkey 設計為 uid+phone+name，那麼這種設計可以很好的支援以下的場景：
難以支援的場景：
hbase 表的資料是按照 rowkey 來分散到不同 region，不合理的 rowkey 設計會導致熱點問題。
熱點問題是大量的 client 直接訪問集群的乙個或極少數個節點，而集群中的其他節點卻處於相對空閒狀態。
如上圖，region1 上的資料是 region 2 的5倍，這樣會導致 region1 的訪問頻率比較高，進而影響這個 region 所在機器的其他 region。
我們如何避免上面說到的熱點問題呢？這就是這章節談到的三種方法。
這裡的加鹽不是密碼學中的加鹽，而是在rowkey
的前面增加隨機數。具體就是給 rowkey 分配乙個隨機字首 以使得它和之前排序不同。
分配的字首種類數量應該和你想使資料分散到不同的
中，加鹽是很有用的。
考慮下面的例子：它將寫請求分散到多個 regionservers，但是對讀造成了一些負面影響。
假如你有下列 rowkey，你表中每乙個 region 對應字母表中每乙個字母。
以 'a' 開頭是同乙個region, 'b'開頭的是同乙個region。
在表中，所有以 'f'開頭的都在同乙個 region， 它們的 rowkey 像下面這樣：
foo0001
foo0002
foo0003
foo0004
現在，假如你需要將上面這個 region 分散到 4個 region。你可以用4個不同的鹽：'a', 'b', 'c', 'd'.
在這個方案下，每乙個字母字首都會在不同的 region 中。加鹽之後，你有了下面的 rowkey:
a-foo0003
b-foo0001
c-foo0004
d-foo0002
所以，你可以向4個不同的 region 寫。
理論上說，如果這四個 region 存放在不同的機器上，經過加鹽之後你將擁有之前4倍的吞吐量。
現在，如果再增加一行，它將隨機分配a,b,c,d中的乙個作為字首，並以乙個現有行作為尾部結束：
a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002
因為分配是隨機的，所以如果你想要以字典序取回資料，你需要做更多工作。
加鹽這種方式增加了寫時的吞吐量，但是當讀時有了額外代價。
hashing 的原理是計算 rowkey 的 hash 值，然後取 hash 的部分字串和原來的 rowkey 進行拼接。
這裡說的 hash 包含 md5、sha1、sha256或sha512等演算法。
比如我們有如下的 rowkey：
foo0001
foo0002
foo0003
foo0004
我們使用 md5 計算這些 rowkey 的 hash 值，然後取前 6 位和原來的 rowkey 拼接得到新的 rowkey：
95f18cfoo0001
6ccc20foo0002
b61d00foo0003
1a7475foo0004
優缺點：可以一定程度打散整個資料集，但是不利於 scan；
比如我們使用 md5 演算法，來計算rowkey的md5值，然後擷取前幾位的字串。substring(md5(裝置id), 0, x) + 裝置id，其中x一般取5或6。
reversing 的原理是反轉一段固定長度或者全部的鍵。
比如我們有以下 url ，並作為 rowkey：
flink.iteblog.com
www.iteblog.com
carbondata.iteblog.com
def.iteblog.com
這些 url 其實屬於同乙個網域名稱，但是由於前面不一樣，導致資料不在一起存放。我們可以對其進行反轉，如下：
moc.golbeti.knilf
moc.golbeti.www
moc.golbeti.atadnobrac
moc.golbeti.fed
經過這個之後，這些 url 的資料就可以放一起了。
rowkey 可以是任意的字串，最大長度64kb（因為 rowlength 佔2位元組）。
建議越短越好，原因如下：
查詢某個使用者的使用者畫像資料
其中 prefix = substr(md5(uid),0 ,x)， x 取 5-6。uid、idcard以及 tele 分別表示使用者唯一識別符號、身份證、手機號碼。
查詢使用者最新的操作記錄或者查詢使用者某段時間的操作記錄，rowkey 設計如下：
uid + long.max_value - timestamp
支援的場景
HBase Rowkey 設計指南
文章目錄 2 rowkey設計技巧 3 rowkey 設計案例剖析 我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼？rowkey 的特點如下 如果我們的 rowkey 設計為 uid ph...
案例篇 HBase RowKey 設計指南
1.為什麼 rowkey 這麼重要 1.1 rowkey 到底是什麼 我們常說看一張 hbase 表設計的好不好，就看它的 rowkey 設計的好不好。可見 rowkey 在 hbase 中的地位。那麼 rowkey 到底是什麼?rowkey 的特點 如下 類似於 mysql oracle 中的主鍵...
HBase RowKey設計原則
對於關係型資料庫，資料定位可以理解為 二維座標 但是hbase中需要四維來定位乙個單元格，即 行健 列族 列限定符 時間戳 hbase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行訪問在臨近位置，便於scan。然而糟糕的rowkey設計是熱點...