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”，因为它可能会导致一些开销。