在大量客戶端請求訪問數(shù)據(jù)或者寫入數(shù)據(jù)的時候，只有少數(shù)幾個或者一個 RegionServer 做出響應，導致該服務器的負載過高，造成讀寫效率低下，而此時其他的服務器還是處于空閑的狀態(tài)，就是所謂“旱的旱死，澇的澇死”。那么為什么會造成這種情況，主要的原因就是數(shù)據(jù)分布不均勻，可能是數(shù)據(jù)量分布不均勻，也可能是冷熱數(shù)據(jù)分布不均勻。而糟糕的 RowKey 設計就是發(fā)生熱點即數(shù)據(jù)傾斜的源頭，所以這里會詳細說說HBase如何處理熱點數(shù)據(jù)問題。

　　加鹽

　　加鹽即在原本的 rowkey 前面加上隨機的一些值。 * 隨機數(shù)：在 RowKey 的前面增加隨機數(shù)來打散 RowKey 在 Region 的分布，但不是一種好的選擇，因為 HBase 的設計是只有 RowKey 是索引，RowKey 都變成隨機的了，讀數(shù)據(jù)只能做性能極低的全表掃描了。總之不推薦。 * 哈希：哈希的方式明顯比隨機數(shù)更好，哈希會使同一行永遠用一個前綴加鹽。同樣可以起到打散 Rowkey 在 Region 的分布的目的，使負載分散到整個集群，最重要讀是可以預測的。使用確定的哈希可以讓客戶端重構(gòu)完整的 Rowkey，可以使用 Get 操作準確獲取某一個行數(shù)據(jù)。

　　反轉(zhuǎn)

　　* 反轉(zhuǎn)即把低位的隨機數(shù)反轉(zhuǎn)到高位。比如手機號碼或者時間戳的反轉(zhuǎn)，高位基本固定是 1 開頭的，而末位是隨機的。這種同樣是一種比較常規(guī)的構(gòu)成散列的方式。

　　預分區(qū)

　　預分區(qū)上面已經(jīng)提到過，這種方式對于處理數(shù)據(jù)量分布不均勻，和冷熱數(shù)據(jù)分布不均勻都是有一定效果的，但是需要對業(yè)務的應用場景做好準確的預判。

　　更多關(guān)于大數(shù)據(jù)培訓的問題，歡迎咨詢千鋒教育在線名師，如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問，獲取試聽資格來試聽我們的課程，在線零距離接觸千鋒教育大咖名師，讓你輕松從入門到精通。