PySpark relationalize处理大文件时未写入S3问题求助

可能原因及对应处理方式 #

1. 任务未显式触发执行（最常见） #

AWS Glue的DynamicFrame操作采用懒执行机制，relationalize仅定义转换逻辑，dfc.keys()只是获取生成的表名，并未实际触发数据写入动作。小文件因数据量小，可能在printSchema等操作时隐式触发计算，但大文件需要显式执行写入步骤。

解决：遍历dfc中的每个DynamicFrame，调用写入方法触发执行：

# 遍历所有生成的表并写入S3
for table_name, frame in dfc.items():
    glueContext.write_dynamic_frame.from_options(
        frame=frame,
        connection_type="s3",
        connection_options={"path": f"s3://mikas-rubbishbin/output/{table_name}/"},
        format="parquet"  # 可替换为csv等你需要的格式
    )

2. S3权限或存储类问题 #

• 检查Glue任务角色是否拥有s3:PutObject权限到目标桶路径s3://mikas-rubbishbin/output/，大文件写入时权限校验更严格（如跨区域写入的额外权限要求）。
• 若目标路径启用了S3智能分层或归档存储类，可能存在写入延迟，可临时切换到标准存储类测试。
• 确认目标路径未开启版本控制导致覆盖冲突（概率较低，可临时关闭验证）。

3. 内存/资源不足导致写入失败 #

XML文件解析后数据量会大幅膨胀（结构冗余度高），10MB的原文件可能生成数倍大小的中间数据，Glue默认资源配置可能不足以支撑写入。

解决：

• 调整Glue任务的Worker类型（如从Standard切换到G.1X/G.2X）和Worker数量。
• 在任务配置中添加参数提升内存：--conf spark.driver.memory=4g --conf spark.executor.memory=8g

4. 隐藏的格式异常数据 #

大文件中可能存在小文件没有的格式错误，relationalize的keys()仅提取结构不校验全量数据，实际写入时会因坏数据失败。

解决：

• 执行dyf.toDF().count()触发全量数据校验，查看是否抛出异常。
• 使用dyf.filter()逐步排查并过滤坏数据行。

5. S3路径冲突或缓存问题 #

• 确认目标路径未被其他任务占用，或之前写入残留隐藏文件（如.part-xxxx.crc），可清空路径后重试。
• 用AWS CLI执行aws s3 ls s3://mikas-rubbishbin/output/ --recursive确认文件状态，S3控制台可能存在缓存延迟。

内容的提问来源于stack exchange，提问作者Mika Smirnovs