3. 数据质量维度在生产中的可操作化

数据质量维度如果只停留在“完整性要好、准确性要高”这样的口号层面，就无法进入生产运维。真正可操作化的关键，是把每个维度翻译成三件东西：可采集的指标、可判定的阈值、可触发的告警规则。本节以一张订单明细表 dwd_order_detail（按天分区，日均约 2000 万行）为例，说明六个维度如何落地。

一、从维度到指标：先定义“可计算的口径”

指标必须能在 SQL 或数据质量引擎中直接算出，且分子分母明确。下表给出六个维度的典型指标口径（示例参数，非实测值）：

注意口径要固定“统计范围”：是全表、增量分区，还是抽样。生产上通常对增量分区做全量校验，对历史大表做分层抽样（如 1% 或固定 10 万行），并在指标名中标注范围，避免口径漂移。

二、阈值：静态阈值 + 动态基线

阈值不是拍脑袋定的。推荐“静态红线 + 动态基线”双层设计。静态红线来自业务容忍度，例如主键重复率必须为 0，空值率不得超过 0.5%。动态基线来自历史统计，例如用近 14 天同指标的中位数和 MAD（中位数绝对偏差）计算合理波动区间：

基线中位数 m = median(近14天指标值)
波动尺度 s = 1.4826 * median(|x - m|)
上界 = m + 3s，下界 = max(0, m - 3s)
若今日指标 > 上界 或 < 下界，则判定为异常波动

这样既能抓住“绝对值超标”，也能抓住“相对自身历史突然变差”。例如空值率平时 0.1%，今天 0.4% 虽未破 0.5% 红线，但已超出动态上界，应触发预警而非严重告警。

三、告警规则：分级、去噪与收敛

告警规则要解决“什么时候响、响给谁、响多严重”。建议按严重度分三级：

• P1 阻断：主键重复率 > 0、关键字段空值率 > 5%、分区延迟超过 SLA 2 小时。立即电话/IM 通知值班。
• P2 预警：指标突破动态上界但未破红线，或连续 2 个周期恶化。IM 通知数据 owner，当日处理。
• P3 观察：单周期轻微波动，仅记录到质量看板，不主动打扰。

去噪的关键是“连续 N 次触发才升级”和“同一规则同一分区去重”。例如一致性匹配率下降，若只出现一次可能是上游延迟，连续两次才升级为 P2。告警内容必须携带：规则名、分区、当前值、阈值、基线值、影响行数、排查入口（如质量报告链接）。

四、六维度落地关系图

下图把六个维度、对应指标、阈值类型和告警级别放在同一张关系图中，便于对照配置。

五、一个可执行的配置样例

把上述设计写成质量规则配置（以 YAML 风格示例，字段为教学假设）：

rule: order_detail_completeness
table: dwd_order_detail
partition: dt=${bizdate}
metric: null_rate
field: order_id
threshold:
  static: 0.005
  dynamic: {window: 14, k: 3}
alert:
  level: P1
  condition: "value > static OR value > upper_bound"
  notify: [oncall, data_owner]
  dedup: partition
  escalate_after: 1

rule: order_detail_uniqueness
table: dwd_order_detail
partition: dt=${bizdate}
metric: duplicate_rate
field: order_id
threshold:
  static: 0
alert:
  level: P1
  condition: "value > 0"
  notify: [oncall]
  dedup: partition

配置完成后，质量引擎在每个分区产出后自动执行，把指标写入质量库，并按规则触发告警。值班人员收到告警后，先看影响行数和分区，再决定是否阻断下游任务。

六、结果判读与闭环

指标、阈值、告警配置好之后，还要看“判读逻辑”是否成立。例如某天完整性空值率从 0.1% 升到 0.45%，未破 0.5% 红线，但超过动态上界，触发 P2。数据 owner 排查发现上游埋点版本变更导致部分订单号缺失，修复后次日回落。这个过程说明：动态基线能提前发现趋势，静态红线能兜住底线，两者缺一不可。

最终，六个维度应形成一张“质量规则清单”，每条规则都有明确的指标口径、阈值来源、告警级别、通知对象和处置入口。只有做到这一步，数据质量才从“感觉”变成“可观测、可告警、可追责”的生产能力。