Azure Data Factory：Exists转换对比两数据表未达预期问题排查

问题1：Exists转换返回大量行的原因分析 #

• 哈希计算逻辑问题：SHA2(256, columns())依赖列的元数据顺序，即便两张表数据库结构一致，若ADF数据集里的列顺序不同，生成的哈希值会完全不同；另外columns()可能包含ADF自动添加的隐藏系统列，也会导致哈希差异。
• 空值与数据类型差异：SQL中的NULL在ADF数据流中的处理逻辑可能和数据库端不一致，比如部分列的NULL值会被当作不同输入计算哈希；同时数据类型的隐式转换（如decimal精度、字符串编码差异）也会让相同内容生成不同哈希。
• Exists转换配置错误：确认Exists的匹配规则是否设置为「不存在于右侧流」，若误设为「存在」会直接返回全量行；同时检查匹配条件是否仅绑定哈希列，有没有多余的匹配规则干扰结果。
• 广播设置不是核心原因：自动/固定广播仅影响性能，不会改变匹配结果，可排除该因素。

问题2：ADF中更高效的两表增量对比方案 #

• 启用数据库CDC（变更数据捕获）：如果源数据库（如Azure SQL DB、SQL Server）支持CDC，开启后ADF数据流可直接读取CDC日志，仅同步新增/变更行，避免全表扫描和哈希计算，效率最高。
• 使用增量标识列：若表中有自增ID、更新时间戳这类字段，直接基于该字段过滤出上次同步后的新数据，再结合哈希或唯一键做变更比对，大幅减少处理的数据量。
• 使用SCD（缓慢变化维度）转换：ADF数据流内置的SCD转换专门处理增量和变更场景，只需配置唯一键、SCD类型（如SCD2跟踪历史），无需手动编写哈希和Exists逻辑，配置简单可靠。
• 优化哈希对比逻辑：若必须用哈希，先对两张表按唯一键分区，再计算哈希并对比，减少全表哈希计算的开销。

问题3：确保准确识别新增/变更行的措施 #

• 修正哈希计算方式：
  • 不要依赖columns()，手动指定所有业务列，比如：SHA2(256, concat(coalesce(col1, ''), coalesce(col2, ''), ...))，用coalesce统一处理空值，避免NULL导致的哈希差异。
  • 对日期、数值类型统一格式化，比如将日期转成固定字符串格式toString(create_time, 'yyyy-MM-dd HH:mm:ss')，将decimal转成固定精度的字符串，消除类型转换带来的差异。
• 抽样验证哈希值：从两张表中抽取已知相同的行，对比它们的哈希值，找出导致差异的具体列，针对性修正处理逻辑。
• 组合唯一键与哈希：先通过唯一键匹配两张表的行，再对比哈希值——唯一键匹配失败的是新增行，匹配成功但哈希不同的是变更行，既避免哈希冲突，又能准确区分新增/变更。
• 小数据集测试验证：先创建包含10-100行的测试表，验证Exists转换和哈希计算的逻辑正确性，确认结果符合预期后，再推广到全量数据。

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