熱點問題

HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。

熱點發生在大量的client直接訪問叢集的一個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起效能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由於主機無法服務其他region的請求。

設計良好的資料訪問模式以使叢集被充分，均衡的利用。為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多資料情況下，資料應該被寫入叢集的多個region，而不是一個。

下面是一些常見的避免熱點的方法以及它們的優缺點

1、加鹽

這裡所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配一個隨機字首以使得它和之前的rowkey的開頭不同。分配的字首種類數量應該和你想使用資料分散到不同的region的數量一致。加鹽之後的rowkey就會根據隨機生成的字首分散到各個region上以避免熱點。

2、雜湊

雜湊會使同一行永遠用一個字首加鹽。雜湊也可以使負載分散到整個叢集，但是讀卻是可以預測的。使用確定的雜湊可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行資料。

3、反轉

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

反轉rowkey的例子以手機號為rowkey，可以將手機號反轉後的字串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題。

4、時間戳反轉

一個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最後錄入的資料。

比如需要儲存一個使用者的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計：
[userId反轉][Long.Max_Value - timestamp]，在查詢使用者的所有操作記錄資料的時候，直接指定反轉後的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp]

如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間]

注意：
儘量減少行和列的大小在HBase中，value永遠和它的key一起傳輸的。當具體的值在系統間傳輸時，它的rowkey，列名，時間戳也會一起傳輸。如果你的rowkey和列名很大，甚至可以和具體的值相比較，那麼你將會遇到一些有趣的問題。HBase storefiles中的索引（有助於隨機訪問）最終佔據了HBase分配的大量記憶體，因為具體的值和它的key很大。可以增加block大小使得storefiles索引再更大的時間間隔增加，或者修改表的模式以減小rowkey和列名的大小。壓縮也有助於更大的索引。
列族儘可能越短越好，最好是一個字元。
冗長的屬性名雖然可讀性好，但是更短的屬性名儲存在HBase中會更好。

喜歡就點贊評論+關注吧

感謝閱讀，希望能幫助到大家，謝謝大家的支援！