语之溪
从竞赛平台转到教育数据中台之后，我接触到的问题发生了变化。
以前更多是在接口、页面、比赛流程和任务状态之间排查问题；新的工作则更常围绕数据来源、标准表、上报系统和数据质量展开。功能仍然需要开发和维护，但判断一项工作是否完成，不能只看页面能不能打开，还要看数据是否能够按照要求进入系统，并且能够支撑后续使用。
先面对数据从哪里来
2024 年 9 月的一份项目周报中，工作重点包括维护上报系统、按照要求上报多张标准表数据，以及处理学校上报数据中的质量问题。周报记录的上报数据已经达到数百万条量级。
这里的关键并不是把数字写得越精确越好，而是要理解数据上报工作本身：数据需要从来源系统汇聚到上报系统，再按照标准和规则进行整理、校验和提交。
数据源提供速度会直接影响后续进度。周报中把数据源提供较慢列为风险，并计划由相关方按照约定字段提供数据。对于数据项目来说，开发人员能否继续推进，往往不只取决于代码是否完成，也取决于上游数据是否准备好、字段是否匹配、质量问题是否已经处理。
标准表不是简单的字段清单
同一阶段还在整理教育部门新版标准表和数据导入模板。标准变化后，系统需要跟着更新，数据导入模板也要同步调整。
从通用角度看，标准表至少会影响几个方面：
业务数据
-> 字段映射
-> 标准表结构
-> 校验与治理
-> 上报或分析使用如果只修改数据库字段，却没有同步处理导入模板、校验规则和历史数据，就可能出现系统能接收数据，但后续上报或分析无法正常使用的情况。
这也是我从项目工作中逐渐形成的认识：数据标准变化不是某一个页面的修改，而是会沿着数据链路影响多个环节。公开文章不展开内部表号、字段值和具体映射规则，但标准变更需要同步考虑这些环节。
数据质量会影响整个流程
数据质量问题通常不会只表现为一条错误提示。它可能表现为字段缺失、格式不符合要求、关联对象找不到，或者同一类数据在不同来源中含义不一致。
处理数据质量问题时，可以先把问题分成几类：
- 数据是否存在；
- 字段格式是否正确；
- 字段之间的关系是否成立；
- 数据是否符合标准表要求；
- 修正后是否需要重新上报或重新计算。
这些是通用的数据治理思路，不对应项目内部的具体规则。实际工作中仍然需要以项目标准、数据来源和业务要求为准。
画像开发依赖数据基础
周报中还提到学生画像指标和页面风格确认，需要校方按照已经确定的字段提供对应数据。后续周报又记录了学生画像、教师画像和其他画像方向的开发进度。
这让我看到，画像页面并不是先做一个展示页面，再想办法填充数据。画像指标能不能成立，取决于底层数据是否存在、数据质量是否满足要求，以及指标口径能不能被确认。
一个比较常见的处理顺序是：
确认指标定义
-> 确认所需字段
-> 检查数据来源
-> 完成数据治理
-> 开发指标和页面
-> 用真实数据验证结果这个流程是结合公开数据中台实践整理出的通用示例。文章不公开具体学校、画像指标、数据源名称和业务数据。
工作内容从接口扩展到数据链路
从竞赛业务转向教育数据中台后，我并没有离开开发工作，而是开始更多地关注接口背后的数据链路。系统要正常运行，需要维护上报功能，也需要处理数据质量、标准变化、导入模板和数据来源之间的关系。
这类项目的进度也不一定只用代码完成量衡量。数据源是否按时提供、标准是否发生变化、数据治理是否完成、上报结果是否符合要求，都会影响项目推进。
截至 2024 年 9 月 20 日，我能确认的工作主要是参与教育数据项目的数据上报系统维护、数据质量问题处理、标准表和导入模板整理，以及画像相关数据准备。具体学校、公司、数据源、表号和业务数据不在公开文章中展开。
对我来说，这次变化首先是工作对象的变化：从围绕比赛流程和接口状态排查问题，逐步转向理解数据从来源到上报、治理和分析使用之间是怎样连接起来的。
