数据治理与质量

课程简介

数据血缘、元数据管理、数据质量监控与合规。

🎬 本课程视频：Data Engineering — 数据工程基础

---

数据治理：血缘、元数据、质量与合规

一、数据治理不是什么？

很多人听到"数据治理"就会想到一堆让人头疼的规章制度和审批流程。但数据治理的本质不是阻碍数据使用的"官僚体系"，而是让数据可信、可用、安全的基础设施。

想象一下你进入一个图书馆——所有的书都按分类摆好，每本书都有标签说明它的位置和内容，你能快速找到需要的书，而且确保你借到的书是完整无缺的。这就是数据治理要做的事。

二、数据血缘（Data Lineage）

数据血缘追踪数据从源头到消费的完整流动路径。它回答三个问题：数据从哪里来？经过了哪些转换？被哪些下游使用？

2.1 为什么数据血缘很重要？

当上游表 Schema 变更时（比如某个字段被删除了），血缘分析能自动标记所有下游受影响的任务、报表和模型。数据出问题时沿着血缘链向上追溯找到根因很简单，向下评估影响范围也很直接。此外血缘让数据团队可以回答审计问题——"这个报表的数据来源是什么？"

2.2 数据血缘的工具

• Apache Atlas：Hadoop 生态的开源数据治理平台，支持从 Hive、HBase、Kafka 等系统自动捕获血缘信息。
• DataHub：LinkedIn 开源的数据目录平台，支持自动和手动血缘构建。
• dbt：自动生成模型级别的血缘图——dbt docs 命令生成的文档中包含了完整的 lineage graph。
• OpenLineage：血缘采集的开放标准框架，可以被不同的治理平台集成。
• 商业方案：Alation、Collibra、Informatica 提供更完整的企业级数据治理方案。

2.3 血缘的实施建议

从简单的粒度开始——先记录"表级别的血缘"（A 表 → B 表），随着团队成熟再到"字段级别的血缘"（A 表的字段 X → B 表的字段 Y）。血缘的自动采集优于手动录入——自动采集可能不完美，但 80% 自动 + 20% 手动远比 100% 手动可持续。

三、元数据管理（Metadata Management）

元数据是关于数据的数据——表结构、字段含义、所有者、创建时间、更新频率、数据量、使用频率等。好的元数据管理让数据团队可以自主发现数据，而不是靠口口相传。

3.1 元数据的三种类型

技术元数据（Technical Metadata）：数据库 Schema、字段类型、约束定义、ETL 脚本。这是最基础的元数据，通常可以从数据库和 ETL 工具自动获取。

业务元数据（Business Metadata）：字段的业务含义、指标的计算逻辑、数据的所有者和监管人。这部分需要业务团队和数据团队的协作录入。

操作元数据（Operational Metadata）：数据管道的运行历史、数据新鲜度、访问频率、查询性能。用于监控数据资产的健康状态。

3.2 元数据管理的最佳实践

• 从自动化开始：使用工具从数据库和 ETL 系统自动提取技术元数据。
• 定义元数据标准：统一命名规范（如 snake_case 或 camelCase）、字段注释要求、敏感数据标签。
• 建立数据目录：DataHub、Amundsen、Apache Atlas 都是不错的选择。
• 将元数据维护嵌入日常流程：在代码审查中要求新增字段必须添加注释和业务含义。

四、数据质量（Data Quality）

数据质量从六个维度评估，这是业界公认的框架：

1. 完整性（Completeness）：数据是否缺失？关键字段的非空率是否符合要求？
2. 准确性（Accuracy）：数据是否反映了真实世界的状态？金额计算是否正确？
3. 一致性（Consistency）：不同系统中的同一数据是否一致？CRM 中的客户名称是否和 ERP 中的一样？
4. 时效性（Timeliness）：数据是否在要求的时间内可用？
5. 唯一性（Uniqueness）：是否存在重复数据？主键是否唯一？
6. 有效性（Validity）：数据格式是否符合规范？邮箱格式是否正确？日期是否在合理范围内？

