2. Azure数据治理生态概览
Azure 的数据治理并不是某一个服务的功能，而是一组服务围绕“元数据”和“数据质量”两条主线协同工作的结果。理解这套生态，关键是先分清每个服务在治理链路中扮演的角色：谁负责采集元数据、谁负责存储原始数据、谁负责计算与转换、谁负责把元数据变成可搜索、可追溯、可管控的资产目录。本节围绕 Microsoft Purview、Azure Data Catalog、Azure SQL、Azure Synapse Analytics、Azure Data Lake Storage 五个核心服务展开，说明它们在数据质量与元数据治理中的定位与协作方式。
一、五个核心服务的角色定位
Azure Data Lake Storage（ADLS Gen2）是治理链路的“数据底座”。它以分层命名空间组织文件，通常按 raw/、curated/、refined/ 等区域划分数据成熟度。治理视角下，ADLS 的价值不只是存储，而是它承载了数据的物理路径、文件格式、分区结构和访问控制（ACL、RBAC）。这些信息本身就是元数据的重要来源，也是数据质量检查的落点——例如空文件、分区缺失、文件大小异常，往往先在存储层暴露。
Azure SQL是“结构化数据与业务规则的载体”。它提供表、视图、约束、主外键、存储过程等强结构元数据，同时通过约束、触发器和查询逻辑承载大量数据质量规则。在治理中，Azure SQL 既是元数据的重要来源（表结构、列类型、注释），也是质量校验的执行点（唯一性、非空、引用完整性）。
Azure Synapse Analytics是“计算与转换中枢”。它把 SQL 池、Spark 池、数据集成管道整合在一起，负责把 ADLS 中的原始数据加工成可分析的数据集。治理视角下，Synapse 是元数据变化最频繁的地方：每一次管道运行、每一次 Spark 作业，都会产生新的表、新的分区、新的血缘关系。因此 Synapse 与 Purview 的集成尤为关键，它让“数据从哪来、经过什么处理、变成什么”可以被自动记录。
Microsoft Purview是“治理控制平面”。它不存储业务数据，而是通过扫描、分类、血缘采集，把分散在各服务中的元数据汇聚成统一的数据地图（Data Map），再通过数据目录、敏感信息分类、血缘视图对外提供服务。Purview 是当前 Azure 治理体系的核心，也是替代早期 Azure Data Catalog 的主力服务。
Azure Data Catalog是“早期元数据目录服务”。它主要提供数据源的注册、发现和标注能力，但缺乏自动扫描、血缘和敏感数据分类能力。在新架构中，它通常被视为 Purview 的前身，仅在存量环境中出现。理解它的定位，有助于判断迁移到 Purview 的必要性。
二、协作关系：从数据落地到可治理资产
这五个服务不是并列关系，而是一条“数据流 + 元数据流”双线并行的协作链。数据流从 ADLS 出发，经 Synapse 加工，落到 Azure SQL 或分析层；元数据流则由 Purview 扫描各服务，形成数据地图与血缘。两条线通过“扫描—分类—血缘—目录”四个动作耦合在一起。
图中上半部分是数据流：ADLS 存放原始与加工数据，Synapse 读取并转换，结果写入 Azure SQL 或分析层。下半部分是元数据流：Purview 分别扫描 ADLS、Synapse、Azure SQL，把路径、表结构、血缘、敏感信息汇聚到数据地图。两条流在“数据质量校验”处交汇——质量规则既作用于数据本身，也作为元数据被记录和追踪。
三、实际协作中的关键动作
要让这套生态真正运转，需要落实几个具体动作。第一，在 ADLS 上按数据成熟度划分容器或目录，并保持命名规范，例如 raw/sales/2024/06/，这样 Purview 扫描后能自动形成可读的资产路径。第二，在 Synapse 中把管道和 Spark 作业的输入输出显式声明，Purview 才能采集到完整血缘；如果转换逻辑写在动态 SQL 或未注册的脚本里，血缘就会断裂。第三，在 Azure SQL 中用约束和注释承载质量规则，例如对订单号列加唯一约束、对金额列加检查约束，这些约束会被 Purview 扫描为资产属性。第四，在 Purview 中配置扫描规则集，对包含手机号、身份证号等模式的列自动打敏感标签，并设置定期扫描计划。
四、一个可参考的治理配置示例
假设某零售企业要把订单数据纳入治理，可采用如下配置作为起点（参数为示例，需按实际环境调整）：
| 服务 | 治理动作 | 示例参数 | 观察结果 |
|---|---|---|---|
| ADLS Gen2 | 划分 raw/curated 区域，启用分层命名空间 | 容器 orders，路径 raw/orders/yyyy/mm/dd | Purview 扫描后出现按日期分区的文件资产 |
| Synapse | 管道声明输入输出，Spark 作业注册到工作区 | 每日 02:00 触发，读取 raw，写入 curated | 血缘图中显示 raw→curated 的转换链路 |
| Azure SQL | 对订单表加主键、唯一约束、检查约束 | OrderId 唯一，Amount >= 0 | 约束作为资产属性被扫描，质量规则可追溯 |
| Purview | 配置扫描规则集与敏感分类 | 每周扫描一次，识别手机号、地址模式 | 数据地图中出现敏感标签与资产负责人 |
这套配置的价值在于：数据从进入 ADLS 到被分析使用，每一步都有元数据记录，质量规则有明确落点，敏感数据有分类标签。当出现“报表金额异常”时，可以沿血缘回溯到 Synapse 的转换逻辑，再检查 Azure SQL 的约束是否被绕过，最后确认 ADLS 原始文件是否完整——这就是治理生态协作带来的可追溯能力。
五、常见误区与判断依据
实践中容易把 Purview 当成“装完就治理好了”的工具，实际上 Purview 只提供能力，治理效果取决于扫描覆盖度、血缘完整性和规则落地情况。判断治理是否有效，可以看三个信号：数据地图中核心资产是否都有负责人和分类标签；关键数据流的血缘是否连续、无断点；质量规则是否在数据落地或转换环节真实执行，而不是只写在文档里。Azure Data Catalog 在存量环境中仍可能被使用，但若需要自动扫描、血缘和敏感分类，应规划迁移到 Purview，而不是继续在旧目录上叠加手工维护。