Databricks Spark写入Azure SQL性能低下是否为单节点集群原因？

首先纠正一个Spark新手常见的认知错误：你观测到前两步仅耗时不到1秒，是因为Spark的转换算子（读取、去重、排序）均为懒加载模式，仅在遇到action算子（write、count等）时才会真正执行全量计算。你调用的show()默认仅拉取20行数据，所以仅扫描了CSV文件的极小片段，缓存也仅生效于这20行数据，全量的读取、去重、排序逻辑实际是和写入操作绑定执行的，这部分隐藏开销也是写入耗时偏长的原因之一。

一、代码逻辑优化 #

• 移除无意义的排序逻辑：orderBy(col("EventId").asc())完全没有必要，写入关系型数据库的行顺序不影响后续使用，排序操作会消耗大量CPU和内存资源，直接删除即可。
• 提前触发计算避免开销叠加：去重完成后调用clearedDF.count()触发全量计算，同时让weatherDF的缓存真正生效，避免计算和写入IO的开销叠加。
• 合理设置持久化级别：对去重后的DataFrame设置内存+磁盘的持久化级别，避免写入过程中分区数据重复计算。

二、JDBC写入参数优化 #

你当前的参数配置存在明显不合理的地方，调整后可提升至少2倍写入速度：

• 调低batchsize到10000~20000：SQL Server的最优批量提交大小在1-2万区间，你设置的10万会导致单次提交事务过大，触发事务日志刷盘瓶颈，反而拖慢速度。
• 启用批量复制专用表锁：替换普通tableLock为bulkCopyTableLock，这是微软Spark SQL连接器专属的批量写入优化参数，比普通表锁的写入效率高30%以上。
• 关闭冗余schema校验：如果你的DataFrame schema和目标表完全匹配，添加schemaCheckEnabled=false参数，关闭元数据校验的额外开销。

优化后的核心代码示例：

# 去重逻辑优化，删除无用的orderBy
clearedDF = weatherDF.dropDuplicates(["Type", "Severity", "StartTime(UTC)", "EndTime(UTC)", "City"])
# 提前触发计算，让缓存生效
clearedDF.persist()
clearedDF.count()

jdbcHost = dbutils.secrets.get(scope="adminSecrets", key="dbServer")
jdbcPort = "1433"
jdbcDatabase = dbutils.secrets.get(scope="adminSecrets", key="dbName")
jdbcUrl = "jdbc:sqlserver://{0}:{1};database={2}".format(jdbcHost, jdbcPort, jdbcDatabase)

try:
  (clearedDF.repartition(4).write
    .format("com.microsoft.sqlserver.jdbc.spark")
    .option("batchsize", 20000)
    .option("bulkCopyTableLock", "true")
    .option("schemaCheckEnabled", "false")
    .option("url", jdbcUrl)
    .option("dbtable", "dbo.weather")
    .option("user", dbutils.secrets.get(scope="adminSecrets", key="adminLogin"))
    .option("password", dbutils.secrets.get(scope="adminSecrets", key="adminPassword"))
    .mode("overwrite")
    .save()
  )
  clearedDF.unpersist()
except ValueError as error:
  print(str(error))

三、Azure SQL侧优化 #

这部分的优化收益通常最大：

• 临时提升Azure SQL服务层级：如果你用的是Basic、Standard S0-S2等低配比实例，本身IOPS上限极低，300万行写入耗时数分钟是正常现象，写入前临时升到P2及以上层级，写入完成后再降配，可提升3-5倍写入速度。
• 写入前禁用目标表的索引和触发器：插入数据时维护索引和触发器的开销占比可超过50%，写入前禁用，写入完成后再重建，可大幅降低耗时。
• 确保Azure Databricks和Azure SQL在同一区域：跨区域传输会带来额外的网络延迟，同一区域内的网络延迟可降低到毫秒级。

四、集群配置的影响 #

你当前的单节点4核14G配置不是核心瓶颈，300万行数据的计算和写入对资源的要求很低，调整完上述参数后，即使是当前配置也能把写入耗时降到1分钟以内。

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