推荐用 Great Expectations 将质量断言写成代码，集成到 CI/CD 管道中。每次数据变更或管道更新时自动运行质量检查。当质量检查失败时自动阻止数据流向下游。

五、合规与安全（Compliance & Security）

GDPR、个人信息保护法等法规要求企业做好数据治理。核心要求包括：
- 数据分类分级：将数据分为公开、内部、敏感、高度敏感四个级别。不同类型的数据有不同的保护策略。
- 访问控制：谁可以访问哪些数据？基于角色的访问控制（RBAC）是基础，属性基访问控制（ABAC）提供更精细的管控。
- 审计日志：谁在什么时间访问了什么数据？这个信息要记录并保留足够长的时间。
- 数据脱敏：在非生产环境或分析环境中对敏感信息（手机号、身份证号、邮箱）进行掩码处理。

关键原则：数据发现先于数据控制——不知道有什么数据就谈不上保护。因此实施顺序应该是：先建立数据目录和血缘，再实施访问控制和审计。

六、数据分类分级实战

数据分类分级是数据安全的基础。将数据资产按敏感度分级，不同级别采取不同的保护措施。

常见的数据分级模型（L1-L4）：

L1 - 公开数据：公司简介、产品说明、宣传材料。保护措施：无特殊要求，可以对外公开。

L2 - 内部数据：内部文档、组织架构、项目计划。保护措施：需要身份认证，禁止对外分享。

L3 - 敏感数据：员工薪资、财务数据、业务 KPI。保护措施：加密存储、细粒度访问控制、操作日志。

L4 - 高度敏感数据：用户身份证号、银行卡号、医疗记录。保护措施：加密存储、严格授权、数据脱敏展示、定期审计。

实施建议：
1. 数据自动分类：用正则表达式或 ML 模型自动识别敏感数据（手机号、身份证号格式）
2. 数据打标签：在元数据系统中为每个字段打上敏感度级别标签
3. 自动执行策略：基于标签自动应用加密、脱敏、访问控制策略

七、元数据的自动采集与维护

好的元数据管理不是一次性的项目，而是持续的过程。

自动采集的范围：
1. 表结构信息：字段名、类型、注释、约束——从数据库系统表中自动拉取
2. 表间关系：主外键关系、血缘关系——从 SQL 解析中提取
3. 数据统计信息：行数、大小、更新频率、空值率——定期扫描计算
4. 使用信息：谁查了哪些表、查询频率、最常用的字段——从查询日志中分析

手动维护的内容：
1. 业务定义：字段的准确业务含义——"这个字段是注册时间还是最后登录时间？"
2. 计算口径：指标的完整计算公式——"GMV 包含退货订单吗？"
3. 数据质量规则：期望的非空率、唯一性、值域

让元数据维护成为日常开发的一部分——在代码审查中要求新增字段必须填写注释和业务含义。

八、合规框架的实际操作

GDPR 等数据保护法规对数据处理提出了严格要求。实际操作中需要关注：

1. 数据映射（Data Mapping）：记录组织处理的所有个人数据的类型、来源、用途、存储位置、保留期限。
2. 同意管理（Consent Management）：记录用户是否同意处理其数据、同意范围、同意时间。
3. 数据主体权利响应（DSR）：建立流程响应用户的数据访问、更正、删除、导出请求。
4. 数据保留与删除（Retention & Deletion）：设定数据保留期限，到期后自动清理。
5. 数据泄露响应（Breach Response）：发现泄露后在规定时间内通知监管机构和受影响用户。
6. 供应商管理（Vendor Management）：如果使用第三方数据处理服务，确保供应商也符合合规要求。

合规不是一次性的项目——需要建立持续合规的运营机制。

九、数据质量监控的工程实践

将数据质量监控嵌入数据管道，实现自动化质量保障：

1. 管道入口质量门禁：数据进入管道时进行基础质量检查——字段是否存在、类型是否正确、非空约束。质量不合格的数据进入死信队列，不污染下游

2. 管道内部逐级验证：每个转换步骤的输出都进行质量检查。不只是检查最后的输出——尽早发现质量问题是降低修复成本的关键

