文章出處：https://www.jianshu.com/p/539415d06f1b

大數據----“數據傾斜”的問題

一、Hadoop中的數據傾斜：

什么是數據傾斜？（見下圖）

簡單來說數據傾斜就是數據的key 的分化嚴重不均，造成一部分數據很多，一部分數據很少的局面。

舉個 word count 的入門例子: 它的map 階段就是形成 （“aaa”,1）的形式，然后在reduce 階段進行 value 相加，得出 “aaa” 出現的次數。若進行 word count 的文本有100G，其中 80G 全部是 “aaa” 剩下 20G 是其余單詞，那就會形成 80G 的數據量交給一個 reduce 進行相加，其余 20G 根據 key 不同分散到不同 reduce 進行相加的情況。如此就造成了數據傾斜，臨床反應就是 reduce 跑到 99%然后一直在原地等著 那80G 的reduce 跑完。

這里如果詳細的看日志或者和監控界面的話會發現：

?

有一個多幾個reduce卡住

各種container報錯OOM

讀寫的數據量極大，至少遠遠超過其它正常的reduce

伴隨著數據傾斜，會出現任務被kill等各種詭異的表現。

二、導致的原因分為幾種情況：

1.單個值有大量記錄

單個值有大量記錄, 這種值的所有紀錄已經超過了分配給reduce 的內存，無論你怎么樣分區這種情況都不會改變. 當然這種情況的限制也非常明顯, 1.內存的限制存在，2.可能會對集群其他任務的運行產生不穩定的影響.

解決方法：(1)增加reduce 的jvm內存（效果可能不好）

或者（2）在 key 上面做文章，在 map 階段將造成傾斜的key 先分成多組，例如 aaa 這個 key,map 時隨機在 aaa 后面加上 1,2,3,4 這四個數字之一，把 key 先分成四組，先進行一次運算，之后再恢復 key 進行最終運算。

（在MapReduce/spark,該方法常用）

2.唯一值較多

唯一值較多，單個唯一值的記錄數不會超過分配給reduce 的內存. 如果發生了偶爾的數據傾斜情況，增加reduce 個數可以緩解偶然情況下的某些reduce 不小心分配了多個較多記錄數的情況.

解決辦法： 增加reduce 個數

3.以上兩種都無效的情況

一個固定的組合重新定義

解決辦法：自定義partitioner

4.從業務和數據上解決數據傾斜

我們能通過設計的角度嘗試解決它。

(1)有損的方法：

找到異常數據，比如ip為0的數據，過濾掉

(2)無損的方法：

對分布不均勻的數據，單獨計算

先對key做一層hash，先將數據打散讓它的并行度變大，再匯集

(3)數據預處理;

5.平臺的優化方法

1.join 操作中，使用 map join 在 map 端就先進行 join ，免得到reduce 時卡住;

2.能先進行 group 操作的時候先進行 group 操作，把 key 先進行一次 reduce,之后再進行 count 或者 distinct count 操作;

3. 設置map端輸出、中間結果壓縮;

大家喜歡多多關注，你的關注是我最大的動力，會不定期更新

總結

以上是生活随笔為你收集整理的数据倾斜问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。