PySpark写入Redshift速度异常缓慢，寻求优化排查方案

针对你遇到的问题——50万行100列的DataFrame读解析都快，但写入Redshift甚至5行都要8秒，大概率是写入配置或方式出了问题，我整理了几个优先级最高的排查方向，按顺序来试：

1. 确认是否用了高效的写入方式（COPY而非JDBC直写） #

PySpark写Redshift最忌讳直接用JDBC逐行插入，哪怕少量数据也会因为连接建立、事务开销变得极慢。正确的姿势是先把数据写到S3临时目录，再通过Redshift的COPY命令批量导入——这也是官方推荐的方式。

检查你的代码是否用了com.databricks.spark.redshift格式（或AWS官方的org.apache.spark.sql.redshift），并且指定了tempdir参数指向S3目录。如果是用普通的JDBC格式（jdbc:redshift://...直接写），立刻改成COPY模式，代码示例：

df.write \
  .format("com.databricks.spark.redshift") \
  .option("url", "jdbc:redshift://your-cluster-endpoint:5439/your-db?user=xxx&password=xxx") \
  .option("dbtable", "your_schema.your_table") \
  .option("tempdir", "s3://your-bucket/path/to/temp/")  # 必须和Redshift同区域！
  .option("batchsize", "10000")  # 调大批量写入的大小
  .mode("append") \
  .save()

2. 检查S3临时目录的关键配置 #

• 同区域部署：S3临时桶必须和Redshift集群在同一个AWS区域，跨区域的网络延迟会直接拖慢数据传输，哪怕5行也会体现出来。
• 权限配置：确保Redshift集群的IAM角色拥有这个S3临时目录的读写权限（s3:GetObject、s3:PutObject、s3:DeleteObject），权限不足会导致隐性的重试等待，看起来就是写入慢。
• 减少小文件：Spark默认的分区数可能太多，导致生成大量S3小文件，Redshift处理小文件的效率极低。可以在写入前调整分区数：

  # 50万行的话，设置成20-50个分区足够
  df = df.repartition(30)
  

3. 调优Redshift端的写入参数 #

• 调大批量大小：设置spark.redshift.batch.size（或直接在option里写batchsize），默认是1000，建议调到5000-20000，减少COPY的次数。
• 优化COPY命令：可以自定义copycommand参数，添加一些优化选项，比如IGNOREHEADER 1（如果有表头）、COMPUPDATE OFF（暂时关闭自动压缩，写完再开启）、STATUPDATE OFF（关闭统计信息更新，后续手动刷新）：

  .option("copycommand", "COPY {table} FROM '{temp_file}' CREDENTIALS 'aws_iam_role=arn:aws:iam::xxx:role/your-redshift-role' DELIMITER ',' CSV IGNOREHEADER 1 COMPUPDATE OFF STATUPDATE OFF")
  

• 禁用表约束：如果目标表有主键、外键约束或触发器，写入时会额外消耗资源做校验。可以先执行ALTER TABLE your_table DISABLE CONSTRAINT your_constraint，写完再重新启用。

4. 排查5行数据慢的根因（缩小问题范围） #

既然5行都慢，说明不是数据量的问题，而是单次写入的开销过大：

• 开启Spark的DEBUG日志，查看写入阶段的耗时分布：是S3上传临时文件慢？还是Redshift执行COPY慢？
• 手动在Redshift控制台执行一次COPY命令，用Spark生成的临时S3文件，看速度如何。如果手动COPY快，问题在Spark配置；如果手动也慢，检查Redshift集群的WLM队列是否被占满，或者S3的网络是否有异常。
• 检查JDBC连接参数，比如是否设置了合理的connectTimeout和socketTimeout，避免不必要的超时重试。

5. 其他小细节 #

• 确认Spark使用的Redshift驱动版本是否兼容，建议用最新的稳定版（比如databricks的redshift connector 6.x+）。
• 避免在写入前做不必要的宽依赖操作，确保DataFrame已经是最终状态，没有隐藏的计算延迟。

按照这个顺序排查，大概率能找到你配置里的问题——我遇到过很多用户都是因为用了JDBC直写、S3跨区域，或者临时目录权限不对导致的写入慢。

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