Spark：工作之间的延迟很长

Question

所以我们正在运行spark工作，它提取数据并进行一些扩展的数据转换并写入几个不同的文件。一切都运行良好，但我在资源密集型工作完成和下一个工作开始之间得到随机的广泛延迟。

在下图中，我们可以看到计划在17:22:02完成的工作需要15分钟才能完成，这意味着我预计下一份工作将在17:37:02左右安排。然而，下一份工作安排在22:05:59，这是工作成功后的+4小时。

当我深入研究下一个工作的火花UI时，它显示＆lt; 1秒调度程序延迟。所以我很困惑这4小时的延迟来自哪里。

（带有Hadoop 2的Spark 1.6.1）

更新

我可以确认David的回答是关于如何在Spark中处理IO操作有点出乎意料。 （考虑到订购和/或其他操作，文件写入基本上是＆＃34;收集＆＃34;在窗帘之后是有意义的。）但是我对I / O时间是这样的事实感到有点不安。不包括在作业执行时间内。我想你可以在＆＃34; SQL＆＃34;即使所有工作都取得成功，查询仍然在运行，但是根本无法深入研究，因此火花UI的选项卡仍在运行。

我确信还有更多方法可以改进，但以下两种方法对我来说已经足够了：

1. 减少文件数
2. 将parquet.enable.summary-metadata设为false

Answer 1

I / O操作通常会在主节点上产生很大的开销。由于这项工作没有并行化，因此可能需要相当长的时间。由于它不是一项工作，因此它不会显示在资源管理器UI中。由主节点

完成的I / O任务的一些示例

• Spark将写入临时s3目录，然后使用主节点
移动文件
• 通常在主节点上读取文本文件
• 在编写镶木地板文件时，主节点将在写入后扫描所有文件以检查架构

通过调整纱线设置或重新设计代码可以解决这些问题。如果您提供一些源代码，我可以找出您的问题。

Discussion of writing I/O Overhead

Discussion of reading I/O Overhead

Answer 2

问题：

当在 EMR 5.5.1 上使用pyspark在s3上编写镶木地板数据时，我遇到了类似的问题。所有工作人员将完成在输出文件夹的_temporary存储桶中写入数据，Spark UI将显示所有任务已完成。但是Hadoop Resource Manager UI不会释放该应用程序的资源，也不会将其标记为已完成。在检查s3存储桶时，似乎Spark驱动程序正在将文件从_temporary到1逐个移动到输出存储桶中，这非常慢，并且除了驱动程序节点之外，所有集群都处于空闲状态。

解决方案：

对我有用的解决方案是通过将配置属性EmrOptimizedSparkSqlParquetOutputCommitter设置为spark.sql.parquet.fs.optimized.committer.optimization-enabled来使用AWS（true）的committer类。

例如：

spark-submit ....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

或

pyspark ....... --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled = true

注意，此属性在EMR 5.19或更高版本中可用。

结果：

使用上述解决方案在EMR 5.20.0上运行spark作业后，它没有创建任何_temporary目录，并且所有文件都直接写入输出存储区，因此作业很快完成。

更多详细信息：
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html