Azure Databricks工作流失败任务重启：重复插入规避方案咨询

关于MERGE方案的有效性 #

完全可以解决重复插入问题。MERGE INTO是典型的幂等操作——基于主键（或唯一键）匹配目标表与源数据，存在匹配记录时执行更新，不存在时执行插入。不管你的Notebook因为失败重启多少次，只要源数据的主键逻辑不变，最终目标表不会出现重复数据，结果始终一致。

举个Spark SQL的实际示例：

MERGE INTO sales_target t
USING sales_source s
ON t.transaction_id = s.transaction_id  -- 主键匹配
WHEN MATCHED THEN
  UPDATE SET t.amount = s.amount, t.updated_at = current_timestamp()
WHEN NOT MATCHED THEN
  INSERT (transaction_id, product_id, amount, created_at)
  VALUES (s.transaction_id, s.product_id, s.amount, current_timestamp())

哪怕这个语句重复执行N次，只要sales_source里的交易ID不变，目标表sales_target不会出现重复的交易记录，只会更新已有记录或插入新记录。

其他可行的解决方案 #

除了MERGE，还有几种思路可以避免修复重跑时的重复DML：

• 拆分任务+状态校验：把Notebook拆成多个独立的子任务（比如数据抽取、清洗、加载），在Databricks工作流中设置任务依赖。同时维护一张元数据表，记录每个子任务的执行状态（比如task_name、batch_id、status）。每个子任务执行前先查询元数据，若标记为已完成则直接跳过，只执行未完成的部分。

• 使用Delta Lake的ACID事务：如果你的表是Delta Lake格式，本身支持原子性事务。失败时整个DML操作会自动回滚，不会留下部分执行的数据。配合MERGE INTO使用，既能保证事务安全，又能实现幂等性。

• 前置校验的DML：对于简单的插入场景，也可以用INSERT INTO ... WHERE NOT EXISTS实现幂等：

INSERT INTO target_table (id, col1)
SELECT id, col1 FROM source_table
WHERE NOT EXISTS (SELECT 1 FROM target_table t WHERE t.id = source_table.id)

这种方式适合不需要更新、只需要避免重复插入的场景，但灵活性不如MERGE。

• 批次标识控制：给每个运行批次添加唯一标识（比如batch_id），写入目标表时带上这个标识。修复重跑时，先根据batch_id删除之前失败批次的部分数据，再重新执行DML。这种方式需要额外管理批次标识，但适合复杂的多步骤流程。

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