将 DAG 转换为任务的巨大延迟答案

【问题标题】：Huge delays translating the DAG to tasks将 DAG 转换为任务的巨大延迟
【发布时间】：2017-01-09 22:30:21
【问题描述】：

这是我的步骤：

将 spark 应用提交到 EMR 集群
驱动程序启动，我可以看到 Spark-ui（尚未创建任何阶段）
驱动程序从 s3 读取一个包含约 3000 个部分的 orc 文件，进行一些转换并将其保存回 s3
保存的执行应该在 spark-ui 中创建一些阶段，但是这些阶段需要很长时间才能出现在 spark-ui 中
阶段出现并开始执行

为什么我在第 4 步中会出现如此大的延迟？在此期间，集群显然在等待某些东西，CPU 使用率为 0%

谢谢

【问题讨论】：

标签： apache-spark amazon-emr apache-spark-2.0

【解决方案1】：

尽管 S3 有其优点，但它并不是一个文件系统，它使其成为处理复杂二进制格式的次优选择，这些格式通常在设计时考虑到实际文件系统。在许多情况下，次要任务（如读取元数据）比实际数据获取更昂贵。

【讨论】：

【解决方案2】：

大概是3&4之间的commit过程； Hadoop MR 和 spark 提交者假设 rename 是一个 O(1) 原子操作，并依靠它来完成工作的原子提交。在 S3 上，当涉及目录中的多个文件时，重命名是 O(data) 且非原子的。 0-CPU 负载是赠品：客户端只是在等待来自 S3 的响应，它在内部以 6-10 MB/S 的速度执行 COPY

HADOOP-13345 正在进行在 S3 中进行 0 重命名提交的工作。现在，您可以从 Databricks 寻找著名但以有趣方式失败的 Direct Committer。

还有一件事：确保您使用“算法 2”进行提交，因为算法 1 在最终作业主提交中进行了更多重命名。我对 Hadoop 2.7 上 ORC/Parquet 性能的完整推荐设置是（以及使用 s3a: urls）：

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

【讨论】：