Databricks写入Synapse（Azure DW）速度极慢问题排查

首先可以明确：7分钟加载10000行40列的数据绝对不正常，Databricks + SQL DW连接器的性能应该能接近ADF的水平，大概率是配置或使用方式存在优化空间，下面分点拆解可能的问题和对应的解决方案：

1. PolyBase未正确启用或暂存层配置不合理 #

你的代码里虽然指定了tempdir和forward_spark_azure_storage_credentials，但可能没充分利用PolyBase（这是Synapse批量加载的核心优化点，ADF正是依赖它实现高速写入）：

• 显式开启PolyBase：部分旧版本的连接器不会默认启用，需要添加option("usePolybase", "true")到写入配置中；
• 暂存存储的性能与区域：tempdir对应的存储账户如果是跨区域的，会产生大量网络延迟；另外，建议使用高级Blob存储或ADLS Gen2（标准存储的IOPS上限低，会成为瓶颈）；
• 凭证转发有效性：确认forward_spark_azure_storage_credentials确实生效——Databricks集群的服务主体需要拥有暂存存储账户的Blob Contributor权限，否则连接器会 fallback 到低效的批量插入模式。

2. Spark并行度与集群资源不足 #

Spark的并行处理能力直接影响写入速度，默认配置可能没适配你的场景：

• 数据分区数不足：10000行的数据量很小，但如果Spark默认分区数太少（比如只有2-4个），会导致写入时并行度不够。可以在写入前手动重分区：

  df_insert.repartition(8) // 数值建议匹配集群的核心数，比如8核集群就设8
    .format("com.databricks.spark.sqldw")
    // 其他配置...
    .save()
  

• 集群规模过小：如果你的Databricks集群是单节点、小规格（比如Standard_DS2_v2），CPU/内存资源不足会拖慢数据处理和上传到暂存层的速度，建议升级到至少4核的中等规格节点。
• 序列化方式优化：默认的Java序列化效率较低，在集群配置中开启Kryo序列化可以减少数据传输开销：

  spark.serializer org.apache.spark.serializer.KryoSerializer
  

3. 连接器版本过旧或兼容性问题 #

旧版本的Databricks SQL DW连接器可能存在性能瓶颈或未优化PolyBase的使用：

• 检查连接器版本：确保使用与你的Spark版本兼容的最新版，比如Spark 3.3对应com.databricks:spark-sqldw_2.12:2.0.0及以上版本（版本号随Spark版本调整）。

4. Synapse SQL池的限制或负载 #

写入速度也受Synapse侧的配置影响：

• DWU规格过小：如果你的Synapse SQL池是低规格（比如DW100c），其写入吞吐量有限，即使Databricks这边处理快，Synapse也无法及时处理请求；
• 侧负载干扰：写入时如果Synapse有其他查询、ETL任务在运行，会占用资源导致写入变慢，建议在低负载时段测试；
• 表结构优化：如果目标表有大量索引、约束，写入时会触发额外的计算开销，建议先禁用索引，写入完成后再重建。

5. 数据类型转换开销 #

虽然你的数据是40列，但如果存在Spark与Synapse不兼容的数据类型（比如Spark的ArrayType、StructType，或者字符串长度不匹配），会产生额外的转换开销：

• 确保Spark中的数据类型与Synapse目标表的类型严格匹配，比如将Spark的StringType映射到Synapse的VARCHAR而非NVARCHAR（后者存储开销更大）；
• maxStrLength的设置是否合理？如果设置过大（比如超过实际字符串长度很多），会导致暂存层存储的文件变大，增加传输时间。

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