Azure Data Factory中sha2(256,columns())是否安全？哈希冲突解决最佳实践

你观察的完全正确——Azure Data Factory的sha2函数在传入多参数时，确实会直接把所有参数拼接成一个字符串后再计算哈希，这就导致你遇到的问题：sha2(256, "ABC", "DEF")和sha2(256, "AB", "CDEF")生成的哈希完全一致，因为两者拼接后的字符串都是ABCDEF。

针对这类数据哈希冲突的问题，以下是几种可靠的解决方法，尤其适用于动态列列表的场景：

• 添加唯一分隔符拼接列值
  给每个列值之间加入一个不会出现在业务数据中的分隔符（比如|、#或者特殊控制字符\u0000），先把所有列值用分隔符拼接成一个无歧义的字符串，再传入哈希函数。
  静态参数示例：

  sha2(256, stringJoin(["ABC", "DEF"], "|"))
  

  动态列列表示例：

  sha2(256, stringJoin(columns(), "|"))
  

  这样"ABC"+"DEF"会变成ABC|DEF，"AB"+"CDEF"会变成AB|CDEF，两者拼接结果不同，哈希自然也不会重复。

• 绑定列名与列值后哈希
  如果担心分隔符仍有冲突（比如数据里恰好包含了你选的分隔符），可以把列名和对应的值绑定成列名=列值的格式，再拼接哈希。这种方式能从根源上避免值拼接的歧义，因为即使两个不同列的值拼接后相同，加上列名也能区分开。
  动态列列表示例：

  sha2(256, stringJoin(map(columns(), concat(item().name, "=", item().value)), "|"))
  

• 采用哈希链计算方式
  不一次性拼接所有列值，而是逐个计算哈希：用第一个列值生成初始哈希，再把这个哈希结果和第二个列值一起作为参数计算新的哈希，以此类推。这种方式不需要考虑分隔符的问题，只要列值或顺序有变化，最终哈希就会不同。
  静态参数示例：

  sha2(256, sha2(256, "ABC"), "DEF")
  

  动态列列表可以用reduce函数实现：

  reduce(columns(), "", (prev, curr) => sha2(256, prev, curr.value))
  

你并没有遗漏关键要点，ADF的sha2多参数行为属于官方文档未明确强调的细节，通过上述方法就能有效规避哈希碰撞的问题。

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