解惑：這個 Spark 任務是資料傾斜了嗎？
健身前後對比
健身回來的路上，看到微信群裡聊技術，一群有問了一個神奇的問題，具體可以看如下截圖：
哥們給出的結論是repartition導致的資料傾斜，我給他詳細的回覆了說明了不是資料傾斜。那麼接下來，我們就仔細分析一下原因。
為了大家更徹底的瞭解這塊內容，文章底部浪尖也錄製了一個小視訊。
那哥們數是repartition導致的資料傾斜原因，是由於前三行資料輸入和輸出都是好幾百兆，而後面的都是隻有幾個MB的輸入，0B輸出，所以下結論是資料傾斜。
浪尖糾正他是錯的原因是資料傾斜往往指的是同一個stage內部： 有的task資料量大，有的task資料量小，task間資料量大小差距比較大，而這個明顯不是 。這個是executor的頁面，可以看complete task列，會發現前三行佔據了幾乎所有task執行，完成的task數是其餘的十幾二十倍。這個就是導致前三行輸入輸出資料量比較大的原因。
資料本地性是導致這個問題的根本原因。由於資料本地性task排程會優先排程到資料所在的executor機器，假如機器executor存在執行中的task會等待一個時間，在這個時間內task執行完，新task會直接排程到該executor上。如此往復，導致executor處理的task差距比較大。
官網給出了關於spark排程task的時候資料本地性降級的等待時間配置。
很簡單，將3s設定為0s，然後結果就是task不會等待資料本性降級，就立即排程執行。
其實，根源還是kafka 建立topic的時候 partition數目沒有夠。單個parition的吞吐量是可以達到數萬qps，但是結合業務邏輯，不同的資料輸出位置，吞吐量會急劇下降，所以topic分割槽數，應該根據處理邏輯和落地位置，磁碟數，綜合考慮設定。
還有一點就是分析問題不準確，關於spark streaming效能瓶頸分析和解決方法，浪尖在知識星球裡做了詳細的分析，建議大家加入知識星球。
加入知識星球二維碼
關於知識星球能學到啥可以閱讀
ofollow,noindex">深入系統掌握大資料
微信群，可以加浪尖微信
