4. 准确性指标定义：数据值域校验、格式校验、逻辑校验、业务规则匹配率

准确性，说白了就是数据跟真实世界是不是一回事。你想想看，一个客户的年龄填了 180 岁，或者一个订单金额出现了负数，这种数据就算入库了，谁敢用？

我做了这么多年数据治理，最怕听到的一句话就是：「数据量很大，跑得也快，但总觉得哪里不对。」嗯，问题往往就出在准确性上。今天咱们就把准确性的四个核心校验维度掰开揉碎了讲清楚。

4.1 数据值域校验：数据不能「出圈」

值域校验，就是给数据划个圈。数据只能在圈里待着，出了圈就是异常。我个人习惯把它分成两类：离散值域和连续值域。

值域校验的指标定义很简单：

值域校验通过率 = 通过值域校验的记录数 / 总记录数 × 100%

这个指标建议按字段粒度去算。比如「年龄字段值域通过率」「单价字段值域通过率」，别混在一起算一个总数，那样看不出问题在哪。

4.2 格式校验：数据得「长对样」

格式校验，就是检查数据是不是符合规定的格式模板。说白了，手机号得是 11 位数字，邮箱得带 @，身份证号得是 18 位。格式不对，数据就没法用。

我见过最离谱的格式问题是什么？一个日期字段，同一列里出现了「2024-01-01」「2024/01/01」「2024年1月1日」「01/01/2024」四种格式。你想想看，这种数据让下游系统怎么解析？

常见的格式校验规则包括：

• 长度校验：固定长度（如身份证 18 位）或最大/最小长度（如地址不超过 200 字）
• 字符类型校验：纯数字、纯字母、字母数字组合、是否包含特殊字符
• 正则表达式校验：邮箱、手机号、邮政编码等复杂格式
• 日期格式校验：统一为 yyyy-MM-dd，拒绝其他格式

格式校验的指标：

格式校验通过率 = 通过格式校验的记录数 / 总记录数 × 100%

建议按字段+校验规则双重维度去统计。比如「手机号-长度校验通过率」「邮箱-正则校验通过率」，这样定位问题更精准。

4.3 逻辑校验：数据不能「自相矛盾」

逻辑校验，是准确性校验里最有意思的一环。它不只看单个字段，而是看字段之间的关系是否合理。说白了，就是数据不能自己打自己脸。

举个例子：

• 「出生日期」是 2000 年，「入职日期」是 2010 年，合理
• 「出生日期」是 2000 年，「入职日期」是 1995 年，这就离谱了——难道 5 岁就上班了？

常见的逻辑校验场景：

逻辑校验通过率 = 通过逻辑校验的记录数 / 总记录数 × 100%

4.4 业务规则匹配率：数据得「懂业务」

业务规则匹配率，是准确性校验的终极形态。它不只看数据本身对不对，还要看数据是不是符合业务上的「潜规则」。这些规则往往写在业务人员的脑子里，而不是数据库文档里。

我举个例子你就明白了：

• 值域校验：年龄在 0-150 之间 → 通过
• 逻辑校验：出生日期早于入职日期 → 通过
• 业务规则：退休人员年龄 > 60（男）或 > 55（女），且状态为「在职」→ 不通过

看到了吗？前两个校验都过了，但业务规则告诉你：一个 65 岁的「在职」员工，这数据肯定有问题。

业务规则匹配率的计算：

业务规则匹配率 = 匹配所有业务规则的记录数 / 总记录数 × 100%

这里有个关键点：业务规则往往是组合条件。一条记录可能同时违反多条规则，但计算匹配率时，只要违反任意一条就算「不匹配」。

4.5 知识体系总览

下面这张图，把四个维度的关系画清楚了。你可以把它当作准确性校验的「作战地图」。

4.6 四个维度的协同关系

这四个维度不是孤立的，它们有明确的依赖关系。我画个简单的层级你就明白了：

1. 第一层：值域校验 — 最基础，拦掉明显不合理的数据
2. 第二层：格式校验 — 确保数据结构统一，方便下游解析
3. 第三层：逻辑校验 — 检查字段间关系是否自洽
4. 第四层：业务规则匹配率 — 最高级，贴近真实业务场景

实际项目中，我建议按这个顺序逐步建立校验规则。别一上来就搞复杂的业务规则，先把值域和格式守住，数据质量就能提升一大截。