我們正在運行以下階段DAG和經歷較長洗牌閱讀時間相對較小洗牌的數據尺寸(約每任務19MB)星火洗牌讀需要顯著時間小數據
一個有趣的方面是每個執行器/服務器中的等待任務具有相同的洗牌讀取時間。下面是一個例子:對於下面的服務器,一組任務等待約7.7分鐘,另一組等待約26秒。
下面是從同一階段運行的另一個例子。該圖顯示了3個執行者/服務器,每個具有相同的洗牌讀取時間的統一的任務組。藍組表示,由於推測執行打死任務:
並非所有的執行者都是這樣的。有些人幾乎可以在幾秒內完成所有任務,而且這些任務的遠程讀取數據的大小與在其他服務器上等待很長時間的大小相同。 此外,這種類型的階段在我們的應用程序運行時間內運行兩次。產生這些具有較大洗牌讀取時間的任務組的服務器/執行者在每個階段運行中都是不同的。
下面是西弗斯/ hosts中的一個任務統計數據表的例子:
看起來負責該DAG的代碼如下:
output.write.parquet("output.parquet")
comparison.write.parquet("comparison.parquet")
output.union(comparison).write.parquet("output_comparison.parquet")
val comparison = data.union(output).except(data.intersect(output)).cache()
comparison.filter(_.abc != "M").count()
我們將高度讚賞你的想法。
奇怪。代碼和數據樣本將不勝感激。我看到DAG的每一步都有緩存調用,你緩存了一切嗎? – Garren
你好。謝謝你的問題。我在上面的描述中發佈了代碼。我們只在我們認爲需要時才緩存。 – Dimon
除了和相交的呼叫是我的擔心。您的DAG引用了sortmergejoin;你知道哪條線路造成了麻煩嗎? – Garren