宁语之溪 - 数据上报
type: channel
link: https://nyzx.de/tag/data-reporting/
items: 数百万级数据上报项目中的进度和质量问题

数百万级数据上报项目中的进度和质量问题
type: item
date: 2024-11-30T16:31:00+08:00
description: 教育数据项目的进度，往往同时受到数据量、标准变化、数据质量和数据源准备情况的影响。数字会不断变化，但数字本身并不能说明项目是否真正接近完成。从 2024 年 9 月到 11 月，项目周报里可以看到几条并行推进的线：上报系统持续运行，标准表数量不断增加，画像开发逐步展开，同时仍然有数据缺失和数据源提供较慢的问题需要处理。数据量增长不等于链路完成9 月的周报记录，上报系统按照要求维护并上报多张标准表数据，上报数据已经达到数百万条量级。到 11 月初，标准表完成数量继续增加，上报系统中的标准表也已经完成大部分。这些数字能够说明工作量和阶段进度，但不能直接等同于项目整体完成。数据上报至少包含多个环节：来源数据准备、字段映射、质量处理、标准表转换、提交上报和结果核对。数据来源 -> 汇聚与映射 -> 质量检查 -> 标准表整理 -> 上报提交 -> 结果核对其中任何一个环节没有准备好，都可能影响最终结果。数据量变大，只说明系统处理了更多数据，不代表所有数据都已经满足上报和分析要求。标准表会持续变化9 月开始整理新版标准表和导入模板，10 月又按照不同版本继续升级上报系统。标准表数量从早期的阶段性完成，逐步推进到 11 月初的大部分完成。这类工作有一个特点：系统升级并不是一次性的。标准版本变化后，需要同步调整数据结构、导入模板、校验规则和已有数据处理方式。公开资料中常见的做法，是把标准版本作为数据处理链路的一部分记录下来：标准版本 -> 字段与枚举变化 -> 导入模板调整 -> 校验规则更新 -> 历史数据复核项目内部的版本映射、表号和字段值不公开，但版本变化会影响数据上报的判断，这一点需要在进度记录中单独保留。数据质量问题会拖慢进度周报中多次出现数据质量处理和数据源提供较慢的问题。数据源提供不及时，会使后续开发和治理缺少输入；数据质量不符合要求，则可能需要重新整理、修正和再次上报。对于数据质量问题，不能只记录“已处理”三个字。至少需要区分：问题发生在数据来源、转换还是上报环节；是缺失、格式错误、关联错误还是口径不一致；修正是否会影响已经完成的数据；修正后是否需要重新执行上报或统计。这些是通用的数据质量记录方法，不对应项目内部的问题编号和业务数据。实际项目中仍然要以具体标准和确认结果为准。画像进度依赖数据准备除上报系统外，项目还在推进学生画像、教师画像、学校画像、专业画像和课程画像等方向。11 月初的周报已经记录了画像整体进度，同时也能看到不同画像方向的完成程度并不相同。画像开发不能只按照页面数量计算。指标定义、数据来源和数据治理情况都会影响开发进度。如果所需数据还没有提供，或者字段口径还没有确认，页面开发即使完成，也可能无法得到可靠结果。指标定义 -> 数据需求 -> 数据来源确认 -> 数据治理 -> 指标开发 -> 结果核对这个流程是公开数据项目中的通用示例。文章不公开具体画像指标、学校名称、数据源和业务内容。项目进度需要保留边界11 月 8 日的周报记录，项目整体完成进度约为 70%，预计 11 月 29 日完成；同时仍有部分标准表缺少数据，画像开发也处于分项推进状态。由于 11 月 25-29 日的后续周报文件当前无法读取，我不能把预计完成日期写成实际完成事实，也不能补写项目最终交付结果。能够确认的只是：截至 11 月 8 日，项目已经进入持续推进阶段，标准表、上报、画像和数据治理仍然并行进行。这也是项目记录中需要特别注意的地方：预计、计划和实际结果必须分开。计划完成日期可以写，实际完成情况需要有后续证据支持。数字背后的工作链路从 9 月的数百万条上报数据，到 10 月标准表和画像开发的阶段推进，再到 11 月初的整体进度记录，数字背后对应的是一条持续变化的数据链路。我现在更关注的不是把所有数字压缩成一个完成率，而是确认每个数字对应什么对象、哪个时间点和哪种状态。上报量、标准表完成数、画像进度、缺失数据和项目整体进度，应该分别记录，不能相互替代。对于数据上报项目来说，进度管理和数据质量管理并不是两件完全分开的事。数据质量影响上报进度，上报标准影响治理方式，而数据治理结果又会反过来影响画像和分析功能。