Glue Job执行write_dynamic_frame.from_options()时无法写入Redshift且无响应

针对Glue Job能正常读取Redshift、S3临时目录已生成数据，但持续运行无法写入Redshift且无报错的情况，可从以下方向排查解决：

1. 明确指定写入模式 #

默认写入模式可能因数据冲突或表结构不匹配导致静默失败，需显式配置写入模式，并核对字段一致性：

• 在redshift_connection_options2中添加写入模式参数：

redshift_connection_options2 = {
    "url": "",
    "dbtable": "",
    "user": redshift_user,
    "password": redshift_password,
    "redshiftTmpDir": redshift_temp_dir,
    "mode": "append"  # 按需选overwrite/append/ignore
}

• 严格核对renamed_df的列名、数据类型与目标Redshift表完全一致，重点确认lastupdatedtimestamp的int类型是否与表中定义匹配。

2. 排查Redshift与S3的权限及路径配置 #

即使S3有数据，Redshift执行COPY命令时仍可能因权限或路径问题阻塞：

• 确保Redshift集群的IAM角色拥有S3临时目录的GetObject、ListBucket权限；
• 检查redshift_temp_dir是否为完整S3路径（格式如s3://your-bucket/temp-path/），路径末尾必须带斜杠；
• 确认Glue Job执行角色拥有该S3目录的读写权限，且Redshift能通过IAM角色正常访问该路径。

3. 优化Spark作业资源与参数 #

资源不足可能导致写入阶段无响应：

• 提升Glue Job的DPU数量，或调整Executor内存、Core数；
• 在Spark会话中添加性能优化参数：

spark.conf.set("spark.sql.execution.arrow.enabled", "true")
spark.conf.set("spark.redshift.copy.batch.size", "100000")

4. 检查Redshift系统表定位隐藏错误 #

Glue日志无报错不代表Redshift端无异常，查询Redshift系统表排查：

-- 查看最近的COPY执行记录
SELECT * FROM STL_LOAD_COMMITS WHERE tablename = '你的目标表名' ORDER BY starttime DESC LIMIT 10;
-- 查看COPY错误详情
SELECT * FROM STL_LOAD_ERRORS WHERE tablename = '你的目标表名' ORDER BY starttime DESC LIMIT 10;

5. 简化动态帧转换流程 #

避免DynamicFrame与DataFrame来回转换可能引入的隐性问题，直接用DynamicFrame处理字段转换：

from awsglue.transforms import ApplyMapping

renamed_dynamic_df = ApplyMapping.apply(
    frame=source_df,
    mappings=[
        ("lastupdatedtimestamp", "long", "lastupdatedtimestamp", "int"),
        # 其他字段映射保持原样
    ],
    transformation_ctx="renamed_dynamic_df"
)

内容的提问来源于stack exchange，提问作者Justin Newport