Microsoft Purview (以前是 Azure Purview) 部署最佳做法

  • 项目

本文介绍如何在数据资产中成功将 Microsoft Purview (以前为 Azure Purview) 部署到生产环境中。 它旨在帮助你制定策略并分阶段部署，从研究到强化生产环境，最好与我们的 部署清单结合使用。

注意

这些最佳做法介绍了 Microsoft Purview 统一数据治理解决方案的部署。 有关 Microsoft Purview 风险和合规性解决方案的详细信息， 请转到此处。 有关 Microsoft Purview 的一般信息， 请转到此处。

如果正在寻找严格的技术部署指南，请使用 部署清单。

如果要创建部署 Microsoft Purview 的计划，并希望在制定部署策略时考虑最佳做法，请按照以下文章操作。 本指南概述了在一个月或更多时间中可以分阶段完成的任务，以开发 Microsoft Purview 的部署过程。 即使是已部署 Microsoft Purview 的组织，也可以使用本指南来确保他们充分利用其投资。

精心规划的数据治理平台部署可提供以下优势：

  • 更好的数据发现
  • 改进的分析协作
  • 最大化投资回报

本指南通过以下阶段提供有关从初始规划到成熟环境的完整部署生命周期的见解：

阶段 说明
确定目标和目标 考虑整个组织对数据治理的需求和需求。
收集问题 你和你的团队在开始时可能会遇到什么问题，你希望从哪里开始解决这些问题？
创建要迁移到生产环境的流程 创建针对组织定制的分阶段部署策略。
平台强化 继续将部署扩展到成熟度。

Microsoft Purview 的许多应用程序和功能也有各自的最佳做法页面。 在本部署指南中经常引用它们，但可以在 “概念 ”和 “最佳做法和指南”下的目录中找到所有这些内容。

确定目标和目标

许多组织通过开发满足整个组织中独立组和数据域的特定要求的各个解决方案，开始了其数据治理之旅。 尽管体验可能因行业、产品和文化而异，但大多数组织发现很难为这些类型的解决方案保持一致的控制和策略。

为了创建全面的数据治理体验，你可能希望在早期阶段确定的一些常见数据治理目标包括：

  • 最大化数据的业务价值
  • 启用数据区域性，让数据使用者能够轻松查找、解释和信任数据
  • 加强各业务部门之间的协作，以提供一致的数据体验
  • 通过加速数据分析来促进创新，从而获得云的优势
  • 通过各种技能组的自助服务选项减少发现数据的时间
  • 缩短交付分析解决方案的上市时间，从而改善为客户提供的服务
  • 降低因使用特定于域的工具和不受支持的技术而导致的操作风险

一般方法是将这些首要目标分解为不同的类别和目标。 示例如下：

类别 目标
发现 管理员用户应能够扫描 Azure 和非 Azure 数据源 (包括本地源) ，以自动收集有关数据资产的信息。
分类 平台应根据数据的采样自动对数据进行分类，并允许使用自定义分类进行手动替代。
消耗 业务用户应能够找到有关每个资产的业务和技术元数据的信息。
血统 每个资产都必须显示基础数据集的图形视图，以便用户了解原始源以及所做的更改。
协作 平台必须允许用户通过提供有关每个数据资产的其他信息进行协作。
Reporting 用户必须能够查看有关数据资产的报告，包括敏感数据和需要额外扩充的数据。
数据治理 平台必须允许管理员定义访问控制策略，并基于每个用户自动强制实施数据访问。
工作流 平台必须能够创建和修改工作流，以便可以轻松地横向扩展和自动执行平台中的各种任务。
集成 票证或业务流程等其他第三方技术必须能够通过脚本或 REST API 集成到平台中。

确定关键方案

Microsoft Purview 治理服务可用于集中管理跨跨云和本地环境的组织数据资产的数据治理。 若要成功实现，必须确定对业务至关重要的关键方案。 这些方案可能跨越业务部门边界，或影响上游或下游的多个用户角色。

可以通过各种方式编写这些方案，但至少应包括以下五个维度：

  1. 角色 - 谁是用户？
  2. 源系统 - 什么是数据源，例如Azure Data Lake Storage Gen2或Azure SQL数据库？
  3. 影响区域 - 此方案的类别是什么？
  4. 详细信息方案 - 用户如何使用 Microsoft Purview 来解决问题？
  5. 预期结果 - 成功标准是什么？

