从规则到工单：大数据数据质量治理闭环

很多团队第一次做数据质量治理时，会先接入表行数波动、字段空值率、主键重复率、枚举值异常等规则。短期看，这些规则确实能发现问题，但运行一段时间后，平台里经常堆满告警：有些没人认领，有些被反复忽略，有些修完几天后又复发。

质量治理失败的根源通常不是规则太少，而是规则没有进入生产链路。成熟的数据质量体系本质上是“规则化”和“运行化”的治理机制，而不是人工抽查。一个可运营的数据质量系统至少要回答五个问题：

二、质量维度

数据质量维度是规则设计的分类框架，包括准确性、完整性、一致性、及时性、唯一性等维度。在大数据场景中，可以把常用维度落成如下工程规则：

质量维度不是越多越好，维度是为了让规则更容易管理，而不是为了堆概念。对于一张核心事实表，完整性、唯一性、及时性通常是第一优先级；对于指标宽表，准确性和一致性往往更关键。

三、规则配置

规则配置的核心目标是让质量检查从“写死在脚本里”变成“可配置、可复用、可审计”。一条工程化质量规则不应只包含 SQL 条件，还应该包含运行策略和处置策略：

<span>+------------------+</span>
| 质量规则配置      |
<span>+------------------+</span>
| 规则ID            |
| 规则名称          |
| 质量维度          |
| 数据对象          |
| 校验字段          |
| 校验逻辑          |
| 阈值              |
| 运行时机          |
| 失败等级          |
| 是否阻断          |
| 责任人            |
| 告警渠道          |
| 工单策略          |
<span>+------------------+</span>

可以把规则配置抽象成如下模型：

<span>rule_id:</span> dq_ads_order_amount_001
<span>rule_name:</span> 订单金额非负校验
<span>dimension:</span> accuracy
<span>table:</span> ads_order_summary_d
<span>partition:</span> dt=${bizdate}
<span>check_sql:</span> |
  <span>SELECT</span> COUNT(*) <span>AS</span> invalid_cnt
  <span>FROM</span> ads_order_summary_d
  <span>WHERE</span> dt=<span>'${bizdate}'</span>
    <span>AND</span> pay_amount < <span>0</span>
<span>threshold:</span>
  <span>operator</span>: <span>"="</span>
  value: <span>0</span>
<span>severity:</span> P1
<span>block_strategy:</span> block_downstream
<span>owner:</span> data_team_order
<span>alert:</span>
  channels: [im, phone]
<span>ticket:</span>
  auto_create: <span>true</span>
  sla_minutes: <span>60</span>

这类配置的好处是，规则平台可以统一解析，而不是让每个数仓开发在任务脚本中重复实现校验逻辑。

四、维度到规则

完整性规则最适合从数据到达和字段非空开始。比如 ODS 层检查分区是否存在，DWD 层检查关键业务字段是否为空，ADS 层检查指标结果是否为空。空字段规则会检查列中是否存在 null、空字符串或仅空格值，并且该规则会影响唯一值、格式匹配等其他规则的评分方式。

完整性规则示例

表级完整性
  ├─ 分区是否存在
  ├─ 分区行数是否 > 0
  └─ 今日行数是否偏离历史均值

字段级完整性
  ├─ 主键非空
  ├─ 业务日期非空
  └─ 核心指标非空

唯一性规则不应只看单字段主键。唯一性既可以校验单列唯一，也可以校验复合列唯一，复合列适合用于国家代码与证件号这类联合标识场景。

唯一性规则示例

单列唯一：
  order_id 不重复

联合唯一：
  user_id + event_id + event_time 不重复

业务实体唯一：
  country_code + certificate_no 不重复

及时性规则要区分“源系统时间”和“数据入仓时间”。freshness 的定义是：数据相对源系统或真实事件的新鲜程度，核心指标是数据生成或更新时间距离当前时间的间隔；官方也建议用最大时间戳、最小时间戳等方式检查数据是否足够新。

<span>及时性判断</span>

<span>事件发生时间</span> <span>event_time</span>
        <span>|
        v
</span><span>采集进入消息队列</span> <span>ingest_time</span>
        <span>|
        v
</span><span>写入</span> <span>ODS</span> <span>load_time</span>
        <span>|
        v
</span><span>加工成</span> <span>DWD</span> <span>process_time</span>
        <span>|
        v
</span><span>产出</span> <span>ADS</span> <span>publish_time</span>

准确性规则通常要结合业务事实或可信来源，一致性规则常见于跨层对账和跨系统对账。比如 DWD 明细汇总后的订单金额，应与 ADS 指标表一致；离线 Hive 表的会员状态，应与实时画像或主数据系统保持一致。

五、执行链路

质量规则只有接入调度链路，才会真正影响生产。否则它只是一个旁路监控系统，发现问题后仍然依赖人工判断和人工转发。

推荐把数据质量校验分成四个执行点：

不同执行点适合不同规则：

