PySpark DataFrame写入BigQuery超24小时未完成，求解决方案

一、先排查DataFrame性能瓶颈 #

• 检查数据源：如果df来自未优化的存储（如单节点CSV、无分区的普通表），先将数据源转换为Delta Lake格式，或添加分区、分桶配置，减少全量扫描的数据量。
• 分析执行计划：运行df.explain()，查看是否存在不必要的shuffle操作、全表扫描，或数据倾斜情况——800万行3列的数据量不算大，这类问题会显著拖慢计算。
• 缓存验证：执行df.cache()后再运行display(df)，如果提速明显，说明是重复计算导致的慢，后续操作前先缓存df。

二、调整集群资源与配置 #

• 扩容集群规模：当前集群可能资源不足，建议配置2-4个worker节点，每个节点至少4核16G内存，避免单节点负载过高。
• 优化Spark参数：调整shuffle和内存相关配置，适配集群资源：

  spark.conf.set("spark.sql.shuffle.partitions", "200")  # 分区数匹配资源，每个分区100-200MB为宜
  spark.conf.set("spark.executor.memoryOverhead", "4096")  # 增加内存预留，防止OOM
  

• 关闭不合理的自动缩放：如果集群启用了自动缩放但阈值设置过高，可能导致资源迟迟不分配，改为固定worker数量再尝试。

三、优化BigQuery写入环节 #

• 验证临时GCS桶权限：确保Databricks集群的服务账号拥有GCS的读写权限，以及BigQuery的表写入权限——权限不足常导致静默等待无报错。
• 指定分区写入（若目标表为分区表）：添加分区字段配置，减少写入时的数据整理开销：

  df\
      .write\
      .format("bigquery")\
      .option("temporaryGcsBucket", "databricks-bq-342")\
      .option("table", "database1:merch.table1")\
      .option("partitionField", "your_partition_col")\  # 替换为实际分区字段
      .mode("overwrite")\
      .save()
  

• 拆分写入流程：先将df写入GCS作为中间存储，再通过BigQuery的LOAD API导入，拆分环节定位问题：

  # 先写入GCS Parquet
  df.write.format("parquet").mode("overwrite").save("gs://databricks-bq-342/temp_parquet")
  # 再通过BigQuery工具导入（可在Databricks用%bash调用bq命令）
  

四、通过日志定位问题 #

• 查看Spark UI：在Databricks集群页面打开Spark UI，检查Stage和Task的执行状态，是否有单个Task卡住、数据倾斜导致的超时。
• 查看BigQuery作业日志：在GCP控制台的BigQuery页面，查看对应表的写入作业记录，排查是否有格式错误、权限报错等隐藏问题。

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