📚 课程目录第2章校验规则基础

校验规则基础：规则的定义与组成

各位同学，欢迎来到第二章。上一章我们聊了数据质量为什么重要，以及常见的质量维度。今天咱们要落地了——讲讲校验规则到底长什么样。

说实话，我见过不少团队，一上来就写规则，结果写出来的东西五花八门。有的规则连名字都看不懂，有的阈值设得离谱，还有的告警级别全是「严重」。最后运维同学天天被告警轰炸，反而把真正的问题漏掉了。

所以，咱们先把规则的结构搞清楚。就像盖房子，先得有图纸。

2.1 规则的五个核心要素

一条完整的校验规则，说白了就五个东西：规则名称、规则类型、校验逻辑、阈值、告警级别。缺一个，这条规则就不完整。

要素	说明	示例
规则名称	唯一标识，让人一眼看懂校验什么	「订单金额非空校验」
规则类型	属于哪类质量维度	完整性、准确性、一致性…
校验逻辑	具体怎么算、怎么比	IS NULL、COUNT、AVG…
阈值	触发告警的边界值	空值率 > 5%
告警级别	问题严重程度	P0/P1/P2/P3

咱们一个一个拆开讲。

2.1.1 规则名称

规则名称不是随便起的。我个人的习惯是：「数据对象 + 校验维度 + 校验内容」。比如「用户表_完整性_手机号非空校验」。这样不管谁看到，都能立刻知道这条规则在查什么。

小技巧： 规则名称里不要带时间戳或版本号。这些信息应该放在元数据字段里，而不是名字里。否则每次改版本都要改规则名，维护成本很高。

2.1.2 规则类型

规则类型对应我们第一章讲的质量维度。常见的就这么几种：

完整性：字段有没有空值？记录有没有缺失？
准确性：数据值对不对？比如金额不能为负数。
一致性：不同表或系统间的数据是否匹配？
及时性：数据有没有按时到达？
唯一性：主键有没有重复？
规范性：格式是否符合标准？比如手机号必须是11位。

嗯，这里要注意：一条规则只能对应一种类型。别把「完整性」和「准确性」混在一起写。我曾经在一个项目里看到有人把「非空校验」和「格式校验」写进同一条规则，结果告警出来根本分不清是哪种问题，排查起来特别痛苦。

2.1.3 校验逻辑

校验逻辑是规则的核心。它告诉系统：你到底要怎么做。

我习惯把校验逻辑分成三类：

简单比较：字段值是否等于某个常量。比如 age >= 0。
聚合计算：对一批数据做统计。比如空值率、重复率。
跨表关联：两张表的数据是否对得上。比如订单表的用户ID是否在用户表里存在。

举个例子，一条「订单金额完整性」的校验逻辑，用SQL写出来大概是这样：

-- 校验逻辑：统计订单金额为空的记录数
SELECT COUNT(*) AS null_count
FROM orders
WHERE order_amount IS NULL;

你看，逻辑很直白。但实际项目中，很多人会把逻辑写得很复杂，恨不得一个SQL解决所有问题。我建议你反过来：一条规则只做一件事。逻辑越简单，越容易排查问题。

2.1.4 阈值

阈值就是「红线」。过了这条线，就触发告警。

阈值怎么设？我见过两种极端：

阈值设得太严，天天告警，最后没人看。
阈值设得太松，问题都爆了还没告警。

我个人建议：先松后紧。刚开始上线时，阈值可以设得宽松一些，观察一段时间，根据实际数据分布再调整。比如空值率，可以先设 10%，运行两周后发现正常数据空值率只有 1%，那就可以收紧到 3%。

注意： 阈值不是一成不变的。业务变了、数据量变了，阈值也要跟着变。建议每季度 review 一次阈值配置。

2.1.5 告警级别

告警级别决定了问题来了谁处理、多快处理。我常用的分级是这样的：

级别	含义	响应要求	示例场景
P0	严重	立即处理，30分钟内响应	核心表数据丢失、主键重复
P1	高	2小时内处理	关键字段空值率超标
P2	中	24小时内处理	非关键字段格式异常
P3	低	记录即可，定期修复	数据延迟、轻微偏差

这里有个坑：别把所有规则都设成P0。我见过一个团队，上线了200条规则，其中180条是P0。结果运维同学每天被告警淹没，真正重要的P0反而被忽略了。你想想看，如果每条消息都是「紧急」，那还有「紧急」吗？

2.2 规则的生命周期管理

规则不是写出来就完事了。它有自己的生命周期。我把它分成五个阶段：

2.2.1 需求分析

这一步很多人会跳过。但我想说：需求分析决定了规则有没有用。

你需要搞清楚：

这个数据是给谁用的？
用的人最关心什么？
数据出问题会有什么影响？

举个例子，财务同学最关心金额字段的准确性，运营同学可能更关心数据的及时性。不同角色，规则优先级完全不同。

2.2.2 规则设计

需求明确了，就开始设计规则。这一步要确定：

规则名称和类型
校验逻辑怎么写
阈值设多少
告警级别定多高

我建议你写一个规则设计文档，哪怕只有一页纸。把上面五个要素写清楚，评审通过后再开发。别急着写代码，想清楚再动手。

2.2.3 开发部署

开发阶段就是把设计变成可执行的代码或配置。这里要注意：

先做单元测试，用少量数据验证逻辑对不对。
再做集成测试，看看规则会不会影响其他系统。
最后灰度上线，先跑一小部分数据，观察效果。

  我的经验： 规则上线前，一定要跑一遍历史数据。看看如果这条规则早就存在，过去一个月会触发多少次告警。如果告警次数异常多，说明阈值可能设得太严了。

2.2.4 运行监控

规则上线后，不是就完事了。你要盯着它：

规则有没有正常执行？
告警有没有被及时处理？
阈值是不是合理？

我见过最离谱的情况：一条规则上线后从来没触发过告警，大家都觉得数据质量很好。结果半年后才发现，规则逻辑写错了，根本没生效。所以，定期检查规则的执行状态，比检查数据本身更重要。

2.2.5 优化退役

规则也是有寿命的。业务变了、数据源变了，原来的规则可能就不适用了。这时候你要做两件事：

优化：调整阈值、修改逻辑、升级告警级别。
退役：如果规则已经没用了，就果断下线。别留着占资源。

我曾经在一个客户那里看到，他们有300多条规则，其中50多条已经两年没触发过告警了。一问才知道，对应的数据表早就下线了。这些「僵尸规则」不仅浪费计算资源，还会让新同学误以为这些数据还在被监控。

注意： 规则退役前，一定要确认没有其他规则或流程依赖它。建议先标记为「废弃」状态，观察一个月再彻底删除。

2.3 本章小结

这一章我们讲了规则的五要素：名称、类型、逻辑、阈值、告警级别。也聊了规则从生到死的五个阶段。说白了，规则管理就是一个闭环：设计→开发→运行→优化→退役，然后不断循环。