方案必须具体、可操作且可执行，并具有可衡量的结果。 可以使用的一些示例方案：

应用场景 详情 Persona
编录业务关键型资产 我需要了解有关每个数据集的信息，以便很好地了解它是什么。 此方案包括有关目录中数据集的业务和技术元数据数据。 数据源包括Azure Data Lake Storage Gen2、Azure Synapse DW 和/或 Power BI。 此方案还包括本地资源，例如SQL Server。 业务分析师、数据科学家数据工程师
发现业务关键型资产 我需要一个可以搜索目录中所有元数据的搜索引擎。 我应该能够使用技术术语、业务术语和通配符的简单或复杂搜索进行搜索。 业务分析师，数据科学家，数据工程师，数据管理员
跟踪数据以了解其来源并排查数据问题 我需要有数据世系来跟踪报表、预测或模型中的数据，使其回到其原始源。 我还需要了解对数据所做的更改，以及数据在整个数据生命周期中的驻留位置。 此方案需要支持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位置的 DB、表、存储过程、视图和配置数据的列表。 对于Azure 数据工厂 (ADF) 可以枚举所有管道，并获取创建、上次运行和当前状态的数据。
  • 世系 - 这使 Microsoft Purview 能够从分析/数据突变系统中收集有关数据移动方式的信息。 对于 Spark 之类的内容，这可能从笔记本的执行中收集信息，以查看笔记本引入的数据、它如何转换数据以及输出数据的位置。 对于 SQL 之类的内容，它可以分析查询日志，以反向工程执行了哪些突变操作及其执行了哪些操作。 我们支持基于推送和拉取的世系，具体取决于需求。
  • 分类 - 这使 Microsoft Purview 能够从数据源获取物理样本，并通过分类系统运行它们。 分类系统可找出一段数据的语义。 例如，我们可能知道文件是 Parquet 文件，有三列，第三列是字符串。 但我们在示例上运行的分类器会告诉我们字符串是名称、地址或电话号码。 点亮此集成点意味着我们已定义 Microsoft Purview 如何打开笔记本、管道、parquet 文件、表和容器等对象。
  • 嵌入式体验 – 具有“工作室”（如 ADF、Synapse、SQL Studio、PBI 和 Dynamics 等体验 (（如 ADF、Synapse、SQL Studio、PBI 和 Dynamics）) 的产品通常希望让用户能够发现他们想要与之交互的数据，并找到输出数据的位置。 Microsoft Purview 的目录可以通过提供嵌入体验来帮助加速这些体验。 此体验可以在 API 或合作伙伴选项的 UX 级别发生。 通过嵌入对 Microsoft Purview 的调用，组织可以利用 Microsoft Purview 的数据资产地图来查找数据资产、查看世系、检查架构、查看评级、联系人等。

收集问题

一旦组织就高级目标和目标达成一致，多个组就会提出许多问题。 收集这些问题以制定解决所有关切的计划至关重要。 收集这些问题时，请确保 包含相关组 。 可以使用我们的文档开始回答它们。

在初始阶段可能会遇到的一些示例问题：

即使你可能没有立即回答其中大多数问题，收集问题也可以帮助你的组织制定此项目，并确保满足所有“必备”要求。

包括适当的利益干系人

为了确保为整个组织成功实施 Microsoft Purview，请务必让适当的利益干系人参与其中。 初始阶段只涉及少数人。 但是，随着范围的扩大，你将需要更多角色来参与项目并提供反馈。

你可能希望包括一些关键利益干系人：

Persona 角色
首席数据官 CDO 监督一系列功能，可能包括数据管理、数据质量、主数据管理、数据科学、商业智能和创建数据策略。 他们可以是 Microsoft Purview 实现项目的发起人。
域/业务所有者 影响工具使用并拥有预算控制的业务人员
数据分析师 能够制定业务问题和分析数据，以帮助领导者做出业务决策
数据架构师 为任务关键型业务线应用设计数据库，同时设计和实现数据安全性
数据工程师 操作和维护数据堆栈，从不同源拉取数据，集成和准备数据，设置数据管道
数据科学家 生成分析模型并设置要通过 API 访问的数据产品
数据库管理员 在服务级别协议中拥有、跟踪和解决与数据库相关的事件和请求， (SLA) ;可以设置数据管道
DevOps 业务线应用程序开发和实现;可能包括编写脚本和业务流程功能
数据安全专家 评估整体网络和数据安全性，涉及传入和传出 Microsoft Purview 的数据

