源系统和数据平台不一致时，从哪里开始排查
源系统里能查到的数据，到了数据平台却数量不同、字段为空或状态不一致，这类问题很难只靠一条 SQL 判断原因。最近参与某教育数据项目时，我接触到上报系统升级、标准表调整、数据采集和治理准确性核对等工作。截至 11 月底，项目记录仍有一类数据尚未提供，画像和整体工作也处于继续推进状态。这让我更明确地意识到：平台数据出现差异，不一定都是同步程序错误，也可能是源数据、统计范围、字段映射或任务时间窗口不同。先确认比较的是不是同一批数据开始排查前，最重要的是把比较范围写清楚：比较的是哪个业务对象；源系统和平台分别使用什么筛选条件；时间范围是否一致；是否包含已删除、无效或历史数据；两边的组织、状态和权限范围是否相同；查询发生在什么时间。如果一边统计当天新增，另一边统计全部有效数据，数量不同是必然的。先统一口径，才能讨论差异是否异常。业务口径 -> 时间范围 -> 状态范围 -> 组织与权限范围 -> 源端数量 -> 平台数量这是一套通用核对顺序，不对应某个内部数据源或真实表结构。确认源数据是否已经具备截至 11 月 29 日的阶段记录里，仍有一类上报数据尚未提供。这种情况下，平台没有对应数据，并不能直接认定同步任务漏数。可以先确认：数据是否已经在源系统产生；当前账号是否有权限看到；数据是否满足采集条件；数据提供时间是否晚于任务执行时间；字段是否仍在等待业务口径确认。只有源端数据已经存在并符合采集条件，后续同步链路的排查才有明确起点。公开文章不写真实学校、具体表号、数据源名称和字段内容，只保留“源数据尚未提供会影响平台结果”的阶段事实。再看任务有没有读到数据源端确认无误后，可以检查任务的抽取范围和执行状态：任务是否触发 -> 是否成功连接源端 -> 抽取条件是否命中 -> 读取记录数量 -> 转换成功与失败数量 -> 目标端写入数量日志中如果只记录“任务成功”，仍然不够。任务可能成功执行，但抽取条件没有命中任何记录；也可能读取到了数据，却在转换或写入阶段跳过了一部分。我会尽量分别记录读取、转换和写入数量，而不是只保留一个最终状态。时间窗口是常见差异来源增量同步通常依赖更新时间、主键或状态字段。时间边界处理不一致时，容易出现遗漏或重复。下面是通用核查 SQL，不来自真实项目：SELECT COUNT(*) FROM source_record WHERE updated_at > :start_time AND updated_at <= :end_time;需要继续确认：上一次结束时间是否等于本次开始时间；边界使用 > 还是 >=；时间字段是否可能为空；源系统和任务服务器的时区是否一致；失败重跑时使用原窗口还是新窗口。数量差异如果集中在边界时间附近，就值得优先检查这些条件。字段映射会造成“有数据但不可用”记录已经进入平台，不代表数据质量一定正确。类型转换、编码映射、空值处理和默认值都可能改变结果。源字段值 -> 清洗与转换 -> 标准值映射 -> 目标字段值 -> 质量规则校验例如，源系统使用文本状态，平台使用数字编码；源端空字符串和 NULL 含义不同，平台却统一处理；日期格式转换失败后，记录可能被跳过或写入空值。这类问题需要选择少量脱敏样本做字段级对照，不能只比较总数量。目标端还可能有自己的处理规则平台写入前后可能执行去重、合并、状态过滤或质量校验。如果同一业务对象存在多条记录，平台可能只保留一条；如果关键字段不满足规则，记录也可能进入异常清单而不是正式表。因此还要确认：唯一键和去重规则是什么；更新已有记录还是新增记录；校验失败的数据去了哪里；是否存在暂存层和正式层；重跑任务会不会重复写入。这些规则必须从实际配置、代码和数据标准中确认，不能根据常见架构自行假设。把差异缩小到具体记录总数只能告诉我存在差异，无法直接说明原因。更有效的方法是比较业务主键或脱敏后的唯一标识，把记录分成三组：源端有、平台无 平台有、源端无 两边都有、字段不同三类差异通常对应不同方向：第一类优先查采集和过滤，第二类检查历史数据、删除和口径，第三类检查转换和标准映射。排查时可以先选少量记录验证链路，确认原因后再扩大范围。公开记录中只保留脱敏标识和统计结果，不保存真实个人或业务数据。结论要能回到证据一次数据差异排查至少应该保留：比较口径、查询时间、任务批次、源端结果、平台结果、差异样本和确认原因。AI 可以帮助整理 SQL、列出可能原因或设计核对步骤，但最终结论仍然依赖真实数据和任务日志。不能因为某种解释符合常见模式，就把它写成当前项目已经发生的事实。源系统和数据平台不一致时，我会先确认比较口径和源数据是否存在，再沿抽取、转换、写入和目标端规则逐层检查。先把差异缩小到具体记录，才能从“数量不一致”走到可以验证的问题原因。
数百万级数据上报项目中的进度和质量问题
教育数据项目的进度，往往同时受到数据量、标准变化、数据质量和数据源准备情况的影响。数字会不断变化，但数字本身并不能说明项目是否真正接近完成。从 2024 年 9 月到 11 月，项目周报里可以看到几条并行推进的线：上报系统持续运行，标准表数量不断增加，画像开发逐步展开，同时仍然有数据缺失和数据源提供较慢的问题需要处理。数据量增长不等于链路完成9 月的周报记录，上报系统按照要求维护并上报多张标准表数据，上报数据已经达到数百万条量级。到 11 月初，标准表完成数量继续增加，上报系统中的标准表也已经完成大部分。这些数字能够说明工作量和阶段进度，但不能直接等同于项目整体完成。数据上报至少包含多个环节：来源数据准备、字段映射、质量处理、标准表转换、提交上报和结果核对。数据来源 -> 汇聚与映射 -> 质量检查 -> 标准表整理 -> 上报提交 -> 结果核对其中任何一个环节没有准备好，都可能影响最终结果。数据量变大，只说明系统处理了更多数据，不代表所有数据都已经满足上报和分析要求。标准表会持续变化9 月开始整理新版标准表和导入模板，10 月又按照不同版本继续升级上报系统。标准表数量从早期的阶段性完成，逐步推进到 11 月初的大部分完成。这类工作有一个特点：系统升级并不是一次性的。标准版本变化后，需要同步调整数据结构、导入模板、校验规则和已有数据处理方式。公开资料中常见的做法，是把标准版本作为数据处理链路的一部分记录下来：标准版本 -> 字段与枚举变化 -> 导入模板调整 -> 校验规则更新 -> 历史数据复核项目内部的版本映射、表号和字段值不公开，但版本变化会影响数据上报的判断，这一点需要在进度记录中单独保留。数据质量问题会拖慢进度周报中多次出现数据质量处理和数据源提供较慢的问题。数据源提供不及时，会使后续开发和治理缺少输入；数据质量不符合要求，则可能需要重新整理、修正和再次上报。对于数据质量问题，不能只记录“已处理”三个字。至少需要区分：问题发生在数据来源、转换还是上报环节；是缺失、格式错误、关联错误还是口径不一致；修正是否会影响已经完成的数据；修正后是否需要重新执行上报或统计。这些是通用的数据质量记录方法，不对应项目内部的问题编号和业务数据。实际项目中仍然要以具体标准和确认结果为准。画像进度依赖数据准备除上报系统外，项目还在推进学生画像、教师画像、学校画像、专业画像和课程画像等方向。11 月初的周报已经记录了画像整体进度，同时也能看到不同画像方向的完成程度并不相同。画像开发不能只按照页面数量计算。指标定义、数据来源和数据治理情况都会影响开发进度。如果所需数据还没有提供，或者字段口径还没有确认，页面开发即使完成，也可能无法得到可靠结果。指标定义 -> 数据需求 -> 数据来源确认 -> 数据治理 -> 指标开发 -> 结果核对这个流程是公开数据项目中的通用示例。文章不公开具体画像指标、学校名称、数据源和业务内容。项目进度需要保留边界11 月 8 日的周报记录，项目整体完成进度约为 70%，预计 11 月 29 日完成；同时仍有部分标准表缺少数据，画像开发也处于分项推进状态。由于 11 月 25-29 日的后续周报文件当前无法读取，我不能把预计完成日期写成实际完成事实，也不能补写项目最终交付结果。能够确认的只是：截至 11 月 8 日，项目已经进入持续推进阶段，标准表、上报、画像和数据治理仍然并行进行。这也是项目记录中需要特别注意的地方：预计、计划和实际结果必须分开。计划完成日期可以写，实际完成情况需要有后续证据支持。数字背后的工作链路从 9 月的数百万条上报数据，到 10 月标准表和画像开发的阶段推进，再到 11 月初的整体进度记录，数字背后对应的是一条持续变化的数据链路。我现在更关注的不是把所有数字压缩成一个完成率，而是确认每个数字对应什么对象、哪个时间点和哪种状态。上报量、标准表完成数、画像进度、缺失数据和项目整体进度，应该分别记录，不能相互替代。对于数据上报项目来说，进度管理和数据质量管理并不是两件完全分开的事。数据质量影响上报进度，上报标准影响治理方式，而数据治理结果又会反过来影响画像和分析功能。