Databricks上Pyspark DataFrame写Parquet到S3中途卡住如何解决

问题根因 #

你遇到的卡死问题本质是超大规模（250万亿行）数据集写入S3时，默认Spark配置没有适配S3的对象存储特性，同时存在分区倾斜、小文件/大文件失衡、提交器开销过大等共性问题，以下是可直接落地的优化方案：

1. 数据分区与并行度优化 #

• 先排查分区键倾斜：提前统计分区键的数值分布，避免单个分区承载绝大多数数据导致单Task卡死

  df.groupBy("column-name").count().orderBy(col("count").desc()).show()
  

  如果存在明显倾斜，要么切换为高基数联合分区键（如日期+业务标识），要么对大分区做加盐拆分。
• 控制分区键基数：最优基数保持在100~10000区间，基数过低会导致单分区文件过大，基数过高会导致S3目录爆炸、元数据开销拉满。
• 调整输出文件大小：Parquet格式最优单文件大小为128MB~256MB，先根据总数据量计算总并行度，按分区键打散重分区，避免小文件过多或单文件过大：

  # num_partitions = 总数据量 / 128MB，可根据实际集群规模调整
  df = df.repartition(numPartitions=num_partitions, col("column-name"))
  

• Spark 3.0+版本开启自适应查询执行（AQE），自动优化倾斜、动态调整并行度：

  spark.conf.set("spark.sql.adaptive.enabled", "true")
  spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
  spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")
  

2. S3写入专属优化 #

• 替换默认提交器：默认FileOutputCommitter在S3上的rename操作开销极高，超大规模数据下会直接卡死，切换为S3专属提交器：

  spark.conf.set("spark.sql.sources.commitProtocolClass", "org.apache.spark.sql.execution.datasources.S3ParquetOutputCommitter")
  spark.conf.set("spark.hadoop.fs.s3a.committer.name", "directory")
  spark.conf.set("spark.hadoop.fs.s3a.committer.staging.conflict-mode", "replace")
  spark.conf.set("spark.hadoop.fs.s3a.fast.upload", "true")
  

• 关闭非必要的元数据生成：超大规模下Parquet元数据聚合会占满内存，直接关闭：

  spark.conf.set("spark.sql.parquet.summary.metadata.level", "NONE")
  

• 调大S3分片上传大小，减少IO请求次数：

  spark.conf.set("spark.hadoop.fs.s3a.multipart.size", "104857600") # 100MB分片
  

3. 写入逻辑优化 #

• 允许增量写入的场景优先用追加模式，避免全量覆盖的开销：

  df.write.parquet("s3://your-bucket/path", mode = "append", partitionBy = "column-name")
  

• 必须全量覆盖的场景开动态分区覆盖，只覆盖本次有数据变动的分区，无需全量删改：

  spark.conf.set("spark.sql.sources.partitionOverwriteMode", "dynamic")
  df.write.parquet("s3://your-bucket/path", mode = "overwrite", partitionBy = "column-name")
  

4. 极端场景兜底方案 #

如果上述优化后仍无法跑通，将数据集按分区键范围拆分为多批，分批写入S3，避免单次任务占用的内存、IO资源超过集群上限。

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