Microsoft Purview（以前称为 Azure Purview）部署最佳做法
本文指导你如何在数据资产中成功地将 Microsoft Purview（以前称为 Azure Purview）部署到生产。 它旨在帮助你制定部署策略并对部署划分阶段（从研究到强化生产环境），并最好将其与我们的部署清单结合使用。
注意
这些最佳做法涵盖了 Microsoft Purview 统一治理解决方案的部署。 有关 Microsoft Purview 的更多信息，请转到此处。
如果要查找严格的技术部署指南，请使用部署清单。
如果要创建部署 Microsoft Purview 的计划，并想要在制定部署策略时采用最佳做法，请遵循以下文章。 本指南概述的任务可在一个月或更多时间内分阶段完成，用于开发 Microsoft Purview 的部署流程。 即使已部署 Microsoft Purview 的组织也可以使用本指南来确保从投资中获得最大的收益。
一个规划良好的治理平台部署有以下优势：
- 增强数据发现
- 改进分析协作
- 投资回报率最大化
本指南介绍从初始规划到成熟环境的完整部署生命周期，包括以下阶段：
| 阶段 | 说明 |
|---|---|
| 明确目标和目的 | 考虑整个组织需要从数据治理获得什么。 |
| 问题 | 你和团队开始时可能遭遇哪些问题，可以从哪里着手解决这些问题？ |
| 创建迁移到生产环境的流程 | 创建满足组织所需的分阶段部署策略。 |
| 平台强化 | 继续进行部署进入成熟阶段。 |
许多 Microsoft Purview 应用程序和功能都有属于自己的最佳做法页面。 本部署指南经常引用它们，但也可在“概念”下目录的“最佳做法和指南”中找到所有这些内容。
明确目标和目的
许多组织通过开发单独的解决方案来满足组织中各个独立的组和数据域的特定要求，开始了其数据管理旅程。 尽管体验可能因行业、产品和文化而异，但大多数组织都发现很难对这些类型的解决方案维持一致的控制和策略。
需要在早期明确一些常见数据管理目标来实现全面的数据管理体验，它们包括：
- 最大程度地提高数据的商业价值
- 实现数据文化，使数据使用者能够轻松查找、解读和信任数据
- 改进不同业务部门之间的协作，以提供一致的数据体验
- 通过加快数据分析促进创新，以利用云的优势
- 通过各种技能组的自助服务选项，缩短发现数据所需的时间
- 缩短向客户提供改善服务的分析解决方案所需的面市时间
- 降低使用特定于域的工具和不受支持的技术带来的操作风险
常见的方法是将这些首要目标分解为不同的类别和目的。 下面是一些示例：
| 类别 | 目标 |
|---|---|
| 发现 | 管理员用户应能够扫描 Azure 和非 Azure 数据源（包括本地源），以便自动收集有关数据资产的信息。 |
| 分类 | 平台应基于数据采样自动对数据进行分类，并允许使用自定义分类进行手动重写。 |
| 消耗 | 商务用户应该能够查找每个资产的相关信息，以获得业务和技术元数据。 |
| 沿袭 | 每个资产都必须显示基础数据集的图形视图，以便用户了解原始源和所做的更改。 |
| 协作 | 平台必须提供有关每个数据资产的其他信息以允许用户进行协作。 |
| 报告 | 用户必须能够查看有关数据资产的报告，其中包括需要敏感数据和需要额外扩充的数据。 |
| 数据治理 | 平台必须允许管理员定义访问控制策略，并根据每个用户自动实施数据访问权限。 |
| 工作流 | 平台必须能够创建和修改工作流，以便可以轻松扩展平台中的各种任务并能够将其自动化。 |
| 集成 | 其他第三方技术（例如票务或业务流程）必须能够通过脚本或 REST API 集成到平台。 |
确定关键方案
Microsoft Purview 治理服务可用于集中管理跨云和本地环境的组织数据资产的数据管理。 若要成功实现，必须确定对于企业至关重要的关键方案。 这些方案可能影响不同业务部门，也可能影响上游或下游的多个用户角色。
可以通过多种方式编写这些方案，但至少应包含以下五个维度：
- 角色 – 用户是谁？
- 源系统 – 数据源是什么（例如 Azure Data Lake Storage Gen2 或 Azure SQL 数据库）？
- 影响范围 – 此方案属于哪个类别？
- 详细方案 – 用户如何使用 Microsoft Purview 解决问题？
- 预期结果 – 成功的标准是什么？
这些方案必须具体、可操作和可执行，并且产生的结果可度量。 一些可用的方案包括：
| 方案 | 详细信息 | 角色 |
|---|---|---|
| 目录中的业务关键型资产 | 我需要获取每个数据集的相关信息，以便了解每个数据集。 此方案包括目录中数据集的业务和技术元数据数据。 数据源包括 Azure Data Lake Storage Gen2、Azure Synapse DW 和/或 Power BI。 此方案还包括本地资源。 | 业务分析师、数据科学家、数据工程师 |
| 发现业务关键型资产 | 我需要有一个搜索引擎，以便可以在目录内的所有元数据中进行搜索。 我应该能够使用技术术语、业务术语以及包含通配符的简单或复杂搜索进行搜索。 | 业务分析师、数据科学家、数据工程师、数据管理员 |
| 跟踪数据以了解其来源并排除数据问题 | 我需要数据世系来追溯报告、预测或模型中数据的原始源头。 我还需要了解对数据所做的更改，以及数据在整个数据生命周期中驻留的位置。 此方案需要支持数据管道 Azure 数据工厂和 Databricks 并将它们设置为具有最高优先级。 | 数据工程、数据科学家 |
| 扩充关键数据资产的元数据 | 我需要用自动生成的技术元数据来扩充目录中的数据集。 例如，分类和标签。 | 数据工程师、域所有者/企业主 |
| 通过友好的用户体验管理数据资产 | 我需要获取业务术语表，以获取特定于业务的元数据。 商务用户可以使用 Microsoft Purview 实现自助服务方案，以便为数据添加注释，并能够通过搜索轻松发现数据。 | 域所有者/企业主、业务分析师、数据科学家、数据工程师 |
与 Microsoft Purview 集成的集成点
成熟的组织很有可能已具有现有的数据目录。 关键问题是：是否继续使用现有技术，以及是否与 Microsoft Purview 数据映射和数据目录同步。 Microsoft Purview 提供 Atlas REST API，用于处理与组织中现有产品的同步。 Atlas API 提供了一种功能强大且灵活的机制来处理推送和拉取方案。 通过 Atlas API，可以将信息发布到 Microsoft Purview 以便于启动，也可以将另一个系统中的最新更新推送到 Microsoft Purview。 也可以通过 Atlas API 读取 Microsoft Purview 中提供的信息，然后将该信息同步回现有产品。
可以使用 Atlas API 和 Kafka 终结点实现其他集成方案，例如票务、自定义用户界面和业务流程。 通常情况下，Microsoft Purview 有四个集成点：
- 数据资产 - Microsoft Purview 可以通过它扫描存储的资产，进而枚举这些资产并收集这些资产的所有立即可用的元数据。 因此，对于 SQL，它可能会列出数据库、表、存储过程、视图以及这些内容的配置数据（保存在
sys.tables之类的位置中）。 对于 Azure 数据工厂 (ADF) 之类的内容，它可能会枚举所有管道并获取关于这些项的创建时间、上次运行时间和当前状态的数据。 - 世系 – Microsoft Purview 可以通过它从分析/数据变更系统收集关于数据变动方式的信息。 对于 Spark 之类的内容，它可能会通过笔记本的执行过程收集信息，以了解笔记本引入的数据、该数据的转换方式及其输出位置。 对于 SQL 之类的内容，它可能会分析查询日志，以通过反向工程了解执行的变更操作和这些操作的具体行为。 我们根据需要支持基于推送和基于拉取的沿袭。
- 分类 – Microsoft Purview 可以通过它从数据源采集物理样本，然后在整个分类系统中运行这些样本。 分类系统会推算出一条数据的语义。 例如，我们可能知道，某个文件是 Parquet 文件，包含三列并且第三列是字符串。 但对样本运行的分类器会显示该字符串是名称、地址或电话号码。 启动此集成点意味着，我们定义了 Microsoft Purview 打开对象（如笔记本、管道、parquet 文件、表和容器）的方式。
- 嵌入式体验 - 具有“工作室”式体验的产品（如 ADF、Synapse、SQL Studio、PBI 和 Dynamics）通常想要让用户能够发现其想要与之交互的数据，并且希望用户能够找到输出数据的位置。 Microsoft Purview 目录可以通过提供嵌入式体验帮助加快这些体验。 此体验可以在 API 或 UX 级别完成，具体取决于合作伙伴的选择。 通过嵌入对 Microsoft Purview 的调用，组织可以利用 Microsoft Purview 的数据资产图找到数据资产、浏览沿袭、查看架构、了解评级以及联系人等。
收集问题
组织认可这些高级目标和目的后，多个群体会提出大量问题。 务必要收集这些问题，以便制定计划来解决所有的疑惑。 确保在收集这些问题时包括相关组。 可以使用我们的文档开始作答。
在初始阶段可能会遇到以下问题：
- 组织的主要数据源和数据系统是什么？
- 哪些数据源受支持？
- 如果 Microsoft Purview 尚不支持数据源，可以选择哪些选项？
- 应如何为 Microsoft Purview 制定预算？
- 谁会使用 Microsoft Purview？他们的角色是什么？
- 谁可以扫描新的数据源？
- 谁可以修改 Microsoft Purview 中的内容？
- 可以在 Microsoft Purview 中利用哪些流程来提高数据质量？
- 如何在平台上启动现有关键资产、术语表术语和联系人？
- 如何保护 Microsoft Purview？
- 如何收集反馈并构建可持续的流程？
- 如果发生灾难，可以做什么？
即使你可能无法立刻回答大多数问题，但收集信息有助于组织制定此项目的框架，并确保满足所有必备要求。
让合适的利益干系人参与
要确保在整个组织成功实施 Microsoft Purview，务必要让合适的利益干系人参与。 初始阶段只涉及几个人。 但是，随着范围的扩大，你需要更多角色来参与项目并提供反馈。
一些需要参与的关键利益干系人包括：
| 角色 | 角色 |
|---|---|
| 首席数据官 | CDO 监督一系列的职能，其中可能包括数据管理、数据质量、主数据管理、数据科学、商业智能和创建数据策略。 首席数据官可以是 Microsoft Purview 实现项目的发起人。 |
| 域所有者/企业主 | 影响工具使用情况并控制预算的企业人员 |
| 数据分析人员 | 能够设计业务问题以及分析数据，以帮助领导者做出业务决策 |
| 数据架构师 | 设计任务关键型业务线应用程序的数据库，以及设计和实现数据安全 |
| 数据工程师 | 操作和维护数据堆栈，从不同源提取数据，集成和准备数据，设置数据管道 |
| 数据科学家 | 生成分析模型并设置要由 API 访问的数据产品 |
| 数据库管理员 | 拥有、跟踪和解决服务级别协议 (SLA) 内与数据库相关的事件和请求；可能会设置数据管道 |
| DevOps | 业务线应用程序开发和实现；可能包括编写脚本和业务流程职能 |
| 数据安全专家 | 评估整体网络和数据安全，这涉及 Microsoft Purview 的传入和传出数据 |
创建迁移到生产环境的流程
下面提供了可能的四阶段部署计划，其中包括每个阶段的任务、有用链接和验收条件：
阶段 1：试点
在此阶段中，必须为少数用户创建和配置 Microsoft Purview。 通常情况下，此群体包含 2-3 人，这些人员将共同完成端到端的方案。 这些人员被视为组织中的 Microsoft Purview 倡导者。 此阶段的主要目标是确保可以实现关键功能，并确保相应的利益干系人了解此项目。
要完成的任务
| 任务 | 详细信息 | 持续时间 |
|---|---|---|
| 收集和认可要求 | 与所有利益干系人讨论，收集所有要求。 各种角色都必须参与，以便于认可项目的每个阶段要完成的一系列要求。 | 一周 |
| 导航 Microsoft Purview 管理门户 | 了解如何在主页中使用 Microsoft Purview。 | 一天 |
| 配置 ADF 以获得沿袭 | 确定关键管道和数据资产。 收集连接到内部 ADF 帐户所需的所有信息。 | 一天 |
| 扫描数据源，如 Azure Data Lake Storage Gen2 | 添加数据源并设置扫描。 确保扫描成功检测到所有资产。 | 两天 |
| 搜索并浏览 | 允许最终用户访问 Microsoft Purview 并执行端到端搜索和浏览方案。 | 一天 |
其他有用链接
验收条件
- Microsoft Purview 帐户已在组织租户下的组织订阅中成功创建。
- 具有多个角色的少数用户可以访问 Microsoft Purview。
- Microsoft Purview 配置为至少扫描一个数据源。
- 用户应该能够获取 Microsoft Purview 的关键值，例如：
- 搜索和浏览
- 沿袭
- 用户应能够在“资产”页中分配资产所有权。
- 用于让关键利益干系人增进了解的演示。
- 完成管理层换购，以便批准更多资源用于 MVP（最小化可行产品）阶段。
阶段 2：最小化可行产品
要载入 Microsoft Purview，认可要求并且有业务部门参与后，下一步就是研发最小化可行产品 (MVP) 版本。 在此阶段，你会将 Microsoft Purview 的使用范围扩大到具有额外的横向和纵向需求的更多用户。 有一些必须为所有用户横向实现的关键方案，例如术语表术语、搜索和浏览。 在纵向也会有更深入的要求，以便每个业务部门或组实现特定端到端的方案，例如从 Azure Data Lake 到 Azure Synapse DW 再到 Power BI 的沿袭。
要完成的任务
| 任务 | 详细信息 | 持续时间 |
|---|---|---|
| 扫描 Azure Synapse Analytics | 开始载入数据库源并进行扫描，以填充关键资产 | 两天 |
| 创建自定义分类和规则 | 扫描资产后，用户可能会发现，除了 Microsoft Purview 中的默认分类之外，还有更多分类的其他用例。 | 2-4 周 |
| 扫描 Power BI | 如果组织使用 Power BI，则可以扫描 Power BI，以便收集要求包含存储层的沿袭的数据科学家或数据分析师所使用的所有数据资产。 | 1-2 周 |
| 导入术语表术语 | 在大多数情况下，组织可能已开发了一套术语表术语和资产术语分配。 这样就需要通过 .csv 文件导入到 Microsoft Purview。 | 一周 |
| 为资产添加联系人 | 对于顶级资产，需要创建一个流程，以便允许其他角色分配联系人，或通过 REST API 导入。 | 一周 |
| 获取分类和敏感见解 | 若要在 Microsoft Purview 中获取报告和见解，你可以访问此功能，以获得各种报告并向管理层展示。 | 一天 |
| 通过 Microsoft Purview 托管用户加入更多用户 | 此步骤需要 Microsoft Purview 管理员与 Microsoft Entra 管理员合作，创建新的安全组以便授予对 Microsoft Purview 的访问权限。 | 一周 |
其他有用链接
验收条件
- 成功将更多的用户（50 个以上）加入到 Microsoft Purview
- 扫描业务关键型数据源
- 导入和分配所有关键术语表术语
- 在关键资产上成功测试重要的标记
- 成功为参与的业务部门用户实现最小方案
阶段 3：预生产
MVP 阶段完成后，接下来要为到达预生产里程碑制定规划。 组织可能会决定为预生产和生产提供单独的 Microsoft Purview 实例，也可能决定保留同一个实例但限制访问权限。 同样，在此阶段，你需要包含对本地数据源的扫描。 如果有 Microsoft Purview 不支持的数据源，可以探索 Atlas API 以了解其他选项。
要完成的任务
| 任务 | 详细信息 | 持续时间 |
|---|---|---|
| 使用扫描规则集优化扫描 | 组织将为预生产环境提供许多数据源。 务必要预先定义关键的扫描条件，以便分类和文件扩展名可以全面一致地应用。 | 1-2 天 |
| 通过检查源页面为每个源评估区域是否可供扫描 | 根据数据源的区域以及组织的合规性和安全性要求，你可能需要考虑哪些区域必须可扫描。 | 一天 |
| 执行扫描时，了解防火墙概念 | 此步骤需要了解组织配置防火墙的方式以及 Microsoft Purview 如何验证自己的身份，以访问要扫描的数据源。 | 一天 |
| 执行扫描时了解专用链接概念 | 如果组织使用专用链接，则必须建立网络安全的基础，以便将专用链接纳入要求中。 | 一天 |
| 使用 Microsoft Purview REST API 实现集成方案 | 如果具有将 Microsoft Purview 与第三方技术（如业务流程或票务系统）集成这样的要求，则可能需要了解 REST API。 | 1-4 周 |
| 了解 Microsoft Purview 定价 | 此步骤为组织提供重要的财务信息，以便于组织作出决策。 | 1-5 天 |
其他有用链接
验收条件
- 已成功加入至少一个业务部门及所有用户
- 扫描本地数据源
- 使用 REST API 完成至少一个集成方案的概念证明
- 完成用于转到生产环境的规划，其中应包括关于基础结构和安全性的关键方面
阶段 4：生产
应遵循上述阶段来创建有效的数据生命周期管理，这是改进治理计划的基础。 数据管理有助于组织为不断发展的 AI、Hadoop 和区块链等区域做准备。 数据和分析只是许多事项的起点，还有更多内容可供探讨。 此解决方案将生成以下结果：
- 以业务为中心 - 解决方案基于技术要求与业务要求和业务方案保持一致。
- 面向未来 - 解决方案最大程度利用平台的默认功能，并使用标准化的行业做法完成配置或脚本活动，以便支持平台改进/演变。
要完成的任务
| 任务 | 详细信息 | 持续时间 |
|---|---|---|
| 已启用了防火墙时扫描生产数据源 | 如果防火墙已运行则此为可选项，但务必要了解增强基础结构的选项。 | 1-5 天 |
| 启用专用链接 | 使用了专用链接时此为可选项。 否则，可以跳过它，因为这是启用专用链接的必要条件。 | 1-5 天 |
| 创建操作文档 | 数据治理不是一次性项目。 这是一项不断发展的计划，有助于做出数据驱动的决策和创建业务机会。 记录关键的过程和业务标准至关重要。 | 一周 |
其他有用链接
验收条件
- 已成功加入所有业务部门及其用户
- 成功达到生产环境的基础结构和安全要求
- 成功实现用户所需的所有用例
平台强化
可以执行其他强化步骤：
- 通过对防火墙资源启用扫描提升安全状况，或使用专用链接
- 优化作用域扫描，以提高扫描性能
- 使用 REST API 导出关键元数据和属性，以执行备份和恢复
生命周期注意事项
要纳入生产流程的另一个重要方面是，如何迁移分类和标签。 Microsoft Purview 包含的系统分类器超过 90 个。 可以对文件、表或列资产应用系统或自定义分类。 分类类似于主题标签，用于标记和标识扫描期间在数据资产中发现的特定类型的内容。 敏感度标签用于标识组织数据中的分类类型类别，以及要应用于每个类别的策略组。 它使用与 Microsoft 365 相同的敏感信息类型，可让你将现有的安全策略和保护延伸到整个内容和数据资产。 它可以扫描文档并自动将其分类。 例如，如果你有一个名为 multiple.docx 的文件，并且内容中包含一个国家/地区 ID 号，则 Microsoft Purview 会将分类（例如“欧盟国家/地区标识号”）添加到“资产详细信息”页。
在 Microsoft Purview 数据映射中，目录管理员需要在其生命周期内在以下几个方面确保一致性，并维持最佳做法：
- 数据资产 - 需要在各个环境中重新扫描数据源。 仅在开发环境中进行扫描，然后在生产环境中使用 API 重新生成，这种做法不建议采用。 主要原因是，Microsoft Purview 扫描程序会在后台对数据资产执行更多连线，这些数据资产可能会很复杂以至于难以将其迁移到其他 Microsoft Purview 实例。 在生产环境中添加相同的数据源，并重新扫描源，这样更加简单。 一般的最佳做法是记录所有扫描、连接和所使用的身份验证机制。
- 扫描规则集 - 这是向特定扫描分配的规则（如要检测的文件类型和分类）的集合。 如果没有那么多的扫描规则集，可以只是通过生产环境手动重新创建这些规则集。 这需要完成内部流程并正确地进行记录。 但是，如果规则集每天或每周都会更改，可以通过了解 REST API 路由解决此问题。
- 自定义分类 - 分类可能不会也定期更改。 在部署的初始阶段，可能需要一些时间了解不同的要求并提供自定义分类。 但是，一旦确定，这可能几乎不需要更改。 因此，此处建议手动迁移所有自定义分类，或使用 REST API。
- 术语表 - 可以通过 UX 导出和导入术语表术语。 还可以使用 REST API 执行自动化方案。
- 资源集模式策略 - 这是一种高级功能，任何典型组织都可以应用。 在某些情况下，Azure Data Lake Storage 的文件夹命名约定和特定结构可能会导致 Microsoft Purview 无法生成资源集。 业务部门可能还需要通过额外的自定义更改资源集构造，以满足业务需求。 在此情况下，最好通过 REST API 跟踪所有更改，并通过外部版本控制平台记录更改。
- 角色分配 – 控制哪些人员有权访问 Microsoft Purview 以及这些人员具有哪些权限。 Microsoft Purview 还提供了用于支持导出和导入用户和角色的 REST API，但这不兼容 Atlas API。 建议改为分配 Azure 安全组并管理组成员身份。
移动租户
Microsoft Purview 当前不支持移动租户的操作。
移动订阅
可以在订阅之间移动 Microsoft Purview 帐户。 但是，如果你的帐户是在 2023 年 12 月 15 日之前创建的（或是使用 2023-05-01-preview 之前的 API 版本部署的），或者你的帐户使用的是托管事件中心，则与 Microsoft Purview 帐户关联的托管存储帐户和托管事件中心不会随实例一起迁移。 Microsoft Purview 帐户仍可正常运行，但不应删除这些资源。
如果需要从其他订阅中删除受管理资源，则需要创建新的 Microsoft Purview 帐户并将信息迁移到此新帐户，然后再删除原始资源及其托管资源。