实时管道的表配置数据检测任务说明

实时管道任务运行后，用户希望检查来源表和目标表的一致性。

数据检测任务 提供两种规则检测两表的一致性：

本文为您讲解如何根据实际情况配置检测规则。

2.1 面对海量表，如何制定检测策略

面对 3000+ 张表的同步任务，如果试图对每张表都配置高频的一致性检测，不仅配置工作量巨大，更会导致源端数据库 IO 耗尽，甚至影响核心业务的稳定性。

高效的检测策略应该是「分级治理」与「哨兵监控」。

2.1.1 分级治理

请将您的 3000 张表按照业务重要性放入下面的金字塔中，不同层级采用不同的策略：

2.1.2 哨兵模式

为什么不需要测所有表呢？

FDL 的管道同步机制是标准化的。通常情况下，如果同一个管道任务中的几张“最难同步的表”（写入最频繁、结构最复杂）的数据是一致的，那么同一个管道里其他几百张静止的、简单的表几乎不可能出问题。

我们推荐的“哨兵”策略：

• 从您的 3000 张表中，找出 写入量最大、变动最频繁 的 10-20 张表（通常是核心业务表）。

• 给这 20 张表配置高频的【明细值比对】。

• 结论：只要这 20 个“哨兵”没有报警，整个 FDL 管道链路就是健康的，其余 2980 张表也就是安全的。

2.2 规则选择说明

关卡	判断标准	说明
第一关	源端数据库现在是否处于高负载或业务高峰	是  -->  停止配置，或仅配置为“夜间 02:00 执行” 否  -->  进入下一关
第二关	表是否有主键或唯一索引	无  -->   建议先去给逻辑主键配置唯一索引, 否则【统计值比对】会触发全表扫描 有  -->  进入下一关
	表是否有修改时间戳	无  -->  锁定方案为 【统计值比对】（无法做增量明细）------非最终方案，还需进一步判断 有  -->  进入下一关
第三关	这是核心交易/结算表，且存在 Update 修改吗	是  -->  初选方案 【明细值比对】，进入下一关继续判断 否（日志表/非核心表/纯Insert表）  -->  锁定方案： 【统计值比对】 ，进入下一关继续判断
第四关	数据量是否巨大（>亿级）或带宽紧张	是  -->  降级：即便上一关选了明细，这里也建议改回统计值；或在明细比对中增加 Exclude 排除大字段 否 -->  进入下一个问题
	写入是否非常高频（7*24h）	1）是  -->【明细值比对】  加窗口：配置 Where update_time < 30分钟前，避开误报 若业务有明确停止窗口（如夜间），建议将检测任务调度在停止写入的时间段（如凌晨 2 点）运行，此时结果最准确 2）否：【明细值比对】 若出现差异，建议复测一次以排除瞬间延迟

• 如果实时管道任务开启了逻辑删除的话，需要在检测对象上配置过滤条件 _fdl_marked_deleted = 'false'

• 如果实时管道任务开启了分组表同步, 需要在检测对象上配置过滤条件过滤 _fdl_src_schema_table = 'schema.table_name'

3.1 发现来源表和目标表数据不一致如何处理

3.1.1 步骤一：查看实时管道日志

首先确认差异是由“管道堵了（延迟）”引起的，还是真正的“数据错了”。

• 看待同步数：如果数值很高，说明数据还在排队。这是延迟，不是不一致。请耐心等待同步完成。

• 看读写时间：如果最新写入时间显著落后于最新读取时间，也是延迟。

• 看脏数据：如果有脏数据记录，说明数据写入报错被丢弃了。这是明确的数据不一致。

3.1.2 步骤二：再运行一次数据检测任务

或者根据前几次的运行结果来辅助判断是否误报。

如果排除了明显的延迟积压，建议手动重新触发一次检测任务。

• 原因：在检测执行期间，源端发生的实时高频变更可能导致瞬时差异。

• 判断：

• 差异消失，忽略（属于动态比对的正常误差）。

• 差异依然存在且稳定，进入第三步。

3.1.3 根因排查

请对照下表逐一检查：