Spark Stand Alone - 最後一步saveAsTextFile花費很多時間使用很少的資源編寫CSV文件

我們在獨立模式下運行Spark，並在240GB「大型」EC2框中使用3個節點將讀取到DataFrame中的三個CSV文件合併爲JavaRDD，使用s3a在S3上輸出CSV部分文件。Spark Stand Alone - 最後一步saveAsTextFile花費很多時間使用很少的資源編寫CSV文件

我們可以從Spark UI中看到第一階段的讀取和合並，以達到預期的100％CPU的最終JavaRDD運行，但使用saveAsTextFile at package.scala:179在CSV文件中寫出的最後階段會在很長時間內「卡住」 3個節點中的2個，其中32個任務中的2個需要花費數小時（盒的CPU佔用率爲6％，內存佔用率爲86％，網絡IO爲15kb/s，磁盤IO整個週期爲0）。

我們正在讀取和寫入未壓縮的CSV（我們發現未壓縮的速度比gzipped CSV快得多），在三個輸入數據幀的每一個上都有重新分區16，並且不會共享寫入。

希望得到任何提示，我們可以調查爲什麼最後階段需要花費很多時間在我們的獨立本地羣集中的3個節點中的2個上做很少的工作。

非常感謝

--- UPDATE ---

我試着寫到本地磁盤，而不是S3A和症狀是相同的 - 的32個任務2在最後階段saveAsTextFile「被困「幾個小時：

來源

2016-11-18 user894199

我見過類似的行爲。截至2016年10月，HEAD存在錯誤修復，可能與有關。但現在你可能使

spark.speculation=true

在 SparkConf

或spark-defaults.conf。

讓我們知道是否可以緩解問題。

來源

2016-11-18 05:53:40 javadba

感謝。我嘗試過，但症狀是一樣的，沒有明顯的變化。 – user894199

如果您通過s3n，s3a或其他方式寫入S3，除非要運行輸出損壞的風險，否則不要設置spark.speculation = true。我懷疑發生的事情是該進程的最後階段是重命名輸出文件，該文件在對象存儲上涉及複製大量數據（很多GB？）。重命名發生在服務器上，客戶端只保持打開HTTPS連接直到完成。我估計S3A的重命名時間約爲6-8兆字節/秒......這個數字是否與你的結果相符？

然後寫入本地HDFS，然後上傳輸出。

gzip壓縮不能分割，所以Spark不會將處理文件的部分分配給不同的執行者。一個文件：一個執行者。
嘗試並避免使用CSV，這是一種醜陋的格式。擁抱：Avro，Parquet或ORC。 Avro非常適合其他應用程序流入，其他應用程序更適合在其他查詢中進行下游處理。顯着更好。
並考慮使用諸如lzo或snappy等格式壓縮文件，這兩種文件都可以拆分。

又見幻燈片上21-22：http://www.slideshare.net/steve_l/apache-spark-and-object-stores

來源

2016-11-18 15:35:31

嗨史蒂夫。非常感謝您的回覆。是的，我聽說過重命名的問題，但是我們4個小時的閒置時間將意味着100GB的輸出文件 - 我們預計約5Gb。不幸的是，上游和下游處理我們不受我們的控制，並使用CSV。我們正在使用Spark 1.6。也許我們應該嘗試升級到2.0，如果寫入HDFS然後上傳不解決問題？ – user894199

我也嘗試過幻燈片21-22：http://www.slideshare.net/steve_l/apache-spark-and-object-stores，它們沒有什麼區別。 – user894199

您可以嘗試升級 - 值得其他原因（提示：DataFrames），但它不會更改低級S3連接或文件輸出提交者。上傳被鎖定時，請執行kill -QUIT以顯示所有被阻止的線程的堆棧 –

Spark Stand Alone - 最後一步saveAsTextFile花費很多時間使用很少的資源編寫CSV文件

回答

相關問題