工程上，质量平台可以作为调度系统的一个插件。任务执行完成后，调度系统调用质量校验服务；质量服务读取规则配置，生成校验 SQL 或执行引擎任务；校验结果写入质量结果表，再由调度系统决定是否继续运行下游。

六、任务拦截

任务拦截是数据质量从“提醒”走向“治理”的关键。没有拦截机制，错误数据会继续扩散到下游，最终在报表、模型、接口或业务决策中暴露。

但拦截不能一刀切。质量规则应按照数据影响范围和业务容忍度设计不同策略：

一个常见误区是把所有规则都设成强阻断。这样会导致数据平台频繁中断，最终业务方和研发都会倾向于关闭规则。更合理的方式是：核心链路强拦截，非核心链路弱拦截；确定性错误强拦截，趋势性风险先告警；影响面大的规则优先拦截，低价值规则只记录。

七、告警分级

告警分级的目标不是“通知更多人”，而是让正确的人在正确时间收到正确严重程度的信息。告警太少会漏问题，告警太多会造成疲劳。

一条好的数据质量告警至少包含这些信息：

告警标题：ads_order_summary_d 支付金额对账失败
失败等级：P1
业务日期：<span>2026</span>-<span>09</span>-<span>17</span>
质量维度：准确性
失败规则：支付金额与 DWD 汇总差异率 <= <span>0.1</span><span>%</span>
实际结果：差异率 <span>3.7</span><span>%</span>
影响范围：订单经营看板、GMV 日报
处理建议：优先检查 dwd_order_pay_detail_d 是否补数
责任人：订单数仓小组
工单链接：DQ-<span>20260918</span>-<span>001</span>

告警分级可以结合规则等级、资产等级、影响范围和历史表现动态计算：

告警等级 = <span>f</span>(规则等级, 资产等级, 下游数量, SLA剩余时间, 历史复发次数)

例如，同样是空值率异常，发生在临时分析表上可能只是 P3，发生在公司级核心指标表上就可能是 P1。如果一个问题连续三天复发，即使单次影响不大，也应该升级，因为它说明根因没有被解决。

八、问题工单

工单是连接“发现问题”和“真正修复”的桥。没有工单，告警只是一条消息；有了工单，问题才有状态、责任人、SLA 和关闭标准。

建议质量工单包含以下状态流转：

工单字段不要设计得太复杂，但必须能支撑复盘：

工单关闭不能只看“任务重跑成功”。更好的关闭标准是：失败规则已重新通过，受影响下游已重刷或确认不受影响，根因分类已填写，必要时已补充防复发动作。

九、复盘机制

复盘不是开会追责，而是让同类问题少发生。质量复盘最好围绕根因，而不是围绕现象。

常见根因可以分为五类：

一个可运营的质量闭环可以表示为：

+<span>----------+</span>
| 定义规则 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 执行校验 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 失败拦截 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 分级告警 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 工单修复 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 复盘沉淀 |
+<span>----+-----+</span>
     |
     v
+<span>----------+</span>
| 优化规则 |
+<span>----+-----+</span>
     |
     +<span>--------------------+</span>
                          |
                          v
                      回到执行校验

规则不是终点，质量状态、问题处理和历史趋势才是运营抓手。

十、平台落地

从系统设计上看，一个数据质量平台可以分成六层：

落地顺序建议从核心资产开始，而不是全量铺开。先选 20 到 50 张核心表，覆盖完整性、唯一性、及时性和准确性四类基础规则，再接入调度拦截和告警工单。等规则稳定后，再扩展到一致性对账、跨系统校验、消费侧质量提示和质量分评分估。

质量分数可以作为运营指标，但不能替代问题治理。维度分数和总体分数的计算方式：维度分数可按通过规则的记录数除以总记录数计算，总体分数可由各维度分数汇总得到；这类分数适合做趋势观察和治理评估，但具体修复仍然要回到失败规则和失败记录。

十一、实践案例

假设我们有一张订单日汇总表 ads_order_summary_d，它支撑经营日报、GMV 看板和管理层周报。它的质量规则可以这样设计：

运行链路如下：

<span>dwd_order_detail_d</span>
        <span>|
        v
</span><span>质量规则</span> <span>A：分区完整性</span>
        <span>|
        v
</span><span>dws_order_user_d</span>
        <span>|
        v
</span><span>质量规则</span> <span>B：主键唯一性</span> <span>+</span> <span>金额非负</span>
        <span>|
        v
</span><span>ads_order_summary_d</span>
        <span>|
        v
</span><span>质量规则</span> <span>C：GMV</span> <span>对账</span> <span>+</span> <span>及时性</span>
        <span>|
        v
</span><span>经营看板</span> <span>/</span> <span>日报</span> <span>/</span> <span>API</span>

如果GMV 对账失败，系统应自动阻断经营看板刷新，生成 P1 告警并创建工单。责任人修复后，需要重跑对应分区，并再次执行对账规则。只有规则通过、下游刷新完成、工单记录根因后，问题才算真正关闭。