10DPU配置Glue作业写入Redshift速度过慢的优化方案咨询

问题1：10 DPU配置下Glue写入Redshift耗时过长的解决思路 #

导致耗时过长的核心原因通常是并行度不匹配、写入模式选择错误，可从以下方向调整：

• 调整Spark并行度：你当前的45GB数据仅拆分为6个CSV文件，对应Spark初始只有6个分区，完全无法跑满10 DPU的计算资源。建议将转换后的数据通过repartition()调整为20_{30个分区，单分区大小控制在1}2GB，避免单分区过大拖慢整体执行速度。
• 禁用JDBC直写模式：Glue默认的JDBC批量插入模式单链路吞吐量极低，完全不适配GB级以上的数据写入，是最常见的耗时原因。
• 调整Redshift侧前置配置：写入前临时关闭目标表的索引、暂停关联的物化视图刷新任务，避免写入时的资源抢占；如果目标表设置了分布键，提前保证Spark侧的数据分布和Redshift分布键对齐，减少Redshift写入后的重分布开销。

问题2：先写Parquet到S3再用COPY命令写入Redshift的可行性 #

该方案是Redshift批量加载的官方推荐方案，相比直接JDBC写入速度可提升3~10倍，核心优势如下：

• Parquet是列式压缩存储，45GB的CSV转成Snappy压缩的Parquet通常仅为10~15GB，大幅降低数据传输和加载开销。
• Redshift的COPY命令是原生批量加载工具，支持并行加载S3上的多份Parquet文件，可自动利用Redshift集群的所有节点资源加载，效率远高于JDBC单链路插入。
• 中间落盘S3的Parquet文件可作为临时备份，后续如果需要重跑加载任务，不需要重新执行Glue转换逻辑，直接调用COPY即可。

最优实现方案 #

方案A：Glue内置连接器自动实现（推荐，代码最简洁） #

Glue 3.0及以上版本的Redshift连接器底层已经自动实现了「先写Parquet到S3临时路径再调用COPY加载」的逻辑，不需要手动实现全流程，仅需在写入时指定临时路径即可，代码示例如下：

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame = 转换完成后的动态帧变量,
    catalog_connection = "你在Glue中配置的Redshift连接名称",
    connection_options = {
        "dbtable": "目标表的schema.表名",
        "database": "Redshift数据库名",
        "tempDir": "s3://你的存储桶路径/glue-temp/"
    },
    redshift_tmp_dir = "s3://你的存储桶路径/glue-temp/"
)

方案B：手动实现全流程（可控性更高） #

如果需要对中间过程做自定义调整，可以手动拆分流程实现：

1. 转换逻辑完成后，将数据集按「Redshift集群节点数 * 2~4」的数量做重分区，保证COPY阶段的并行度和Redshift集群能力匹配。
2. 将重分区后的数据以Snappy压缩的Parquet格式写入S3临时路径，代码示例：

transformed_dynamic_frame.toDF().write.mode("overwrite").parquet(
    "s3://你的存储桶路径/redshift-load-temp/",
    compression="snappy"
)

3. 通过Glue集成的Redshift Data API调用COPY命令加载数据，SQL示例：

COPY 目标表名
FROM 's3://你的存储桶路径/redshift-load-temp/'
IAM_ROLE '你配置的Redshift加载用IAM角色ARN'
FORMAT PARQUET
REGION '资源所在的AWS区域'
COMPUPDATE OFF
STATUPDATE OFF;

加载完成后可手动执行ANALYZE 目标表名更新表统计信息，保证后续查询性能。
4. 加载校验完成后，删除S3临时路径的Parquet文件，避免存储浪费。

内容的提问来源于stack exchange，提问作者Aditya Verma