Glue Dynamic Frame 比普通 Spark 慢得多

Question

在下图中，我们使用三种不同配置运行相同的粘合作业，以了解如何写入 S3：

1. 我们使用动态帧写入S3
2. 我们使用纯spark框架来写入S3
3. 与 1 相同，但工作节点数量从 80 个减少到 60 个

• 在所有条件相同的情况下，动态框架需要 75 分钟才能完成这项工作，普通 Spark 需要 10 分钟。输出了 100 GB 的数据。
• 动态帧对worker节点数量超级敏感，稍微减少worker节点数量时，处理2小时后会因内存问题而失败。这是令人惊讶的，因为我们期望 Glue 作为一项 AWS 服务能够更好地处理 S3 写入操作。

代码差异是这样的：

if dynamic:
    df_final_dyn = DynamicFrame.fromDF(df_final, glueContext, "df_final")

    glueContext.write_dynamic_frame.from_options(
    frame=df_final_dyn, connection_type="s3", format="glueparquet", transformation_ctx="DataSink0",
    connection_options={"path": "s3://...", 
    "partitionKeys": ["year", "month", "day"]})
else:
    spark.conf.set("spark.sql.sources.partitionOverwriteMode", "dynamic")
    df_final.write.mode("overwrite").format("parquet").partitionBy("year", "month", "day")\
             .save("s3://.../")

为什么效率这么低？

Answer 1

我参加聚会迟到了，但这里是根据我的经验提供的一些意见。

在 Glue 中从 S3 读取时可以进行一些优化。 这是来自 AWS 的一篇关于该主题的精彩文章：https://aws.amazon.com/blogs/big-data/optimize-memory-management-in-aws-glue/

这些是我们有幸使用动态框架实现稳定且高性能的 Glue 作业：

'useS3ListImplementation': True
'groupFiles': 'inPartition'
'groupSize': '<some-int>' // some value between 1048576 and 134217728

为了防止 Glue 中的内存故障并增加并行化，

groupSize

是一个关键配置。如果没有它，Glue 会以某种方式动态计算组大小，根据我的经验，当任务获取太多数据时，这可能会导致随机失败。

另一件事是让 Glue 和 Spark 测试更加等效：例如跳过“transformation_ctx”，因为它可能会导致一些开销。