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

　　加鹽

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

　　反轉(zhuǎn)

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

　　預(yù)分區(qū)

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

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