数据质量规则分级不是所有异常都该半夜叫人一、质量监控太敏感会把团队训练成忽略告警数据质量监控是数据治理的基础。空值、重复、波动、延迟、枚举异常都要检查。但如果所有异常都用同一等级告警很快就会告警疲劳。半夜被低风险字段波动叫醒几次后真正严重的问题也可能被忽视。数据质量规则需要分级。哪些问题会影响核心指标哪些只影响边缘报表哪些可以工作时间处理。分级不是降低要求而是让处理优先级和业务影响匹配。二、按影响面、紧急度和可恢复性分级质量规则可以按 P0 到 P3 管理。P0 影响核心指标或数据安全立即处理P1 影响重要报表当日处理P2 影响局部分析排期处理P3 只是提示。flowchart TD A[质量规则触发] -- B[判断影响面] B -- C[判断紧急度] C -- D[判断可恢复性] D -- E{等级} E --|P0| F[立即告警] E --|P1| G[工作群通知] E --|P2| H[生成治理任务] E --|P3| I[记录趋势]同一条规则在不同表上等级也可能不同。核心指标表的空值比临时分析表的空值严重得多。三、规则配置要带负责人和处理动作质量规则如果只定义阈值没有负责人和处理建议触发后还是没人管。rule_id: order_amount_not_null table: dwd_order_item_di field: pay_amount check: not_null severity: P0 owner: data_platform action: 暂停下游核心指标产出检查订单同步链路规则配置里写清处理动作可以降低排障时间。尤其是 P0 规则不能只告诉人“出错了”还要告诉人第一步查哪里。四、质量规则要评估误报和漏报规则上线后要看触发频率、处理时长、误报比例和漏报案例。一个每天触发但没有业务影响的规则应该降级或调整阈值。一个从不触发却漏掉事故的规则说明覆盖不够。还要处理依赖关系。上游表延迟会导致多个下游规则同时报警。系统应合并根因相同的告警避免一处延迟炸出一屏通知。最后质量规则要和数据 SLA 绑定。核心报表的产出时间、完整性和准确性都应该有可观测指标。规则不是治理的终点而是治理动作的入口。规则还要有静默窗口。大促、迁移、历史回刷期间部分规则可能会预期触发。静默不是关闭治理而是给特殊操作设置审批、时间范围和复盘要求。没有记录的静默会让真实事故被掩盖。根因分析要沉淀到规则库。一次空值事故如果来自上游接口字段变更就应该增加 schema 变更检测而不是只修当天数据。质量治理的成熟度体现在规则能从事故中变得更准。最后质量看板要看趋势。单次触发只是事件长期误报率、修复时长和重复问题才反映治理水平。数据质量不是靠一次巡检变好而是靠规则、流程和负责人持续闭环。质量规则还应接入发布流程。新表上线前至少要配置主键、分区、行数波动和核心字段校验。旧表新增字段时也要同步补规则。等事故发生后再补监控治理成本会高很多。告警文案也要可执行。只写“表异常”没有意义应包含表名、分区、规则、当前值、阈值、负责人和建议动作。值班人员看到告警时第一眼就应该知道该查同步、查上游还是查口径变更。最后分级要定期复盘。业务重点变化后原来的 P2 表可能变成核心链路原来的 P0 规则也可能不再关键。规则等级如果不更新监控会慢慢偏离真实业务风险。五、总结数据质量规则要按业务影响分级。P0 立即处理P1 当日处理P2 排期治理P3 记录趋势。规则配置应包含负责人、阈值、处理动作和依赖关系。好的质量监控不是异常越多越专业而是让真正重要的问题被及时看见。
数据质量规则分级不是所有异常都该半夜叫人一、质量监控太敏感会把团队训练成忽略告警数据质量监控是数据治理的基础。空值、重复、波动、延迟、枚举异常都要检查。但如果所有异常都用同一等级告警很快就会告警疲劳。半夜被低风险字段波动叫醒几次后真正严重的问题也可能被忽视。数据质量规则需要分级。哪些问题会影响核心指标哪些只影响边缘报表哪些可以工作时间处理。分级不是降低要求而是让处理优先级和业务影响匹配。二、按影响面、紧急度和可恢复性分级质量规则可以按 P0 到 P3 管理。P0 影响核心指标或数据安全立即处理P1 影响重要报表当日处理P2 影响局部分析排期处理P3 只是提示。flowchart TD A[质量规则触发] -- B[判断影响面] B -- C[判断紧急度] C -- D[判断可恢复性] D -- E{等级} E --|P0| F[立即告警] E --|P1| G[工作群通知] E --|P2| H[生成治理任务] E --|P3| I[记录趋势]同一条规则在不同表上等级也可能不同。核心指标表的空值比临时分析表的空值严重得多。三、规则配置要带负责人和处理动作质量规则如果只定义阈值没有负责人和处理建议触发后还是没人管。rule_id: order_amount_not_null table: dwd_order_item_di field: pay_amount check: not_null severity: P0 owner: data_platform action: 暂停下游核心指标产出检查订单同步链路规则配置里写清处理动作可以降低排障时间。尤其是 P0 规则不能只告诉人“出错了”还要告诉人第一步查哪里。四、质量规则要评估误报和漏报规则上线后要看触发频率、处理时长、误报比例和漏报案例。一个每天触发但没有业务影响的规则应该降级或调整阈值。一个从不触发却漏掉事故的规则说明覆盖不够。还要处理依赖关系。上游表延迟会导致多个下游规则同时报警。系统应合并根因相同的告警避免一处延迟炸出一屏通知。最后质量规则要和数据 SLA 绑定。核心报表的产出时间、完整性和准确性都应该有可观测指标。规则不是治理的终点而是治理动作的入口。规则还要有静默窗口。大促、迁移、历史回刷期间部分规则可能会预期触发。静默不是关闭治理而是给特殊操作设置审批、时间范围和复盘要求。没有记录的静默会让真实事故被掩盖。根因分析要沉淀到规则库。一次空值事故如果来自上游接口字段变更就应该增加 schema 变更检测而不是只修当天数据。质量治理的成熟度体现在规则能从事故中变得更准。最后质量看板要看趋势。单次触发只是事件长期误报率、修复时长和重复问题才反映治理水平。数据质量不是靠一次巡检变好而是靠规则、流程和负责人持续闭环。质量规则还应接入发布流程。新表上线前至少要配置主键、分区、行数波动和核心字段校验。旧表新增字段时也要同步补规则。等事故发生后再补监控治理成本会高很多。告警文案也要可执行。只写“表异常”没有意义应包含表名、分区、规则、当前值、阈值、负责人和建议动作。值班人员看到告警时第一眼就应该知道该查同步、查上游还是查口径变更。最后分级要定期复盘。业务重点变化后原来的 P2 表可能变成核心链路原来的 P0 规则也可能不再关键。规则等级如果不更新监控会慢慢偏离真实业务风险。五、总结数据质量规则要按业务影响分级。P0 立即处理P1 当日处理P2 排期治理P3 记录趋势。规则配置应包含负责人、阈值、处理动作和依赖关系。好的质量监控不是异常越多越专业而是让真正重要的问题被及时看见。
