Azure Databricks导入10M行数据至Azure SQL遇瓶颈，CPU满负载求助

针对你遇到的Azure SQL数据库CPU拉满导致Spark写入失败的问题，结合eDTU50规格的限制，给出以下针对性优化方案：

一、调整JDBC写入参数 #

• 降低批量写入大小：当前batchsize=100000远超eDTU50的处理能力，建议将值调整为1000-5000。小批量写入能分散数据库的单次处理压力，避免CPU瞬间冲高到100%。
• 关闭全表锁：tableLock=true会锁定整个目标表，加剧锁竞争并消耗额外CPU，改为tableLock=false，利用行级锁降低负载。
• 控制并行写入分区数：新增numPartitions参数，设置为4-8（eDTU50的建议并发数），比如option("numPartitions", "6")。同时在Databricks端对DataFrame做预分区（df.repartition(6)），确保每个分区数据量均匀，让数据库负载更均衡。
• 保留可靠性级别：如果数据一致性要求允许，BEST_EFFORT可以保留；若需严格避免重复，可改为NO_DUPLICATES，但要配合较小的批量大小。

二、Azure SQL数据库端优化 #

• 临时升级eDTU规格：导入期间临时将数据库升级到eDTU 200或更高层级，完成后再降级。弹性层的快速调整能直接提升写入吞吐量，绕过CPU瓶颈。
• 禁用索引与约束：导入前删除目标表的非聚集索引、外键约束、触发器，导入完成后再重建。索引维护在批量写入时会占用大量CPU，禁用后能大幅降低负载。
• 优化事务与隔离级别：开启数据库的ALLOW_SNAPSHOT_ISOLATION，减少锁竞争；或者在写入时使用TABLOCK提示（需与JDBC的tableLock参数协调）。
• 监控日志写入速率：eDTU50的日志写入上限为1MB/s，若批量写入超过此值会导致日志等待，进而拉高CPU。可通过Azure门户查看此指标，调整批量大小和并行数适配。

三、Databricks端补充调整 #

• 替换overwrite模式：overwrite会先删除全表，增加数据库锁压力。改为先执行TRUNCATE TABLE（通过Spark的spark.sql调用），再用append模式写入，减少锁竞争。
• 压缩数据分区：若数据存在倾斜，使用df.coalesce(numPartitions)合并分区，确保每个分区数据量均匀，避免单个分区写入过大拖垮数据库。

调整后的示例代码 #

try:
    # 先清空目标表
    spark.sql(f"TRUNCATE TABLE {target_table}")
    
    df.repartition(6) \
    .write \
    .format("com.microsoft.sqlserver.jdbc.spark") \
    .mode("append") \
    .option("url", sql_db_url) \
    .option("dbtable", target_table) \
    .option("user", username) \
    .option("password", password) \
    .option("batchsize", "3000") \
    .option("tableLock", "false") \
    .option("schemaCheckEnabled", "false") \
    .option("reliabilityLevel", "BEST_EFFORT") \
    .option("numPartitions", "6") \
    .save()

    print("Successfully write data into target SQL database")
except Exception as error:
    print("An exception occurred:", error)

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