2017-08-17 117 views
1

我們正在運行以下階段DAG和經歷較長洗牌閱讀時間相對較小洗牌的數據尺寸(約每任務19MB)星火洗牌讀需要顯著時間小數據

enter image description here

一個有趣的方面是每個執行器/服務器中的等待任務具有相同的洗牌讀取時間。下面是一個例子:對於下面的服務器,一組任務等待約7.7分鐘,另一組等待約26秒。

enter image description here

下面是從同一階段運行的另一個例子。該圖顯示了3個執行者/服務器,每個具有相同的洗牌讀取時間的統一的任務組。藍組表示,由於推測執行打死任務:

enter image description here

並非所有的執行者都是這樣的。有些人幾乎可以在幾秒內完成所有任務,而且這些任務的遠程讀取數據的大小與在其他服務器上等待很長時間的大小相同。 此外,這種類型的階段在我們的應用程序運行時間內運行兩次。產生這些具有較大洗牌讀取時間的任務組的服務器/執行者在每個階段運行中都是不同的。

下面是西弗斯/ hosts中的一個任務統計數據表的例子:

enter image description here

看起來負責該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() 

我們將高度讚賞你的想法。

+1

奇怪。代碼和數據樣本將不勝感激。我看到DAG的每一步都有緩存調用,你緩存了一切嗎? – Garren

+0

你好。謝謝你的問題。我在上面的描述中發佈了代碼。我們只在我們認爲需要時才緩存。 – Dimon

+0

除了和相交的呼叫是我的擔心。您的DAG引用了sortmergejoin;你知道哪條線路造成了麻煩嗎? – Garren

回答

0

顯然問題是JVM垃圾回收(GC)。任務必須等到GC在遠程執行器上完成。相同的洗牌讀取時間是由於幾個任務正在等待執行GC的單個遠程主機的事實。我們按照提示here,問題減少了一個數量級。遠程主機上的GC時間與本地shuffle讀取時間之間的關聯仍然很小。將來我們會考慮嘗試洗牌服務。