创建要迁移到生产环境的流程

下面我们提供了一个可能的四阶段部署计划，其中包括每个阶段的任务、有用链接和验收条件：

  1. 阶段 1：试点
  2. 阶段 2：最小可行产品
  3. 阶段 3：预生产
  4. 阶段 4：生产

阶段 1：试点

在此阶段中，必须为一小部分用户创建和配置 Microsoft Purview。 通常，它只是一组 2-3 人，共同运行端到端方案。 他们被视为组织中 Microsoft Purview 的拥护者。 此阶段main目标是确保满足关键功能，并且适当的利益干系人了解项目。

要完成的任务

任务 详情 持续时间
收集 & 就要求达成一致 与所有利益干系人讨论以收集一整套要求。 不同的角色必须参与，才能就项目每个阶段完成的一部分要求达成一致。 一周
导航 Microsoft Purview 治理门户 了解如何从主页使用 Microsoft Purview。 一天
为世系配置 ADF 确定关键管道和数据资产。 收集连接到内部 ADF 帐户所需的所有信息。 一天
扫描数据源，例如Azure Data Lake Storage Gen2或 SQL Server。 添加数据源并设置扫描。 确保扫描成功检测所有资产。 两天
搜索 和 浏览 允许最终用户访问 Microsoft Purview 并执行端到端搜索和浏览方案。 一天

验收条件

  • Microsoft Purview 帐户在组织租户下的组织订阅中成功创建。
  • 具有多个角色的一小部分用户可以访问 Microsoft Purview。
  • Microsoft Purview 配置为扫描至少一个数据源。
  • 用户应能够提取 Microsoft Purview 的键值，例如：
    • 搜索和浏览
    • 血统
  • 用户应能够在资产页中分配资产所有权。
  • 演示和演示，以提高主要利益干系人的认识。
  • 从管理层购买，以批准 MVP 阶段的更多资源。

阶段 2：最小可行产品

