4. Azure 数据目录与业务术语表
在数据治理体系中，数据目录不是一份静态的资产清单，而是把“技术元数据、业务语义、责任归属”三者绑定在一起的动态索引。Azure 环境中，数据分散在 Azure SQL Database、Azure Data Lake Storage Gen2、Azure Synapse Analytics、Microsoft Fabric、Power BI 以及第三方系统里，如果没有统一目录，业务人员找不到数据、数据工程师不知道字段含义、合规人员无法追溯敏感数据流向，治理就无从落地。本节围绕三个核心动作展开：建立可检索的数据目录、用业务术语表统一语义、为每项数据资产指定所有者与元数据。
一、数据目录的组成与元数据分层
企业数据目录通常由三类元数据构成。技术元数据描述物理结构，例如服务器名、数据库名、表名、列名、数据类型、分区键、存储路径；业务元数据描述语义，例如业务定义、计算口径、所属业务域、更新频率、数据质量规则；运营元数据描述使用与责任，例如所有者、数据管理员、访问申请入口、最近刷新时间、血缘来源。Microsoft Purview 是 Azure 原生的治理平台，其数据映射（Data Map）负责扫描和存储技术元数据，统一目录（Unified Catalog）负责检索与浏览，业务术语表（Business Glossary）负责承载业务元数据，而所有者、专家、管理员的分配则把运营元数据落到具体人员或团队。
一个可用的目录必须做到“扫得到、看得懂、找得到人”。扫描解决覆盖度，术语表解决语义一致性，所有者分配解决问责闭环。三者缺一，目录就会退化为一张无人维护的表清单。
二、业务术语表的定义方法
业务术语表的核心价值是消除“同名不同义、同义不同名”。例如“活跃客户”在销售部门指 90 天内有订单的客户，在财务部门指 12 个月内有回款的客户，如果目录里只写一个字段名 active_customer_flag，两个部门会各自理解，报表口径必然冲突。建立术语表时，每个术语至少应包含：术语名称、标准定义、计算口径或判定规则、同义词、所属业务域、关联的数据资产、术语所有者、生效日期与版本。
以“活跃客户”为例，可以定义如下：术语名称为“活跃客户”，标准定义为“在统计周期内存在有效交易或回款的客户”，计算口径为“最近 90 天内至少有一笔状态为已完成的订单”，同义词包括“活跃买家”“有效客户”，所属业务域为“客户域”，关联资产为 gold.dim_customer 与 gold.fact_order，术语所有者为客户运营负责人。这样业务人员搜索“活跃客户”时，既能读到定义，也能直接跳转到对应表，还能看到谁负责解释口径。
术语表不是一次性文档，而是需要版本管理的活资产。建议为每个术语记录变更历史，当口径调整时，同步更新关联资产说明，并通知下游报表负责人。术语的审批可以走轻量流程：业务域负责人提出，数据治理委员会确认，Purview 管理员发布。
三、数据资产元数据与所有者管理
在 Purview 中，每个被扫描到的资产都可以补充业务描述、分配分类、设置敏感度标签，并指定联系人。联系人分为三类：所有者（Owner）对资产内容和质量负最终责任；专家（Expert）负责解答口径与技术问题；管理员（Steward）负责日常维护、权限审批和元数据更新。对于关键资产，例如客户主数据、订单事实表、财务汇总表，必须至少指定一名所有者和一名管理员。
实际操作中，可以先按业务域划分资产集合（Collection），例如“客户域”“交易域”“财务域”“供应链域”，再把域内资产的所有者绑定到对应团队。Purview 的集合支持继承权限，子集合默认继承父集合的角色分配，这样可以减少重复配置。扫描范围建议按数据源类型分批推进：先扫描 Azure SQL 与 ADLS Gen2 中的核心库表，再扫描 Synapse 与 Fabric 的湖仓对象，最后补充 Power BI 语义模型和报表，避免一次性全量扫描导致分类噪声过多。
| 业务域 | 数据资产 | 关联术语 | 所有者 | 管理员 | 敏感度 |
|---|---|---|---|---|---|
| 客户域 | gold.dim_customer | 活跃客户、客户等级 | 客户运营负责人 | 客户数据管理员 | 高（含 PII） |
| 交易域 | gold.fact_order | 有效订单、订单金额 | 交易平台负责人 | 交易数据管理员 | 中 |
| 财务域 | finance.mart_revenue | 确认收入、回款率 | 财务分析负责人 | 财务数据管理员 | 高 |
| 供应链域 | supply.dim_product | 在售商品、SKU | 供应链负责人 | 供应链数据管理员 | 低 |
四、落地检查与常见问题
目录建设完成后，可以用四个问题检验是否可用：第一，业务人员能否用自然语言术语搜到对应资产；第二，每个核心资产是否有明确所有者和管理员；第三，敏感字段是否已打分类标签并能追溯血缘；第四，术语口径变更后，关联资产说明是否同步更新。如果其中任一答案为否，说明目录仍停留在“扫描完成”阶段，尚未形成治理闭环。
常见问题包括：扫描账号权限不足导致部分库表缺失；术语表只建不用，业务人员仍靠口头确认口径；所有者分配给了离职人员或共享邮箱，导致审批停滞；分类规则过于宽泛，把普通字段误标为敏感数据，增加不必要的审批负担。解决思路是：为扫描账号配置最小必要读取权限并定期复核；把术语表嵌入报表开发流程，要求新报表必须引用标准术语；所有者必须绑定到岗位而非个人；分类规则先小范围试点，确认准确率后再扩大范围。
总结来说，Azure 数据目录的建设路径是：先扫描形成技术元数据底座，再用业务术语表统一语义，最后通过所有者和管理员分配把责任落到人。三者结合，目录才能从“能看”变成“能用”，成为企业数据治理的可信入口。