Azure Data Factory无最后修改日期及主键的增量加载方案咨询

以下是几种可行的增量加载方案，适配不同业务场景：

方案一：基于数据哈希值的全量对比增量加载 #

通过计算每行数据的哈希值，对比源端与目标端的哈希差异识别增量数据，无需修改源表结构：

• 操作步骤：
  1. 在ADF中全量读取源表数据，使用派生列活动计算每行哈希值（例如执行SHA2(CONCAT(col1, col2, col3, ...))，将所有字段拼接后生成唯一哈希）；
  2. 读取目标存储中已同步的数据及对应的哈希字段（需提前在目标表中预留哈希存储位）；
  3. 通过合并或查找活动，筛选出源端哈希未在目标端出现、或哈希值不一致的行；
  4. 将筛选出的行插入或更新到目标表。
• 适用场景：数据量较小的表，源表存在更新/删除操作；
• 缺点：全量读取源表会占用较多带宽与计算资源，数据量大时性能衰减明显。

方案二：利用数据库变更日志捕获增量 #

如果源数据库支持变更数据捕获（CDC），可直接读取数据库变更日志获取增量，无需依赖源表的水印或主键：

• 操作步骤：
  1. 确认源数据库是否支持CDC（如SQL Server、Azure SQL DB、PostgreSQL等均支持），并申请权限开启CDC（若权限允许）；
  2. 在ADF中使用对应数据库的CDC源连接器，直接读取捕获到的新增、更新、删除数据；
  3. 将变更数据同步到目标表，保障数据一致性。
• 适用场景：源数据库支持CDC且能获取开启权限，需要精准捕获增量的场景；
• 优点：性能优异，仅同步变更数据，无需全量读取；
• 缺点：依赖数据库CDC功能，部分数据库需额外配置或更高权限。

方案三：基于内部行标识符的伪增量（仅适用于仅插入场景） #

若源表只有插入操作、无更新/删除，且数据库提供内部行标识符（如SQL Server的%%physloc%%、MySQL的_rowid），可利用这些标识符实现伪增量：

• 操作步骤：
  1. 首次同步时全量读取源表，记录同步到的最大内部行标识符；
  2. 后续同步时，读取源表中内部行标识符大于上次记录值的行；
  3. 更新记录的最大行标识符，完成增量同步。
• 适用场景：仅插入数据的表，无更新/删除操作；
• 缺点：内部行标识符由数据库内部维护，可能随存储结构调整失效，存在数据丢失风险，不适合有更新的场景。

方案四：分批全量同步+差异对比 #

针对中等体量的表，可选择一个有区分度的非主键列（如地区、业务类型、日期范围）作为分批依据，分批次对比源端与目标端的数据差异：

• 操作步骤：
  1. 选择源表中分布均匀的列作为分批键（例如region、create_date）；
  2. 每次同步一个批次，全量读取该批次的源表数据与目标表对应批次的数据；
  3. 对比两个数据集的差异（可通过哈希值或逐列对比），同步新增、更新的行；
  4. 循环处理所有批次，完成增量同步。
• 适用场景：数据量中等，存在更新/删除操作，且有合适的分批列；
• 优点：比全量对比性能更优，降低单次同步的数据量；
• 缺点：依赖合适的分批列，若分批列分布不均，部分批次仍会有较大数据量。

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