計算資料時，資料分散度不夠，導致大量資料集中到一台或幾台機器上計算。
區域性計算遠低於平均計算速度，整個過程過慢。
部分任務處理資料量過大，可能oom，任務失敗，進而應用失敗。
1、executor lost、（driver）oom、shuffle過程出錯；
2、正常執行任務突然失敗；
3、單個executor執行時間特別久，整體任務卡在某個階段不結束；
spark streaming更容易出現資料傾斜，特別是包含sql的join、group操作，因為記憶體分配不多，很容易出現資料傾斜，造成oom。
資料傾斜只會發生在shuffle階段。進行shuffle時，必須將各個相同key拉取到某個節點的乙個task進行處理，如按照key進行聚合或join，某個key對應資料量特別大，就會發生資料傾斜。
觸發shuffle運算元：distinct、groupbykey、reducebykey、aggregatebykey、join、cogroup、repartition等。
檢視各個task分配的資料量，確定是不是分配資料不均勻導致。
某個task執行特別慢
1） 知道觸發shuffle常用運算元；
2）從日誌找到執行到第幾個stage，再在spark web ui檢視各個task分配資料量。如果嚴重不均，大概率發生了資料傾斜。
3）由stage劃分原理推算出問題**，再精準定位shuffle類運算元。（這部分需要對spark原始碼有深入理解）
某個task莫名奇妙oom
直接看yarn-client/cluster模式下log中的異常棧，
由於資料巨大，可以對資料進行抽樣，統計出現次數，根據次數大小取出前幾個。如果多數分布均勻，個別資料大若干數量級，則說明發生了資料傾斜。
過濾異常資料
內容：異常/空值正確處理；視情況忽略對結果影響不大的無效資料；有效資料：自定義partitioner，將不均勻的資料做一次hash，打散後讓它並行度變大，再匯集。
hive etl預處理資料
內容：預警線通過hive etl對資料按照key進行聚合，或其他表進行join，spark作業不再需要shuffle原子進行這類操作。
優劣：完全規避掉了資料傾斜，spark作業效能大幅度提公升。但治標不治本，只是將問題前移。
適用：spark響應要求高，執行次數不多，可以放到前面，提供更好的使用者體驗。
內容：將少數資料量特別的key，對作業執行和計算結果不重要，乾脆直接過濾。
優劣：實現簡單，效果很好。但適用場景不多，大多數情況，導致傾斜的key很多，並不算少數幾個。
內容：設定shuffle運算元執行shuffle read task數量，引數spark.shuffle.partitions可以代表並行的，預設200，可以調大。原本多個key分配給task的數量從乙個變多個，從而讓每個task處理比原來更少的資料。
優劣：實現簡單，可以有效緩解，但沒有徹底解決。
內容：第一次區域性聚合，每個key前面都打上乙個隨機數，執行reducebykey等區域性聚合，然後將各個key字首去掉，再次進行全域性聚合操作，可以得到最終結果
優劣：適用reducebykey/goup by等聚合操作（分組操作），但join類shuffle操作，還得用其他解決方案。
內容：大小表（<2g）關聯，可以不用join運算元，而適用broadcast變數與map類運算元實現join操作，進而規避掉shuffle類操作。broadcast變數獲取較小rdd全量資料，與當前rdd的每一條按照key進行比對，相同連線。
優劣：join類操作效果很好，但只適用大小表情況。小表較大會oom。
適用：兩個rdd/hive表進行join時，如果資料量都比較大，出現資料傾斜。如果乙個rdd少數key資料量過大，另乙個rdd所有key都分布均勻。
內容：對少數幾個資料量多大的key，sample取樣出資料量最大的幾個key，然後將這幾個key從原來rdd拆分出來，形成乙個單獨rdd，給每個key都打上n以內隨機數作為字首，需要join的另乙個rdd，也過濾出來對應key形成單獨rdd，將每條資料膨脹成n條資料，附加0-n字首，不會導致傾斜的大部分key也形成另乙個rdd。此時，原先相同key打散成n份，分散到多個task進行join。剩下的rdd照常即可，最後將兩次join結果union合併就得到最終join結果。
優劣：只是幾個key導致傾斜，只需將其打散，然後另外乙份對應key的rdd擴容n倍。但如果傾斜key特別多，如成千上萬，就不適合。
內容：與方案六類似，進行join操作時，rdd中大量key導致資料。都是a_rdd打上隨機附加數，b_rdd進行擴容。不同之處在於，方案六是針對少數key，這一方案是針對大量傾斜key，沒法將部分key拆分出來，只能對整個rdd進行資料擴容，對記憶體資源要求很高。
優劣：join型別資料傾斜都能出來，效果顯著，當然更多是緩解，而不是徹底避免。但擴容對記憶體資源要求很高。
內容：先用方案一和二預處理一部分資料，其次可以對shuffle提公升並行度，最後可以針對不同聚合或join操作，選擇一種方案進行優化。
業務角度：比如上海資料特別多，可以單獨count，最後和其他城市整合；
程式層面：count（distinct） 導致只有乙個reduce，可以在group外麵包一層count；
調參方面：spark自帶很多引數，合理利用可以解決大部分問題。
1、spark效能優化之道——解決spark資料傾斜（data skew）的n種姿勢
2、spark效能優化指南——高階篇
3、漫談千億級資料優化實踐：資料傾斜（純乾貨）
4、spark 資料傾斜及其解決方案
5、細品資料傾斜（建議收藏）
6、一文帶你搞清楚什麼是「資料傾斜」
7、面試必問&資料傾斜
spark資料傾斜問題
資料傾斜 加更大記憶體 跟cpu硬體是效能優化的根本之道 一 資料傾斜帶來的致命性後果 1.oom 根本原因資料太多 一般oom都是由於資料傾斜所致，spark基於jvm之上的 2.速度非常慢 二 資料傾斜的基本特徵 1.任務分配不均勻 2.個別task處理過度大量的資料 shuffle過程中遇到同...
Spark之資料傾斜
spark之資料傾斜 1 關於效能調優首先談資料傾斜，為什麼?1 因為如果資料傾斜，其他所有的調優都是笑話，因為資料傾斜主要導致程式跑步起來或者執行狀態不可用。2 資料傾斜最能代表spark水平的地方，spark是分布式的，如果理解資料傾斜說明你對spark執行機制瞭如指掌。2 資料傾斜兩大直接致命...
Spark面試經典系列之資料傾斜 資料傾斜之痛
本課主題 spark效能真正的殺手 資料傾斜兩大直接致命性的的後果 資料傾斜最殺人就是 out of memory oom 一般oom都是由於資料傾斜所致 速度變慢 特別慢 非常慢 極端的慢 不可接受的慢。資料傾斜基本特徵 個別 task處理大量資料 20 和80 基本上都存在業務熱點問題，這是現實...