1. 课程导入与全景认知

在开始学习任何一项数据治理技术之前，先要回答三个问题：我们治理的到底是什么？它为什么值得投入？在 AWS 上，谁该为哪一部分负责？本章不急于进入具体工具，而是先建立一张"全景地图"，让后续 29 章的技术细节都能挂靠在这张地图上。

一、数据质量与元数据治理分别是什么

数据质量（Data Quality）关注的是数据"能不能用、好不好用"。它通常被拆解为若干可度量的维度：完整性（该有的字段是否为空）、唯一性（主键是否重复）、一致性（同一事实在不同表中是否矛盾）、准确性（是否与真实世界相符）、及时性（数据是否在业务需要的时间窗口内到达）、有效性（是否符合格式与取值域约束）。这些维度不是抽象口号，而是可以写成规则、跑出通过率、触发告警的工程对象。

元数据治理（Metadata Governance）关注的是"数据是什么、从哪来、谁负责、被谁用"。元数据分三类：技术元数据（表结构、字段类型、分区、存储位置、血缘）、业务元数据（业务定义、指标口径、负责人、SLA）、运营元数据（作业运行时长、扫描行数、失败次数、成本）。治理的核心动作是：把这些信息采集起来、统一登记、建立血缘、明确归属，并让它们随数据变化而持续更新。

两者不是并列关系，而是互相支撑：数据质量规则需要元数据来定位"该检查哪张表、哪个字段、按什么口径"；元数据治理又需要质量结果来回答"这份数据现在可信吗"。因此本课程把它们放在同一条主线上。

二、业务价值：从"救火"到"可承诺"

数据质量问题最常见的表现不是系统崩溃，而是"报表数字对不上"。业务方发现 GMV 环比异常，分析师花两天排查，最后定位到上游一张订单表某天分区缺失。这类问题的成本往往被低估：一次口径争议可能消耗数人日，一次错误决策可能带来真实资金损失。

元数据治理的价值则体现在"可发现、可理解、可追责"。当新同事需要接入一张表时，如果能看到字段业务定义、上游血缘、负责人和最近一次质量检查结果，接入时间可以从数天缩短到数小时。当指标口径发生变更时，血缘图能直接告诉你会影响哪些下游报表和模型。

把两者合起来看，治理的终局是让数据从"能用但不敢信"变成"可承诺"——即可以对业务方明确承诺：这份数据在什么时间范围内、以什么质量水平、由谁负责交付。

三、AWS 上的责任共担模型

AWS 的责任共担模型（Shared Responsibility Model）通常用于安全领域，但同样适用于数据治理，只是边界需要重新划分。AWS 负责"云本身"的可靠性：S3 的持久性、Glue 作业运行的基础设施、Lake Formation 的权限引擎、CloudWatch 的日志采集能力。客户负责"云中的内容"：数据是否被正确分类、质量规则是否合理、元数据是否准确、访问权限是否符合最小化原则。

一个容易踩的坑是：把"用了托管服务"等同于"治理已经完成"。例如启用了 Glue Data Catalog，并不代表元数据就是准确的——如果爬虫没有覆盖新分区，或者业务定义从未登记，Catalog 里依然是一堆无意义的字段名。AWS 提供的是能力与工具，治理策略和规则必须由数据团队自己定义并持续运营。

四、本课程围绕的真实数据资产场景

为了让所有章节有统一的落点，本课程设定一个贯穿始终的示例场景：某电商平台在 AWS 上构建数据湖，原始数据以 JSON 和 CSV 形式落在 S3 的 raw 层，经 Glue 作业清洗后写入 curated 层，再由 Athena 和 Redshift 供报表与风控使用。核心资产包括订单表、用户表、商品表、支付流水表，关键指标包括 GMV、支付成功率、退款率。

这个场景中会出现典型问题：订单表某天分区为空、用户表手机号格式不统一、支付流水与订单金额不一致、指标口径在多个报表中定义不同。后续章节将围绕这些问题，逐一展开规则设计、血缘构建、质量监控、告警与复盘。

五、贯穿场景中的典型问题与治理切入点

回到示例场景，我们可以把常见问题归为四类，并对应到不同的治理切入点：

• 数据缺失类：订单表某天分区为空。切入点是在 Glue 作业后增加分区存在性与行数下限检查，并接入告警。
• 格式不一致类：用户表手机号有的带国家码、有的不带。切入点是在 curated 层写入前做标准化，并在元数据中登记字段格式约束。
• 跨表矛盾类：支付流水金额之和与订单金额不一致。切入点是用血缘定位关联字段，建立跨表一致性规则。
• 口径分歧类：GMV 在不同报表中定义不同。切入点是在业务元数据中登记唯一口径，并标注下游影响范围。

这四类问题分别对应后续章节中的质量规则设计、标准化处理、血缘分析与指标治理。读者在学习时，可以始终把具体技术动作映射回这张全景图，避免陷入"只会用工具、不知道为何而用"的状态。