溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關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任務是不是數據傾斜的示例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
