使用Databricks将Delta表写入Azure SQL的性能与连接问题排查

一、解决连接关闭异常 #

1. 修正错误参数配置 #

你的代码中isolationLevel参数设置有误，该参数需传入SQL事务隔离级别字符串（如READ_COMMITTED、REPEATABLE_READ），而非布尔值"True"。错误参数会导致连接器无法正确初始化数据库连接，进而触发连接关闭异常。

修正后的参数示例：

.option("isolationLevel", "READ_COMMITTED")

同时，tableLock参数建议使用小写布尔值"true"（部分版本连接器对大小写敏感）：

.option("tableLock", "true")

2. 匹配连接器与Spark版本兼容性 #

当前使用的spark-mssql-connector_2.12:1.2.0与Databricks Runtime 9.1 LTS（Spark 3.1.2）存在潜在兼容性问题。建议升级到适配Spark 3.1.x的版本，例如com.microsoft.azure:spark-mssql-connector_2.12:1.3.0。

3. 添加连接超时配置 #

Azure SQL可能因长时间无交互自动关闭连接，添加超时参数延长连接存活时间：

.option("connectTimeout", "300000")  # 5分钟，单位毫秒
.option("socketTimeout", "300000")

4. 调整批量大小 #

过大的batchsize（100000）可能导致单批次数据传输时间过长，触发连接超时。建议适当调小至50000左右，平衡传输效率与连接稳定性：

.option("batchsize", "50000")

二、Spark写入Azure SQL的性能优化方法 #

1. 优化数据分区 #

确保DataFrame分区数合理，建议设置为集群总核心数的2-3倍（你的集群共32核，建议分区数64-96）。通过repartition调整：

df = df.repartition(80)  # 根据实际数据量灵活调整

2. 启用批量复制模式 #

微软连接器支持Bulk Insert批量复制，比普通JDBC批量写入效率更高，添加以下参数：

.option("bulkCopyBatchSize", "100000")
.option("bulkCopyTableLock", "true")
.option("bulkCopyTimeout", "300000")

注意：启用该模式后，原batchsize参数会被忽略，需使用bulkCopyBatchSize替代。

3. 调整Azure SQL数据库配置 #

• 临时升级服务层级：将Basic/Standard tier临时升级到Premium tier，利用更高的IOPS和计算资源加速写入，完成后再降级。
• 禁用索引与约束：写入前临时禁用目标表的非聚集索引、外键约束，写入完成后重新启用，减少写入时的索引维护开销。
• 调整并行度：在Azure SQL中设置MAXDOP参数，匹配Spark集群的并行写入能力（需根据数据库资源合理调整）。

4. 优化Spark集群配置 #

• 调整Executor资源：将每个Executor内存设为12GB（预留2GB给系统），核心数设为4，与节点配置匹配，避免资源浪费。
• 启用动态分区调整：在集群配置中开启spark.sql.adaptive.enabled=true，让Spark自动调整分区数，优化资源利用。

5. 原生JDBC写入优化 #

若使用原生JDBC，可添加以下参数提升性能：

df.write \
  .format("jdbc") \
  .mode("overwrite") \
  .option("url", url) \
  .option("dbtable", Tablenamewithschema) \
  .option("user", user) \
  .option("password", password) \
  .option("batchsize", "50000") \
  .option("numPartitions", "80") \
  .option("truncate", "true") \
  .option("rewriteBatchedStatements", "true")  # 开启批量语句重写，提升JDBC性能
  .save()

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