cod*_*nky 17 hadoop scala apache-spark
因此,我们正在运行spark工作,提取数据并进行一些扩展的数据转换并写入几个不同的文件.一切都运行良好但我在资源密集型工作完成和下一个工作开始之间的随机扩张延迟.
在下图中,我们可以看到计划在17:22:02完成的工作需要15分钟才能完成,这意味着我预计下一份工作将在17:37:02左右安排.然而,下一份工作安排在22:05:59,这是工作成功后的+4小时.
当我深入研究下一个作业的火花UI时,它会显示<1秒的调度程序延迟.所以我很困惑这4小时的延迟来自哪里.
(带有Hadoop 2的Spark 1.6.1)
更新:
我可以确认David的回答是关于如何在Spark中处理IO操作有点出乎意料.(考虑到排序和/或其他操作,在写入之前,写入文件基本上会在幕后"收集"是有道理的.)但是,由于I/O时间不包含在作业执行时间中,我感到有些不安.我想你可以在spark UI的"SQL"选项卡中看到它,因为即使所有工作都成功但查询仍在运行,但你根本无法深入研究它.
我确信还有更多方法可以改进,但是下面两种方法对我来说已经足够了:
parquet.enable.summary-metadata
falseDav*_*vid 26
I/O操作通常会在主节点上发生显着的开销.由于这项工作没有并行化,因此可能需要相当长的时间.由于它不是一项工作,因此它不会显示在资源管理器UI中.主节点完成的I/O任务的一些示例
这些问题可以通过调整纱线设置或重新设计代码来解决.如果您提供一些源代码,我可以找出您的问题.
问题:
在EMR 5.5.1上使用 pyspark 在 s3 上写入镶木地板数据时,我遇到了类似的问题。所有工作人员将完成_temporary
在输出文件夹中的存储桶中写入数据,Spark UI 将显示所有任务已完成。但 Hadoop 资源管理器 UI 不会为应用程序释放资源,也不会将其标记为完成。在检查 s3 存储桶时,似乎 Spark 驱动程序正在将文件 1 个一个地从_temporary
目录移动到输出存储桶,这非常慢并且除了驱动程序节点之外,所有集群都处于空闲状态。
解决方案:
对我有用的解决方案是通过EmrOptimizedSparkSqlParquetOutputCommitter
将配置属性设置spark.sql.parquet.fs.optimized.committer.optimization-enabled
为 来使用 AWS () 的提交者类true
。
例如:
火花提交....... --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
归档时间: |
|
查看次数: |
6274 次 |
最近记录: |