使用Azure Data Factory Upsert复制活动时源与接收器库行数不匹配的常见修复

• 先确认键列的有效性
  即使你认为键列准确，也得落地验证：

  • 在源数据库执行查询，检查键列是否存在重复值：SELECT [键列名], COUNT(*) FROM [源表名] GROUP BY [键列名] HAVING COUNT(*) > 1，重复键会导致Upsert时匹配逻辑混乱，比如同一键值的多行可能只更新/插入一行，或者重复插入。
  • 检查键列的Null值：Upsert对Null的匹配逻辑是严格的（Null不等于任何值，包括其他Null），如果源表键列存在Null行，这些行每次都会被当作新行插入，导致目标行数持续增加。

• 验证Copy Activity的配置细节

  • 核对字段映射：确保源和目标的键列数据类型完全匹配（比如字符串类型的长度、编码要一致），避免因隐式转换导致匹配失败。
  • 检查Upsert的冲突策略：确认设置的是“插入新行并更新匹配行”，有没有误设成“仅插入新行”或其他规则？另外，部分场景下如果源和目标的非键字段完全一致，ADF可能会跳过更新，但这不会影响行数，除非有其他逻辑。

• 扒管道运行日志找线索

  • 查看Copy Activity的运行详情，重点看读取行数、写入行数、跳过行数、失败行数这几个指标：
    • 如果读取行数≠写入行数，说明有数据在传输中被过滤或失败；
    • 如果有跳过行数，查看跳过原因（比如数据不符合约束、类型转换错误）；
    • 失败行数对应的错误信息会直接指向问题点。
  • 确认Lookup活动的输出：导出Lookup的结果，检查是否所有目标表都被正确枚举，每个表的键列配置是否和预期一致（有没有把非键列当成键列的情况）。

• 排除源数据的实时变动干扰
  如果管道运行期间源数据库有数据写入、更新或删除，你事后统计的源行数和管道读取时的行数必然不一致。可以：

  • 在管道启动时，先对源表做快照（比如SQL Server的SELECT * INTO 快照表 FROM 源表），然后用快照表作为源进行Upsert；
  • 严格在同一时间点统计源和目标的行数（比如管道运行结束后立刻两边统计）。

• 检查目标数据库的额外变动

  • 确认目标表是否有其他写入渠道：比如ETL脚本、应用程序直接写入，导致目标行数额外增加；
  • 查看目标表的触发器、约束：比如是否有触发器在插入/更新时自动删除某些行，或者自增列、默认值导致的隐性行变化。

• 抽样对比源与目标的键列数据
  随机选几个行数差异的表，抽样对比源和目标的键列值，看是否存在因编码、特殊字符、大小写导致的不匹配（比如源是"abc "带空格，目标是"abc"，Upsert时会当成不同键值插入新行）。

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