Hbase的表結構中rowkey的設計---避免熱點問題

熱點問題

　　hbase 中的行是以 rowkey 的字典序排序的，這種設計優化了scan 操做，能夠將相關的 行 以及會被一塊兒讀取的行 存取在臨近位置，便於 scan 。 然而，糟糕的 rowkey 設計是 熱點 的源頭。 熱點發生在大量的客戶端直接訪問集羣的一個或極少數節點。訪問能夠是讀，寫，或者其餘操做。大量訪問會使 熱點region 所在的單個機器超出自身承受能力，引發性能降低甚至是 region 不可用。這也會影響同一個 regionserver 的其餘 regions，因爲主機沒法服務其餘region 的請求。設計良好的數據訪問模式以使集羣被充分，均衡的利用。 
　　爲了不寫熱點，設計 rowkey 使得 不一樣行在同一個 region,可是在更多數據狀況下，數據應該被寫入集羣的多個region，而不是一個。下面是一些常見的避免 熱點的方法以及它們的優缺點：

一、加鹽

　　這裏的加鹽不是密碼學中的加鹽，而是在rowkey 的前面增長隨機數。具體就是給 rowkey 分配一個隨機前綴 以使得它和以前排序不一樣。分配的前綴種類數量應該和你想使數據分散到不一樣的 region 的數量一致。 若是你有一些 熱點 rowkey 反覆出如今其餘分佈均勻的 rwokey 中，加鹽是頗有用的。考慮下面的例子：它將寫請求分散到多個 RegionServers，可是對讀形成了一些負面影響。 
a-rk0001 
b-rk0002 
c-rk0003 
a-rk0004

三、哈希

　　除了加鹽，你也可使用哈希，哈希會使同一行永遠用同一個前綴加鹽。哈希也可使負載分散到整個集羣，可是讀倒是能夠預測的。使用肯定的哈希可讓客戶端重構完成的 rowkey，使用Get 操做獲取正常的獲取某一行數據。

四、翻轉key

　　第三種防止熱點的方法是翻轉固定長度或者數字格式的rowkey。這樣可使得rowkey中常常改變的部分（最沒意義的部分）放在前面。這樣能夠有效的隨機 rowkey,可是犧牲了 rowkey 的有序性。 
100kr 
200kr 
300kr

五、單調遞增 rowkey(時間連續序列)

　　當全部客戶端一段時間內一致寫入某一個region,而後再接着寫入下一個 region。例如：像單調遞增的 rowkey（時間戳） ，就會發生這種現象。應該儘可能避免這種設計。 
打散數據的數據+時間序列

六、儘可能減小行和列的大小

　　在Hbase中，value永遠是和它的key一塊兒傳輸的。當具體的值在系統間傳輸時，它的rowkey,列名，時間戳也會一塊兒傳輸。若是你的rowkey和列名很大，甚至能夠和具體的值相比較，那麼你將會遇到一些有趣的狀況。HBase storefiles中的索引（有助於隨機訪問）最終佔據了HBase 分配的大量內存，由於具體的值和他的key很大。能夠增長 block 大小使得 storefiles 索引在更大的時間間隔增長，或者修改表的模式以減少rowkey 和 列名的大小。壓縮也有助於更大的索引。

　　大多時候較小的低效率是可有可無的，可是在這種狀況下，任何訪問模式都須要列族名，列名，rowkey，因此它們會被訪問數十億次在你的數據中。

七、列族越短越好

儘量使列族名越短越好，最好是一個字符。（例如：’d’ 表明data/default）。屬性名也是同樣的。