AWS Glue Job读取海量S3文件时create_dynamic_frame_from_options失败求助

看起来你遇到的是典型的海量小文件场景下Glue Job资源瓶颈和网络异常问题，咱们先从修复当前Job的运行问题入手，再聊聊更适合这种大规模数据转换的优化方案：

你的核心矛盾是2000万用户文件夹对应的超大量文件路径直接耗尽了Driver内存，同时useS3ListImplementation=True在处理海量文件列表时触发了SSL握手和HTTP请求异常，导致任务无法正常分发到执行器。

1. 解决文件列表加载与网络异常 #

• 禁用useS3ListImplementation：这个参数会让Driver独自承担所有文件路径的扫描工作，面对2000万+的文件数量，直接导致内存占满。改用默认的文件发现机制后，Spark会把文件列表的加载分散到执行器上，大幅减轻Driver压力。
• 升级Driver内存：在Glue Job的「Job parameters」中添加--driver-memory 32g（G.2X实例最大支持64g，可根据实际情况调整），确保Driver有足够内存处理初始元数据扫描。
• 提升S3请求容错性：添加Spark配置参数增强网络异常的重试能力，解决close_notify during handshake这类问题：

  --conf spark.hadoop.fs.s3a.connection.maximum=500
  --conf spark.hadoop.fs.s3a.retry.max=10
  --conf spark.hadoop.fs.s3a.connection.timeout=30000
  

2. 优化文件合并与资源利用率 #

当前的groupFiles参数设置未生效（因为你的S3结构未注册为Glue正式分区），调整参数让文件合并逻辑发挥作用：

• 将groupFiles改为"merge"，让Glue跨用户文件夹合并小文件，达到groupSize（100MB）阈值后再处理，减少小文件数量，提升执行器利用率。
• 调整执行器配置：设置执行器数量为30-50个，同时添加--executor-cores 4和--executor-memory 16g，让每个执行器有足够资源处理合并后的文件，避免资源闲置。

3. 分批处理降低单次任务压力 #

如果一次性扫描所有用户仍有问题，可以按userId前缀拆分任务（比如按首两位字符分成100组），分批处理：

# 示例：按userId首两位分批处理
prefix_groups = [f"{i:02d}" for i in range(100)]
for prefix in prefix_groups:
    target_path = f"s3://bucketname/prefix/{prefix}*"
    datasource = glueContext.create_dynamic_frame_from_options(
        "s3",
        {'paths': [target_path], 'recurse': True, 'groupFiles': 'merge', 'groupSize': 100 * 1024 * 1024},
        format="json",
        transformation_ctx = f"datasource_{prefix}"
    )
    # 转换为Parquet并写入输出路径
    parquet_df = datasource.toDF()
    parquet_df.write.mode("append").parquet(f"s3://output-bucket/parquet-output/{prefix}/")

考虑到你有2000万用户的海量小文件，一次性处理效率偏低，推荐以下架构优化：

1. 先合并小文件再转换格式 #

用Spark的分区能力合并小文件，确保输出的Parquet文件大小在100-200MB区间（最优Parquet文件大小）：

# 读取所有JSON文件
raw_df = spark.read.json("s3://bucketname/prefix/*/*.gz")
# 按userId分区，并设置合适的并行度合并文件
raw_df.repartition(1000).write.partitionBy("userId").parquet("s3://output-bucket/parquet-data/")

这里repartition(1000)可根据你的目标文件大小调整，确保每个输出文件大小适中。

2. 注册Glue分区表优化后续查询 #

转换完成后，用Glue Crawler将输出的Parquet数据注册为分区表，把userId设为分区键，后续查询时可直接裁剪分区，大幅提升查询效率。

3. 并行化处理的替代方案 #

如果Glue Job的性能仍达不到预期，可以考虑用AWS Batch结合Spark集群处理：

• 将用户列表拆分成多个子任务，每个Batch任务处理一部分用户的文件
• 利用Spot实例降低成本，通过Batch的调度能力实现大规模并行处理

内容的提问来源于stack exchange，提问作者Balamurugan Balasubramanian