治理域和域建议

重要

  • 数据映射中的域限制为总共 5 个。
  • 所有平台域的集合限制为 1000 个。 (一个域可以有 1000 个集合;如果均匀分布,5 个平台域将有 200 个集合,每个集合。)
  • 数据源在一个域中的一个集合中注册。
  • 必须在数据源所在的同一域中扫描已扫描数据源中的资产。
  • 合并帐户将创建域。
  • 构造域不会映射到域,因为 Fabric 域的数量将超过 5 个域的限制。

常规建议

Azure Purview 构造到新 Microsoft Purview 构造模型的逻辑映射示意图。

  • 如果需要真正的分离,则需要单独的租户来启用 Microsoft Purview 的不同实现。 对于大多数组织来说,创建单独的租户并不是一种可能的解决方案,但在某些法规环境中,可能需要创建单独的租户。
  • 许多组织已经具有 SaaS 模型,可以从 Microsoft 365 或 PBI/Fabric 进行部署。 在组织内遵循该模式有助于解决 SaaS 部署问题。

集合和域

  • 使用集合为大多数不同用户提供访问分段,以便仅获得数据映射所需的访问权限。
  • 使用集合与 IT 团队进行技术分离并启用加入,治理域可用于业务团队分离和逻辑概念边界 (术语表术语和数据产品) 。
  • 对于没有生产和非生产单独资源的数据源,具有两者的数据源需要使用集合进行测试,因为每个数据源都注册到一个域和一个集合。

域和治理域

  • 使用开发、测试、生产治理域 (Finance.dev、Finance.prod 等 ) 将测试与概念和使用体验分开。 当不需要测试或不应使测试对目录的使用者可见时,如果概念已准备好用于生产,则可以使治理域过期或重新调整生产用途。
  • 计划使用治理域(而不是集合域或平台域)对计费进行细分。
  • 可将治理域映射到平台域和集合,以在治理域与包含其数据资产的数据映射部分之间建立逻辑关系。

域建议

数据映射中域的非推荐使用

  • 异地驻留分段的隔离。
  • 域不会根据异地驻留分段需求进行缩放以创建边界。
  • 域不会为元数据启用单独的存储位置。
  • 不建议使用业务连续性和灾难恢复方案,因为如果一个域关闭,所有其他域都会关闭。
  • 元数据需要下载到备用源。
  • 业务单元隔离最好通过治理域进行处理。
  • 计费分离遵循使用治理域的做法。
  • 生命周期管理 (开发、测试、质量保证、生产) ,大多数客户都有非生产和生产资源,这些资源旨在与生产资源分开。 可以通过域或集合实现分离。 当同一资源中有非生产和生产数据时,客户必须使用集合。