数据治理与数据质量全景知识图谱

4.1 元数据管理与数据目录

技术元数据：Schema、字段类型、分区信息、存储位置、更新频率。自动采集为主，连接器覆盖率决定目录完整度。

业务元数据：字段含义、Owner、使用场景、数据等级。需要人工标注 + 自动推断结合，是目录真正有用的关键。

搜索与发现：好的数据目录让人能像搜索引擎一样找到数据。关键能力：全文搜索、标签过滤、热度排序、相关推荐。

工程判断：数据目录的价值不在于"收录了多少表"，而在于"有多少人真的用它来找数据"。采用率比覆盖率更重要。

4.2 数据血缘

表级血缘：A 表经过 ETL 生成 B 表。实现相对简单（解析 DAG 编排工具的依赖关系），但粒度不够。

列级血缘：A 表的 X 列经过 JOIN + 转换生成 B 表的 Y 列。需要 SQL 解析引擎（如 sqllineage、OpenLineage），复杂 SQL 和 UDF 是难点。

运行时血缘 vs 静态血缘：静态解析 SQL 得到的是"可能的"血缘，运行时捕获得到的是"实际的"血缘。两者互补，运行时更准但开销更大。

血缘断裂：中间经过 Python 脚本、API 调用或手动操作的环节，血缘链路会断。这是所有血缘系统的共同痛点，需要手动补录或约定规范。

4.3 数据质量监控

质量维度：完整性（NULL 率）、准确性（值域校验）、一致性（跨表/跨系统对账）、时效性（数据新鲜度）、唯一性（主键重复）。

规则引擎：预定义规则（NOT NULL、范围检查、正则匹配）+ 自定义 SQL 断言。Great Expectations 和 dbt tests 是代码化质量检查的代表。

异常检测：基于历史统计基线自动发现异常（行数突变、NULL 率飙升、分布偏移）。Monte Carlo、Soda 等工具提供开箱即用的异常检测。

工程判断：质量规则不是越多越好。规则太多会产生告警疲劳，关键是覆盖核心链路的关键断言，并确保告警有人响应。

4.4 数据合约

核心理念：数据生产者对下游消费者做出明确承诺——Schema 结构、更新频率、质量 SLA、兼容性策略。类似 API 契约，但面向数据。

实现方式：YAML/JSON 定义合约 → CI 流水线校验 → 违反合约阻断发布。将质量检查从"事后发现"前移到"发布前拦截"。

生产者驱动 vs 消费者驱动：生产者驱动（我承诺提供什么）更可持续，消费者驱动（我需要什么）更灵活但协调成本高。

4.5 合规与脱敏

分类分级：将数据按敏感度分级（公开/内部/机密/绝密），按类型分类（PII/PHI/财务/行为）。自动分类引擎通过正则 + ML 识别敏感字段。

动态脱敏 vs 静态脱敏：动态脱敏在查询时实时处理（按角色展示不同粒度），静态脱敏生成脱敏副本。动态更灵活但有性能开销，静态更安全但数据副本多。

GDPR 删除权："被遗忘权"要求能删除特定用户的所有数据。需要完整的数据血缘支撑——知道用户数据流向了哪些下游系统和表。

审计链路：谁在什么时间访问了什么数据、做了什么操作。审计日志是合规的最后防线，也是事后追溯的唯一依据。

4.6 保留期、删除权与副本清单

保留矩阵：每类数据都要写清业务目的、法律或审计依据、在线保留期、归档保留期、备份保留期、到期动作和例外审批人，不能用“以后可能有用”作为长期保留理由。

删除权实现：删除请求不能只落到主库，还要通过血缘和副本清单覆盖搜索索引、缓存、报表、日志、对象存储、备份、下游系统和第三方副本。

删除证明：高风险删除要能输出请求来源、数据主体、影响范围、保留例外、执行结果、失败重试和验证记录。主库删了但备份、索引和报表仍能查到，删除治理就没有完成。

执行承接：真正执行删除、匿名化或历史批量清理时，应按 生产数据修复与运维操作 的 dry-run、审批、审计、复核和不可逆操作要求处理。

数据库下钻：如果问题已经落到生产数据库里的热数据、温数据、冷归档、分区、历史查询路由、附件和索引副本清理，继续看 如何设计数据库归档、冷热分层与数据生命周期。