源系统和数据平台不一致时，从哪里开始排查

⚠️ 本文最后更新于2024年12月14日，已经过了618天没有更新，若内容或图片失效，请留言反馈

源系统里能查到的数据，到了数据平台却数量不同、字段为空或状态不一致，这类问题很难只靠一条 SQL 判断原因。

最近参与某教育数据项目时，我接触到上报系统升级、标准表调整、数据采集和治理准确性核对等工作。截至 11 月底，项目记录仍有一类数据尚未提供，画像和整体工作也处于继续推进状态。这让我更明确地意识到：平台数据出现差异，不一定都是同步程序错误，也可能是源数据、统计范围、字段映射或任务时间窗口不同。

先确认比较的是不是同一批数据

开始排查前，最重要的是把比较范围写清楚：

如果一边统计当天新增，另一边统计全部有效数据，数量不同是必然的。先统一口径，才能讨论差异是否异常。

业务口径
    -> 时间范围
    -> 状态范围
    -> 组织与权限范围
    -> 源端数量
    -> 平台数量

这是一套通用核对顺序，不对应某个内部数据源或真实表结构。

截至 11 月 29 日的阶段记录里，仍有一类上报数据尚未提供。这种情况下，平台没有对应数据，并不能直接认定同步任务漏数。

可以先确认：

只有源端数据已经存在并符合采集条件，后续同步链路的排查才有明确起点。

公开文章不写真实学校、具体表号、数据源名称和字段内容，只保留“源数据尚未提供会影响平台结果”的阶段事实。

源端确认无误后，可以检查任务的抽取范围和执行状态：

任务是否触发
    -> 是否成功连接源端
    -> 抽取条件是否命中
    -> 读取记录数量
    -> 转换成功与失败数量
    -> 目标端写入数量

日志中如果只记录“任务成功”，仍然不够。任务可能成功执行，但抽取条件没有命中任何记录；也可能读取到了数据，却在转换或写入阶段跳过了一部分。

我会尽量分别记录读取、转换和写入数量，而不是只保留一个最终状态。

增量同步通常依赖更新时间、主键或状态字段。时间边界处理不一致时，容易出现遗漏或重复。

下面是通用核查 SQL，不来自真实项目：

SELECT COUNT(*)
FROM source_record
WHERE updated_at > :start_time
  AND updated_at <= :end_time;

需要继续确认：

数量差异如果集中在边界时间附近，就值得优先检查这些条件。

记录已经进入平台，不代表数据质量一定正确。类型转换、编码映射、空值处理和默认值都可能改变结果。

源字段值
    -> 清洗与转换
    -> 标准值映射
    -> 目标字段值
    -> 质量规则校验

例如，源系统使用文本状态，平台使用数字编码；源端空字符串和 NULL 含义不同，平台却统一处理；日期格式转换失败后，记录可能被跳过或写入空值。

这类问题需要选择少量脱敏样本做字段级对照，不能只比较总数量。

平台写入前后可能执行去重、合并、状态过滤或质量校验。如果同一业务对象存在多条记录，平台可能只保留一条；如果关键字段不满足规则，记录也可能进入异常清单而不是正式表。

因此还要确认：

这些规则必须从实际配置、代码和数据标准中确认，不能根据常见架构自行假设。

总数只能告诉我存在差异，无法直接说明原因。更有效的方法是比较业务主键或脱敏后的唯一标识，把记录分成三组：

源端有、平台无
平台有、源端无
两边都有、字段不同

三类差异通常对应不同方向：第一类优先查采集和过滤，第二类检查历史数据、删除和口径，第三类检查转换和标准映射。

排查时可以先选少量记录验证链路，确认原因后再扩大范围。公开记录中只保留脱敏标识和统计结果，不保存真实个人或业务数据。

一次数据差异排查至少应该保留：比较口径、查询时间、任务批次、源端结果、平台结果、差异样本和确认原因。

AI 可以帮助整理 SQL、列出可能原因或设计核对步骤，但最终结论仍然依赖真实数据和任务日志。不能因为某种解释符合常见模式，就把它写成当前项目已经发生的事实。

源系统和数据平台不一致时，我会先确认比较口径和源数据是否存在，再沿抽取、转换、写入和目标端规则逐层检查。先把差异缩小到具体记录，才能从“数量不一致”走到可以验证的问题原因。

现在已有 8 次阅读，0 条评论，0 人点赞