Delta Lake非流式合并幂等写入：崩溃重跑是否产生重复数据？

一、Merge操作崩溃后的处理逻辑 #

Delta Lake的ACID事务特性决定了Merge操作是原子执行的：如果执行过程中因任何原因崩溃（节点故障、作业中断等），整个事务会自动回滚，目标表会恢复到Merge启动前的状态——不会出现“部分记录写入成功”的中间状态。

如果实际场景中发现目标表存在异常状态（比如误判为部分写入），可以按以下步骤处理：

• 执行DESCRIBE HISTORY <target-table>查看事务日志，定位失败的Merge事务版本，确认事务的最终状态。
• 若事务标记为失败，直接重跑Merge即可，因为目标表并未被修改；若存在异常中间态，执行RESTORE TABLE <target-table> TO VERSION AS OF <pre-crash-version>回滚到崩溃前的版本，再重新执行Merge。

二、重跑时源表更新是否会产生重复记录 #

结合你给出的场景，不会产生重复记录，核心原因在于Merge的主键匹配逻辑：

1. 对于运行2中假设已成功插入的2条记录：重跑时源表中的这些记录主键会与目标表中的现有主键匹配，触发WHEN MATCHED分支（通常是更新操作），不会再次执行插入。
2. 对于运行2中已更新的1条记录：重跑时源表对应的主键记录会再次匹配，执行更新（如果源表中该记录有新变更则更新，无变更则不会影响现有数据）。
3. 源表新增的2条唯一主键记录：因为目标表中无匹配项，会触发WHEN NOT MATCHED分支执行插入，不会与现有记录冲突。

需要注意：

• 必须确保Merge语句逻辑正确，明确包含WHEN MATCHED THEN UPDATE和WHEN NOT MATCHED THEN INSERT的分支定义，避免因逻辑缺失导致异常。
• 你提到的txnVersion & txnAppId特性确实不支持批处理Merge的幂等控制，但Merge本身基于主键的匹配逻辑已经足够避免重复记录。

针对你的场景的具体结果 #

• 若Delta事务正常回滚（目标表回到105条）：重跑Merge后，目标表最终为105 + 3（原插入） +1（新增插入）=109条记录（2条原更新、1条新增更新都是修改已有记录，不增加总数）。
• 若存在极端的部分写入场景（目标表为108条）：重跑后，原已插入的2条记录会被更新，新增的2条记录插入，最终目标表为108 +2=110条记录，且无重复主键的记录。

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