解決資料傾斜的辦法，前輩已經寫得非常完整了，我這裡就直接搬磚吧
（建議先看這個鏈結文章，非常好）
下面是自己的總結：
什麼是資料傾斜？（見下圖）
簡單來說資料傾斜就是資料的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 的jvm記憶體（效果可能不好）
或者（2）在 key 上面做文章，在 map 階段將造成傾斜的key 先分成多組，例如 aaa 這個 key,map 時隨機在 aaa 後面加上 1,2,3,4 這四個數字之一，把 key 先分成四組，先進行一次運算，之後再恢復 key 進行最終運算。
（在mapreduce/spark,該方法常用）
唯一值較多，單個唯一值的記錄數不會超過分配給reduce 的記憶體. 如果發生了偶爾的資料傾斜情況，增加reduce 個數可以緩解偶然情況下的某些reduce 不小心分配了多個較多記錄數的情況.
解決辦法： 增加reduce 個數
乙個固定的組合重新定義
解決辦法：自定義partitioner
我們能通過設計的角度嘗試解決它。
(1)有損的方法：
找到異常資料，比如ip為0的資料，過濾掉
(2)無損的方法：
對分布不均勻的資料，單獨計算
先對key做一層hash，先將資料打散讓它的並行度變大，再匯集
(3)資料預處理;
1.join 操作中，使用 map join 在 map 端就先進行 join ，免得到reduce 時卡住;
2.能先進行 group 操作的時候先進行 group 操作，把 key 先進行一次 reduce,之後再進行 count 或者 distinct count 操作;
3. 設定map端輸出、中間結果壓縮;
大資料學習 資料傾斜
2017 10 23 細柳條小秀才翻譯鋪 前言 資料傾斜是日常大資料查詢中 的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領...
大資料中的資料傾斜
文章結構 先大致解釋一下什麼是資料傾斜 再根據幾個場景來描述一下資料傾斜產生的情況 詳細分析一下在hadoop和spark中產生資料傾斜的原因 如何解決 優化 資料傾斜問題？簡單的講，資料傾斜就是我們在計算資料的時候，資料的分散度不夠，導致大量的資料集中到了一台或者幾台機器上計算，這些資料的計算速度...
大資料常見問題之資料傾斜
用hive算資料的時候reduce階段卡在99.99 用sparkstreaming做實時演算法時候，一直會有executor出現oom的錯誤，但是其餘的executor記憶體使用率卻很低。資料傾斜有乙個關鍵因素是資料量大，可以達到千億級。以hadoop和spark是最常見的兩個計算平台，下面就以這...