数据治理

数据治理治理蓝图

Posted by

一、我们要解决什么问题（Why）

现状痛点

  • 数据错误通常在报表/资损/客诉阶段才被发现，已产生业务影响
  • 问题定位依赖人工排查，责任不清、修复慢、重复发生
  • 数据质量建设停留在“抽查/事后对账”，缺乏体系化治理

治理目标

从“事后救火”转为“过程取证 + 闭环治理”， 让核心数据 可监控、可追责、可持续改善。

二、总体思路（一句话）

双轨监控 + 分级治理 + 闭环运营

  • 实时 Binlog 监控：发现“正在发生的错误”
  • 离线数仓监控：发现“历史累积的问题”
  • 分级告警 + 责任到人：只对真正重要的问题动用资源

三、核心架构（How）

业务库(MySQL/TiDB)
│
Binlog
▼
CDC → Kafka ──► 实时质量监控（取证，不拦截）
│ │
│ ▼
│ Binlog 违规事件表
▼
Doris ODS/DWD/DWS/ADS
│
▼
离线质量监控（全量扫描）
│
▼
离线违规结果表

关键区分

  • Binlog：单条事件、实时、无历史 → 防止新脏数据继续扩散
  • 离线：全量、含历史 → 发现加工逻辑与历史遗留问题

四、治理范围如何控制（避免失控）

1️⃣ 表分级策略（先抓重点）

表级别判定标准监控策略
A 类：核心资产影响结算/资损/合规/核心报表Binlog + 离线
B 类：重要维度主数据/配置，影响范围广仅离线
C 类：低风险表日志/临时暂不监控

第一阶段只做 A 类表，确保投入产出比

2️⃣ 字段级聚焦（不做全字段）

  • 只监控 关键字段 + 高风险字段
  • 主键/唯一键/非空字段 强制监控
  • 备注、日志类字段不纳入

五、告警与治理机制（不制造噪音）

三级响应机制

等级含义处理方式
L1 严重资损 / 合规 / 高频错误实时告警 + 工单
L2 警告业务逻辑问题日报汇总
L3 信息低风险、试探规则仅记录

核心原则：不是所有问题都要告警

六、治理闭环（确保问题真的解决）

问题生命周期

发现 → 指派 → 修复 → 验证 → 收敛

  • 每条问题都有 责任人 + SLA
  • 超时自动升级
  • 重复问题触发根因分析

修复是否有效？

  • 规则持续运行
  • 连续 7 天不再触发 → 自动判定“已收敛”

七、治理效果如何衡量（证明价值）

指标管理价值
L1 问题数量趋势是否减少核心风险
平均修复时长组织响应效率
规则覆盖率核心数据是否被保护
误报率规则质量

每日输出《数据质量健康度看板》

八、实施路线图（可控推进）

  • 阶段 1：A 类表 + 核心字段（当前）
  • 阶段 2：扩展 B 类表 + 指标波动监控
  • 阶段 3：成熟规则前移到源头拦截

九、管理层能得到什么（Value）

  • 核心数据风险 提前暴露，而不是事后背锅
  • 数据问题 可追责、可量化、可持续下降
  • 为结算、风控、经营分析提供 可信数据基础

这是一套长期可运营的数据治理体系，而不是一次性项目

上一篇 数据质量监控落地实施方案