获得加入 Microsoft Purview 的商定要求和参与的业务单位后，下一步是) 发布最低可行产品 (MVP。 在此阶段，你将将 Microsoft Purview 的使用扩展到更多水平和垂直需求的用户。 对于所有用户，必须水平满足一些关键方案，例如术语表术语、搜索和浏览。 每个业务部门或组还会有垂直深入的要求，以涵盖特定的端到端方案，例如从Azure Data Lake Storage到Azure Synapse DW 到 Power BI 的世系。

要完成的任务

任务 详情 持续时间
扫描Azure Synapse分析 开始载入数据库源并扫描它们以填充关键资产 两天
创建自定义分类和规则 扫描资产后，你的用户可能会发现，除了 Microsoft Purview 的默认分类之外，还有其他用于更多分类的用例。 2-4 周
扫描 Power BI 如果组织使用 Power BI，则可以扫描 Power BI，以收集数据科学家或数据分析师使用的所有数据资产，这些资产要求包含存储层的世系。 1-2 周
导入术语表术语 在大多数情况下，你的组织可能已开发术语表术语和术语分配给资产的集合。 这需要通过 .csv 文件导入 Microsoft Purview。 一周
将联系人添加到资产 对于顶级资产，你可能希望建立一个流程，以允许其他角色分配联系人或通过 REST API 导入。 一周
添加敏感标签并扫描 对于某些组织来说，这可能是可选的，具体取决于 Microsoft 365 中的标记的用法。 1-2 周
获取分类和敏感见解 对于 Microsoft Purview 中的报告和见解，可以访问此功能来获取各种报表并向管理层提供演示文稿。 一天
使用 Microsoft Purview 托管用户加入更多用户 此步骤要求 Microsoft Purview 管理员与 Azure Active Directory 管理员建立新的安全组，以授予对 Microsoft Purview 的访问权限。 一周

验收条件

  • 成功将更大的用户组加入 Microsoft Purview (50 多个)
  • 扫描业务关键数据源
  • 导入并分配所有关键术语表术语
  • 成功测试关键资产上的重要标记
  • 已成功满足参与业务部门用户的最低方案

阶段 3：预生产

MVP 阶段结束后，即可规划预生产里程碑。 你可能希望包括在本地数据源（例如SQL Server）上的扫描。 如果 Microsoft Purview 不支持的数据源存在任何差距，可以探索 Atlas API 以了解其他选项。

要完成的任务

任务 详情 持续时间
使用扫描规则集优化扫描 你的组织将具有许多用于预生产的数据源。 必须预先定义用于扫描的关键条件，以便分类和文件扩展名可以全面一致地应用。 1-2 天
通过检查源页来评估每个源的区域可用性，以便扫描每个源 根据数据源的区域和组织对合规性和安全性的要求，你可能需要考虑哪些区域必须可用于扫描。 一天
在扫描时了解防火墙概念 此步骤需要了解组织如何配置其防火墙，以及 Microsoft Purview 如何对自身进行身份验证以访问用于扫描的数据源。 一天
了解扫描时专用链接概念 如果组织使用专用链接，则必须为网络安全打下基础，以将专用链接作为要求的一部分。 一天
扫描本地SQL Server 如果具有本地SQL Server，则这是可选的。 扫描需要设置自承载Integration Runtime并将SQL Server添加为数据源。 1-2 周
将 Microsoft Purview REST API 用于集成方案 如果要求将 Microsoft Purview 与其他第三方技术（如业务流程或票证系统）集成，则可能需要浏览 REST API 区域。 1-4 周
了解 Microsoft Purview 定价 此步骤将为组织提供重要的财务信息来做出决策。 1-5 天

验收条件

  • 与所有用户一起成功加入至少一个业务部门
  • 扫描本地数据源，例如SQL Server
  • 使用 REST API 的 POC 至少一个集成方案
  • 完成生产计划，其中应包括基础结构和安全性的关键领域

阶段 4：生产

应遵循上述阶段来创建有效的数据生命周期管理，这是改进治理计划的基础。 数据治理可帮助组织为 AI、Hadoop、IoT 和区块链等不断增长的趋势做好准备。 这只是数据和分析的许多事情的开始，还有很多可以讨论的。 此解决方案的结果将带来：

  • 以业务为中心的 解决方案 - 与业务要求和方案（比技术要求）保持一致。
  • 未来就绪 - 解决方案将最大化平台的默认功能，并使用标准化的行业做法进行配置或脚本活动，以支持平台的进步/演变。

要完成的任务

任务 详情 持续时间
扫描启用了防火墙的生产数据源 如果防火墙已到位，但请务必探索强化基础结构的选项，这是可选的。 1-5 天
启用专用链接 如果使用专用链接，则此项是可选的。 否则，可以跳过此选项，因为它是启用 Private 时必须满足的条件。 1-5 天
创建自动化工作流 工作流对于自动执行审批、升级、评审和问题管理等流程非常重要。 2-3 周
创建操作文档 数据治理不是一次性项目。 这是一个正在进行的计划，旨在推动数据驱动的决策制定并为业务创造机会。 记录关键过程和业务标准至关重要。 一周

验收条件

  • 成功加入所有业务部门及其用户
  • 成功满足生产基础结构和安全要求
  • 成功满足用户所需的所有用例

平台强化

可以采取更多强化步骤：

  • 通过在防火墙资源上启用扫描或使用专用链接来增强安全态势
  • 微调范围扫描以提高扫描性能
  • 使用 REST API 导出用于备份和恢复的关键元数据和属性
  • 使用工作流 自动执行票证和事件处理，以避免人为错误
  • 使用策略 通过 Microsoft Purview 治理门户管理对数据资产的访问。

生命周期注意事项

在生产过程中要包含的另一个重要方面是如何迁移分类和标签。 Microsoft Purview 具有 90 多个系统分类器。 可以对文件、表或列资产应用系统或自定义分类。 分类类似于主题标记，用于标记和标识扫描期间在数据资产中找到的特定类型的内容。 敏感度标签用于标识组织数据中分类类型的类别，然后将要应用于每个类别的策略分组。 它使用与 Microsoft 365 相同的敏感信息类型，使你能够跨整个内容和数据资产扩展现有安全策略和保护。 它可以扫描文档并自动对文档进行分类。 例如，如果有一个名为 multiple.docx 且其内容中包含国家/地区 ID 号的文件，Microsoft Purview 将在“资产详细信息”页中添加分类，例如欧盟国家/地区标识号。

在Microsoft Purview 数据映射中，目录管理员需要在几个方面确保其生命周期内的一致性和维护最佳做法：

  • 数据资产 – 需要跨环境重新扫描数据源。 不建议仅在开发中扫描，然后使用生产中的 API 重新生成它们。 main原因是 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 当前不支持移动租户。

后续步骤