📚 课程目录第3章数据质量规则体系

3. 数据质量规则体系

数据质量规则体系是灰度发布与回放验证的“度量基准”。没有统一、可量化的规则，回放验证就无法判断数据质量是“变好”还是“变差”。本章从规则分类、定义规范、元数据管理三个维度构建完整的规则体系。

3.1 数据质量规则分类

数据质量规则通常按六维模型划分，覆盖数据从产生到消费的全生命周期。下表列出各维度的定义、典型规则示例及适用场景：

维度	定义	典型规则示例	适用场景
完整性	数据记录、字段是否存在缺失或空值	非空校验、主键缺失率 < 0.1%	ETL 入仓、API 响应字段校验
准确性	数据值与真实值或标准值的吻合程度	金额精度校验、枚举值范围校验	财务对账、业务指标计算
一致性	同一数据在不同系统或时间点是否一致	跨表关联字段值匹配、汇总值比对	数据仓库与业务系统同步
及时性	数据从产生到可用的时间延迟是否满足要求	T+1 延迟 < 30 分钟、实时延迟 < 5 秒	实时数仓、风控决策
唯一性	数据实体是否存在重复记录	主键唯一、业务键去重率 100%	用户画像、订单表
有效性	数据是否符合业务定义的格式、范围或约束	手机号正则校验、日期格式校验	数据入库前清洗

灰度发布提示： 在灰度回放验证中，优先关注完整性和一致性维度。完整性确保回放数据不丢失，一致性确保新旧规则输出结果可对比。

3.2 规则定义规范

规则定义规范确保每条质量规则可理解、可执行、可追溯。规范包含以下核心要素：

规则标识：全局唯一 ID，格式为 DQ-{维度缩写}-{序号}，如 DQ-INT-001。
规则名称：简短描述规则目的，如“订单金额非空校验”。
规则表达式：使用标准 SQL 或 DSL 描述校验逻辑，支持参数化配置。
阈值配置：定义通过/告警/失败的分级阈值，如“失败阈值 > 5%”。
生效范围：指定规则适用的数据源、表、字段及环境（开发/测试/生产）。
版本号：语义化版本，如 v1.2.0，用于灰度发布时追踪规则变更。

以下是一个完整的规则定义示例：

{
  "ruleId": "DQ-ACC-023",
  "ruleName": "订单金额与明细汇总一致性校验",
  "dimension": "accuracy",
  "expression": "SELECT order_id, SUM(line_amount) AS total FROM order_detail GROUP BY order_id HAVING ABS(total - order_amount) > 0.01",
  "threshold": {
    "pass": 0,
    "warn": 0.001,
    "fail": 0.01
  },
  "scope": {
    "datasource": "dw_core",
    "tables": ["orders", "order_detail"],
    "env": ["staging", "production"]
  },
  "version": "v1.2.0",
  "owner": "data_quality_team"
}

避坑指南： 规则表达式必须避免使用非确定性函数（如 NOW()、RAND()），否则回放验证时新旧规则结果无法稳定对比。

3.3 规则元数据管理

规则元数据管理是规则体系的“大脑”，负责存储、检索、版本控制及依赖分析。元数据模型包含以下核心实体：

规则定义表：存储规则 ID、名称、表达式、阈值、版本等静态信息。
规则实例表：记录每次规则执行的任务 ID、开始时间、结束时间、状态、结果摘要。
规则依赖图：记录规则之间的上下游依赖关系，用于灰度发布时评估影响范围。
规则变更日志：记录每次规则修改的版本、操作人、变更原因、前后对比。

下图展示规则元数据管理的核心架构与流转关系：

3.4 规则版本与灰度策略

规则元数据管理必须支持版本化，才能与灰度发布流程无缝衔接。核心策略如下：

版本状态	含义	灰度阶段	回放验证要求
DRAFT	规则正在编辑，未生效	开发环境	无
STAGING	规则已提交，等待灰度验证	灰度环境	必须通过回放验证
ACTIVE	规则已发布，全量生效	生产环境	回放验证通过后自动升级
ROLLBACK	规则回滚至上一版本	生产环境	回放验证失败时触发

  最佳实践： 规则元数据管理建议使用独立的元数据库（如 MySQL + Redis 缓存），与业务数据存储分离。每次灰度发布前，自动比对 STAGING 与 ACTIVE 版本的规则差异，生成回放验证用例清单。