1. 课程导入与全景认知
在 Azure 数据平台上，数据质量与元数据治理并不是两个可以分开推进的“附加项”，而是同一套数据可信体系的左右手。数据质量回答的是“这份数据能不能用、准不准、全不全、是否及时”；元数据治理回答的是“这份数据是什么、从哪来、谁负责、被谁用过、口径是否一致”。前者关注数据内容本身的可信度，后者关注数据资产的可发现、可理解、可追溯与可问责。缺少元数据，质量问题往往只能靠人工猜测定位；缺少质量校验，元数据描述得再完整也无法保证下游分析结论可靠。
从业务价值看，这两项能力直接决定数据平台能否从“能存能算”走向“可被信任地决策”。一个典型场景是：财务部门发现某张 Power BI 报表的月度收入比上月骤降 18%，如果平台没有元数据血缘，分析师需要逐层翻查 ADF 管道、Databricks Notebook 和 Synapse 视图；如果平台同时具备质量规则与血缘信息，就能快速定位到上游 CRM 客户主数据中“客户状态”字段在 3 月 15 日被批量置为“失效”，从而判断是业务口径变化还是数据异常。可见，元数据治理提供“地图”，数据质量提供“仪表盘”，二者结合才能把排障时间从数小时压缩到数分钟。
在 Azure 数据平台中，这两项能力有明确的落点。数据质量通常依托 Azure Data Factory 或 Synapse Pipeline 在数据流转关键节点插入校验活动，也可通过 Databricks 的 Great Expectations、dbt tests 或 Delta Live Tables 期望规则实现；校验结果可写入 Azure SQL Database、Log Analytics 或 Microsoft Purview 的定制属性。元数据治理则以 Microsoft Purview 为核心，自动扫描 Azure SQL、Synapse、ADLS Gen2、Databricks 等数据源，采集技术元数据、业务术语、分类标签和血缘关系。Purview 的数据资产、术语表、分类规则与血缘图谱，正好为质量规则提供“作用对象”和“责任归属”。
上图展示了本课程的核心逻辑：数据源经过 Purview 扫描形成元数据资产，元数据为质量规则提供作用对象与责任归属；质量校验在数据流入消费层之前设置门禁，消费端的问题又反向驱动规则迭代。这个闭环不是一次性项目，而是持续运营的治理机制。
为了后续 29 章能够顺利动手实践，建议先准备好实战环境。以下是一份可直接参照的环境准备清单，所有资源均可在 Azure 门户中创建，示例命名仅作参考，实际使用时请替换为全局唯一名称。
| 资源类型 | 示例名称 | 用途 | 关键配置 |
|---|---|---|---|
| 资源组 | rg-dq-governance-dev | 统一管理本课程所有资源 | 区域建议选 East US 2 或 Southeast Asia |
| Azure SQL Database | sql-dq-demo | 模拟业务源库与质量结果存储 | 基本层，启用公有访问，防火墙放行客户端 IP |
| ADLS Gen2 | stdqdemo001 | 存放原始文件与质量报告 | 启用分层命名空间，创建 raw/ 与 quality/ 容器 |
| Azure Data Factory | adf-dq-demo | 编排数据流与质量校验活动 | 托管标识开启，授予 ADLS 与 SQL 相应权限 |
| Microsoft Purview | pv-dq-demo | 元数据扫描、血缘与术语表 | 标准版，配置托管标识并注册上述数据源 |
| Log Analytics | law-dq-demo | 集中存储质量告警与审计日志 | 按需付费，保留 30 天 |
环境就绪后，建议用一条最小链路验证连通性：在 Azure SQL 中创建 dbo.Customer 表，插入 5 条示例数据，其中 1 条 Email 为空、1 条 CustomerID 重复；在 ADF 中建立到该库的 Linked Service，使用“Lookup”活动执行 SELECT COUNT(*) FROM dbo.Customer WHERE Email IS NULL，预期返回 1。若返回值正确，说明数据源、ADF 与权限链路已打通，后续章节即可在此基础上逐步叠加 Purview 扫描、质量规则和告警配置。