一、資料傾斜的原理

在執行shuffle操作的時候，大家都知道是按照key來進行values的資料的輸出、拉取和聚合的。同一個key的values，一定是分配到一個reduce task進行處理的。假設多個key對應的values，總共是90萬。但是問題是可能某個key對應了88萬資料，key-88萬values，分配到一個task上去面去執行。另外兩個task，可能各分配到了1萬資料，可能是數百個key，對應的1萬條資料。如下：

想象一下，第一個和第二個task，各分配到了1萬資料，那麼可能1萬條資料，需要10分鐘計算完畢，第一個和第二個task，可能同時在10分鐘內都執行完了。第三個task要88萬條，88 * 10 =  880分鐘 = 14.5個小時。大家看看，本來另外兩個task很快就執行完畢了（10分鐘），但是由於一個拖後腿的傢伙，第三個task要14.5個小時才能執行完，就導致整個spark作業，也得14.5個小時才能執行完。 這就是資料傾斜。

二、資料傾斜的現象

發生資料傾斜，spark有兩種表現：

1、你的大部分的task，都執行的特別特別快，刷刷刷就執行完了（你要用client模式，standalone client，yarn client，本地機器主要一執行spark-submit指令碼，就會開始列印log），task175 finished。剩下幾個task執行的特別特別慢，前面的task一般1s可以執行完5個，最後發現第1000個task，999個 task要執行1個小時，2個小時才能執行完一個task。出現數據傾斜了還算好的，雖然老牛拉破車一樣，非常慢，但是至少還能跑。

2、執行的時候，其他task都刷刷刷執行完了，也沒什麼特別的問題。但是有的task，就是會突然間報了一個OOM，JVM Out Of Memory，記憶體溢位了，task failed，task lost，resubmitting task。反覆執行幾次都到了某個task就是跑不通，最後就掛掉。 某個task就直接OOM，那麼基本上也是因為資料傾斜了，task分配的數量實在是太大了！所以記憶體放不下，然後你的task每處理一條資料，還要建立大量的物件，記憶體爆掉了。

三、資料傾斜的產生原因與定位

根據log去定位：出現數據傾斜的原因，基本只可能是因為發生了shuffle操作，在shuffle的過程中出現了資料傾斜的問題。因為某個或者某些key對應的資料，遠遠的高於其他的key。

（1）在自己的程式裡面找找，哪些地方用了會產生shuffle的運算元，groupByKey、countByKey、reduceByKey、join。

（2）log一般會報是在你的哪一行程式碼，導致了OOM異常。或者呢，看log，看看是執行到了第幾個stage。哪一個stage，task特別慢，就能夠自己用肉眼去對你的spark程式碼進行stage的劃分，就能夠通過stage定位到你的程式碼，哪裡發生了資料傾斜，去找找程式碼那個地方，是哪個shuffle操作。