由於時間久遠。該問題十分具有代表性。所以今天將其記錄一下。
本人使用的是華爲C70集羣，spark1.5.1的版本，由於版本問題。原先批處理一個小時的程序變慢一倍。達到2小時的處理時長。以jstack和jstat的方式大量觀察，排除了gc和oom的問題。
那麼問題到底出在哪裏?
截圖爲內網。我無法拿出來。
我用語言描述一下：
即爲可以從spark UI界面觀察得出。job界面中 多個stage之間存在了很多空白時間!以下這個圖是百度的。就是放這裏圖個感覺哈哈~~
可以得出每個stage的提交時間和運行時間。但是我的程序當中。即便提交時間+運行時間與下一個stage之間差了幾分鐘之差，並且跑到大表會更長，小表會短一點，所以就去排查日誌。driver的日誌是正常的。沒有任何報錯和延遲信息。我就去查節點網絡的io問題，去ping然後查丟包。結果也是正常，到底是什麼原因呢？？到底空白時間在做什麼？
經過去具體某個節點點開excutor的日誌查詢，發現底部有大量類似於
deleting …
replacing…
相關字眼。而且info信息的時間戳恰好對應了空白時間的區域。
我去查了相關源碼才得知。
當寫入hive時候。即便是sparksql任務已經完成。底部還是在進行對hfile塊文件，大量的搬運複製，刪除操作。由於增量與全量的合併。每次全量的hfile都要進行一次這種hfile相關的大量操作。而其原因是由於底層該表的小文件個數較多。導致系統需要操作就隨之變多。回到spark1.5.1，sparksql shuffle過程會產生大量小文件而且，如果不加以控制。全量表的小文件會越來越多。進一步延長程序時間。所以在診斷出這類問題以後，採用coalesce方式動態根據表的數據量控制分區數。
進行減少dataframe的分區的操作，解決了該類問題。此問題是在3個月之前出現的。所以以此記錄。讓後人減少爬坑時間。
最終數百個stage 每個縮短了具體數分鐘的時長。原先程序又恢復了運行1小時的時長。
問題說的不是很好。如果有小夥伴出現這類問題，可以諮詢我。
內網工作。截圖和相關信息無法貼出。望見諒!