第七章　数据接入与源头治理

第五章把零容错划成了底线。底线要落成软件，得从数据进门的第一步开始。迎新的错九成发生在进门那一刻，所以进门这一关的强度，决定后面四年的干净程度。

7.1 十六个导入入口与进门校验

迎新期要进系统的数据，比一般业务系统多得多。新生基础信息、新生其他信息、成员、组织、宿舍、住房设施、缴费、选宿、志愿者、预约、物品、班主任、任务分组、学院绿色通道——目前一共 16 个导入入口，因为它们的表结构、口径、责任部门都不一样，强行合并成一张大表只会让每个部门都不肯用。

入口多不是问题，入口不一致才是问题。我们的处理有两条统一要求。

先校验，再落库。 宿舍与楼栋这类最容易出错的入口已经支持"只校验不写入"：上传一份表，系统先返回一份与真实导入完全一致的结果——哪些行会成功、哪些行会被拦下、拦下的原因是什么，确认无误再执行真正的导入。这样避免了"先导进去再说"造成的脏库，也避免了发现错了要整批回滚。这一模式目前只在这两个入口跑通，其余入口尚未覆盖，缺口在 7.7 里逐项列出。

错误行要说清是哪一行、为什么。 新生基础信息这一类主入口给的是行号加原因，而不是"格式错误，请检查"——前者管理员十分钟能改完，后者要来回问三轮，最后往往变成把数据删到能导入为止，那是拿数据质量换省事。其余入口的回执格式目前还不统一，这件事一并收进后面的统一映射批次。

模板也分三类：基础模板、按批次任务动态生成的信息模板、未报到名单模板。第二类是关键——要采集什么字段由学校自己配，配完模板自动生成，不会出现"系统里加了一个字段，导入模板还是半年前那份"。

7.2 字段映射与值映射：把"男／1／male"归成同一个值

上游数据永远长成它自己的样子。一所学校的学籍表写"性别"，另一所写"XBDM"，第三所给的是 1 和 0；民族一栏可能写全称，可能写代号，可能写"汉"。

系统里做了两层映射，且都已生产验证：

字段映射——目标字段对应源数据里的哪一列，可以配置；映射留空时按列名直通，所以一张规整的表可以直接导。

值映射——同一个业务值的不同写法归到一个标准值上。性别的"男"与"1"落成同一个枚举值，"女"与"0"落成另一个；民族的"汉"与"汉族"由归一工具统一。

但收敛到这里就停了：写成"male""M""男性"的值目前会被置空，而不是报错。空值不会分裂出第四个类别，它直接从所有分组里消失——统计看上去更干净，人却少了。把"认不出来的必须吱一声"补齐，是值域标准库随批次要解决的事。真正的收敛只有两种结果：要么每一种写法都归到同一个值，要么系统当场告诉你它不认识这一种写法。

这一层看着琐碎，实际决定后面所有统计能不能算。值域没收敛，"按性别分组"就会出来五个类别，其中四个是同一个意思；任何按字段做的分群、筛选、画像都会在这些脏值上分裂。指标字典（见第十四章）之所以能成立，前提是值域先收敛。

7.3 外部库同步与超时保护

导入是批量动作，很多学校需要的是持续同步：数据在教务系统里改了一个手机号，迎新系统不该等到下次导入才知道。

我们支持四种常见数据源（MySQL、PostgreSQL、SQL Server、Oracle），带 30 秒连接超时保护与语句校验。超时保护这件小事很要紧：对接外部库最怕对方库卡顿或网络不通，若没有超时，一个同步任务能把整条业务链拖死。

当前同步覆盖的范围是组织与成员两个域，其余业务域按批次扩展。这里要说得保守一点：外部库对接是每所学校都要真刀实枪验证的环节，说成"全面打通"会给学校埋一个上线前的坑。

7.4 组织类型推断路由

一所学校的组织架构，导出成表格后通常只是一堆列：学院名称、专业名称、班级名称。系统需要把它们变成有层级的组织树（五级组织、九种组织类型，见第八章）。

