1

这是我的步骤：

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

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

谢谢

4

2 回答 2

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
于 2017-01-10T13:39:40.083 回答
2

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

于 2017-01-09T22:54:58.860 回答