在大量客戶端請求訪問數(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ù)培訓的問題,歡迎咨詢千鋒教育在線名師,如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問,獲取試聽資格來試聽我們的課程,在線零距離接觸千鋒教育大咖名師,讓你輕松從入門到精通。