做法是"组织路由"可配置：告诉系统哪几列依次代表学院／专业／班级，导入时自动逐层建节点、自动归位。配一次，之后全校几千名学生不需要人工建树。

新学校上线时，这一项常常是第一天就能跑通全部数据的关键——组织架构建不起来，任务、权限、进度统计全都无从挂靠。

7.5 数据质量规则引擎

校验规则不该由厂商写死在系统里。每个学校的历史包袱不同：有的学校身份证号里有大量临时号，有的学校手机号是家长的且不允许改，有的专业名在系统里有两个历史写法。

所以字段校验、值域约束、跨字段逻辑冲突这类规则要做成可配置的：规则可配、清洗前后的差异可比对、批量执行不阻塞正常业务。清洗必须能预览——先看这一批会被改成什么样，确认之后再落，这是源头治理和用户信任的分界点。

7.6 黄金字段与多源冲突：谁说了算

同一件事，两个来源给了两个值。身份证号一边是录取库的，一边是证件读取核验的；学号一边是导入的，一边是学籍注册的；手机号一边是招办导的，一边是学生自己改的。

这类冲突绝不允许系统去猜，也不该由操作员当场凭感觉挑一个。规则要事先写死：

• 身份证号——以核验结果为准（本人证件在现场读过，效力高于任何一份历史表）；
• 学号——以学籍数据为准（后面要进全国学籍系统，口径必须一致）；
• 手机号——以本人最新自填为准（这是学生自己的信息，他改得动）。

三条规则的共通点是：先定权威性，再谈合并。 权威性来自"谁对这个数据的准确性负责"，不是来自"谁的库更先进"。

范围要照实说。眼下确定在系统里的是不允许出现两个人——同一个人被重复导入会被当场拦下并给出行号，因为一个主键只对应一条记录（见第八章）。而"这两条记录里的身份证不一致时改哪一个"这类字段级裁决规则，仍有一部分写在实施约定里，固化成可配置规则随批次补齐。把规则写进系统，和把规则写在实施人员的习惯里，是两件不同年限的事——前者第十所学校只花 25 人日，后者每换一所学校都要重问一遍。

这一层做没做，一个问题就能分辨："身份证与录取库不一致时，以谁为准？"答得出一条既定规则的，说明这件事想过；答"我们到时候人工核对一下"的，说明还没有规则，现场就得靠人背锅。

7.7 下一步：把已验证的映射推广到十六个入口

字段映射与值映射在核心入口已经跑通，也经受住了生产环境的检验。但目前这套机制还没有覆盖全部 16 个入口——部分入口仍是按列的先后顺序读表，意味着学校换一列顺序，就要请厂商改一次程序。

这件事已经列入建设批次：把导入映射做成一套统一框架，连同预校验与错误行回执一起标准化，目标是所有入口行为一致——任何入口都不该出现"换列序就要改程序"。

这条差距不藏，是因为它决定这套系统三年后还能不能低成本服务这所学校。学校问一句"我明年的表格式变了怎么办"，只有把机制和差距都摆清楚，才答得上来。

7.8 为什么源头治理在印象时代更要紧

过去数据出错的代价是内部返工。现在多一层：名单出错，学生当场就会知道学校不严谨。

第一章讲过那个参照系：学生在用消费互联网的水准打量学校的第一屏。而迎新系统里最容易被他直接看见的，正是数据质量——他的名字写错了、班级不对、专业显示成另一个、系统里出现两个同样的他。这些事在后台看是"历史数据遗留"，在学生看是**"这所学校连我的信息都搞不准"**。第一印象里最扎眼的一条，往往不是流程慢，是学校显得不严谨。

而源头这一关的功夫，说到底也不是为了让报表好看。数据进得来、拦得住、对得上，是为了后面能拿它做一件事：把这一个学生和那八千个学生区分开来。

分不出个体，"个性化推送""精准资助""只给他那一条"全是空话。先把数据落到每一个人身上，再把身份与权限划清楚，后面所有服务主张才有地基。