資料傾斜

在任何大資料類的專案中，都是最棘手的效能問題，最能體現人的技術能力，最能體現RD（Research Developer，研發工程師）的技術水平。

資料傾斜 = 效能殺手

如果沒有豐富的經驗，或者沒有受過專業的技術培訓，是很難解決資料傾斜問題的

在執行shuffle操作的時候，大家都知道，我們之前講解過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作業，跑的特別特別特別特別慢！！！像老牛拉破車！

資料傾斜，一旦出現，是不是效能殺手。。。。
發生資料傾斜以後的現象：

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

1、你的大部分的task，都執行的特別特別快，刷刷刷，就執行完了（你要用client模式，standalone client，yarn client，本地機器主要一執行spark-submit指令碼，就會開始列印log），task175 finished；剩下幾個task，執行的特別特別慢，前面的task，一般1s可以執行完5個；最後發現1000個task，998，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

log一般會報是在你的哪一行程式碼，導致了OOM異常；或者呢，看log，看看是執行到了第幾個stage！！！