如下問題討論：
哥們給出的結論是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不會等待數據本性降級，就立即調度執行。
很多人禁用數據本地性的時候，直接給參數設置爲0，沒帶單位導致不生效。
其實，根源還是kafka 創建topic的時候 partition數目沒有夠。單個parition的吞吐量是可以達到數萬qps，但是結合業務邏輯，不同的數據輸出位置，吞吐量會急劇下降，所以topic分區數，應該根據處理邏輯和落地位置，磁盤數，綜合考慮設置。