巨大的延誤翻譯DAG到任務

這是我的步驟：巨大的延誤翻譯DAG到任務

提交火花應用到EMR集羣
駕駛員開始，我可以看到火花UI（無階段都尚未創建）
驅動程序從s3讀取一個〜3000部分的orc文件，進行一些轉換並將其保存回s3
保存的執行應該在spark-ui中創建一些階段，但階段需要很長時間出現在spark-ui
階段出現並開始執行

爲什麼我在步驟4中得到那麼大的延遲？在此期間，集羣顯然是在等待着什麼，並且CPU使用率是0％

感謝

來源

2017-01-09 Mikel

關注其S3不是一個文件系統，它使一個次優的選擇。與複雜的二進制格式這是工作通常根據實際的文件系統設計。在許多情況下，輔助任務（如讀取元數據）比實際的數據獲取要貴。

來源

2017-01-09 22:54:58 user7396747

這可能是3 & 4之間的提交過程; Hadoop MR和spark提交者假定rename是一個O（1）原子操作，並依靠它來完成工作的原子提交。在S3上，當涉及目錄中的多個文件時，重命名是O（數據）並且是非原子的。 0-CPU的負載是免費的：客戶端只是等待S3的響應，這是在內部以6-10 MB /秒的速度進行COPY的響應

HADOOP-13345正在進行中的工作，以便在S3中執行0重命名提交。就目前而言，您可以從Databricks中尋找着名的但失敗的有趣方式Direct Committer。

還有一件事：確保您使用「算法2」進行提交，因爲算法1在最終作業主提交中執行了更多重命名操作。我在Hadoop 2.7上推薦的ORC/Parquet perf的設置是（與使用s3a：url一起）：

spark.sql.parquet.filterPushdown true 
spark.sql.parquet.mergeSchema false 
spark.hadoop.parquet.enable.summary-metadata false 

spark.sql.orc.filterPushdown true 
spark.sql.orc.splits.include.file.footer true 
spark.sql.orc.cache.stripe.details.size 10000 

spark.sql.hive.metastorePartitionPruning true 
spark.speculation false 
spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2 
spark.hadoop.mapreduce.fileoutputcommitter.cleanup.skipped true

來源

2017-01-10 13:39:40

巨大的延誤翻譯DAG到任務

回答

相關問題