3. 出口质量报告：数据交付给下游时附带质量报告——行数、空值率、异常率——让下游用户了解数据质量状况

4. 时间序列质量监控：对质量指标做时间序列分析——今天的空值率和上周同一天比怎么样？不是单纯看绝对值，而是看趋势

推荐使用的工具有 Great Expectations（最流行）、dbt test（与 dbt 集成）、Soda Core（开源轻量）、Deequ（AWS 开源，基于 Spark）。

十、数据契约：数据生产者和消费者之间的协议

数据契约（Data Contract）是一个新兴的数据治理概念。它定义了数据生产者和消费者之间的明确协议——包含什么数据、什么格式、什么质量、什么频率。

一个数据契约的典型内容：
- Schema：字段名、数据类型、是否为空
- 语义：每个字段的业务含义
- 质量 SLA：非空率 ≥ 99%、唯一性 100%、更新频率每小时一次
- 联系人：生产者团队、消费者团队
- 变更通知：Schema 变更需要提前通知消费者

数据契约的核心价值在于让数据生产者对自己的数据输出负责——不再是"我把数据扔出去就不管了"。当质量不达标时，消费者可以依据契约要求生产者修复。

十一、数据治理的组织推动

技术工具只是数据治理的一部分——组织推动和文化建设同样关键。

自上而下的支持：数据治理需要管理层的明确支持和资源投入。没有高层的推动，数据治理项目往往会在各部门的“优先级冲突”中被搁置。

自下而上的动力：让数据团队切身感受到数据治理带来的好处——找数据更快了、数据质量更高了、出问题了更容易排查了。让使用者成为数据治理的推动者。

渐进式实施：不要试图一次性建立完美的数据治理体系。选择 1-2 个痛点最突出的领域开始——比如先做好数据目录和血缘。有了成功经验后再扩展到数据质量和安全合规。

数据治理委员会：建立跨部门的数据治理委员会，定期开会讨论数据标准、冲突解决、优先级和进展。委员会的成员包括数据工程师、数据分析师、业务代表和数据安全官。

衡量和展示价值：数据治理的效果需要量化——数据发现的平均时间从多少降到了多少？数据质量问题导致的事故减少了多少？合规检查的准备时间从几周缩到了几天？有了这些量化指标，才能持续获得投入支持。

十二、数据质量监控的自动化实践

数据质量监控不能只靠人工抽查，必须实现自动化。以下是构建自动化数据质量体系的关键要素：

期望管理：Great Expectations 的核心概念是 Expectation——对数据的断言。例如「column A 的值不为空」「column B 的值在 0-100 之间」「table 的记录数在 1000-5000 之间」。每个 Expectation 都有明确的通过/失败标准。

自动化运行：将数据质量检查集成到数据管道中——在每个 ETL 任务完成后自动运行质量检查。如果检查失败，根据严重级别决定是否阻断下游流程。dbt 的 test 功能和 Great Expectations 的 checkpoint 机制都支持这种集成。

数据质量仪表盘：创建可视化的数据质量仪表盘，展示各数据集的健康状态。使用红黄绿灯标——红色代表最近一次检查失败、黄色代表检查通过但指标在恶化趋势中、绿色代表健康。仪表盘应面向业务用户而非技术用户。

质量回溯：当发现数据质量问题时，能够快速追溯——这个问题是从什么时候开始的？受影响的报表有哪些？哪些用户已经被影响？数据血缘是实现质量回溯的基础设施。

根因分析：自动化收集质量问题的上下文信息——失败的数据样本、失败时刻的系统状态、最近的变更记录。这些信息可以大幅缩短根因分析的时间。

持续改进：每个季度回顾数据质量检查的有效性——哪些检查发现了真实问题？哪些检查从未失败过可以考虑移除？是否有新的质量问题类型需要添加检查？

延伸阅读

• 📺 B 站播放列表：Data Engineering — 数据工程基础
• 📚 更多学习资源，请访问 deeplearning.ai 官网