你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

自助服务数据平台的设计注意事项

数据网格是一种令人兴奋的数据体系结构设计和开发的新方法。 与传统的数据体系结构不同，数据网格分离了功能性的数据域（专注于创建数据产品）和平台团队（专注于技术功能）之间的职责。 这种职责分离必须反映在平台中。 必须在提供与域无关的功能和使域团队能够在组织中建模、处理和分发数据之间取得平衡。

选择适当的域粒度级别和规则以使用平台进行分离并不容易。 本文包含多个提供详细指导的方案。

云规模分析

若要使用 Azure 生成数据网格，建议采用云规模分析。 此框架是一种可部署的参考体系结构，附带开源模板和最佳做法。 云规模分析体系结构具有两个主要构建基块，这些构建基块是所有部署选项的基础：

• 数据管理登陆区域：数据体系结构的基础。 它包含数据管理的所有关键功能，例如数据目录、数据世系、API 目录、主数据管理等。
• 数据登陆区域：托管分析和 AI 解决方案的订阅。 其中包括用于托管分析平台的关键功能。

以下示意图大致展示具有数据管理登陆区域和单个数据登陆区域的云规模分析平台。 示意图中并未体现所有 Azure 服务。 它已经过简化，重点展示体系结构中的核心概念资源组织。

基于云的分析框架并未明确说明必须预配的确切数据体系结构类型。 可将其用于许多常见的云规模分析解决方案，包括（企业）数据仓库、数据湖、数据湖中心和数据网格。 本文中的所有示例解决方案均使用数据网格体系结构。

了解所有体系结构都遵循数据网格原则：域所有权、数据即产品、自助服务数据平台和联合计算治理。 各种路径都可能通向数据网格。 没有单一的正确或错误答案。 必须根据组织的需求做出正确的权衡。

单个数据登陆区域

用于构建数据网格体系结构的最简单部署模式涉及一个数据管理登陆区域和一个数据登陆区域。 此类方案中的数据体系结构如下所示：

在此模型中，所有功能数据域都驻留在同一个数据登陆区域。 单个订阅包含一组标准服务。 资源组分隔不同的数据域和数据产品。 Azure Data Lake Store、Azure Logic Apps 和 Azure Synapse Analytics 等标准数据服务适用于所有域。

所有数据域都遵循数据网格原则：数据遵循域所有权，数据被视为产品。 平台完全是自助服务，尽管服务存在有限的变体。 所有域都应严格遵守并遵循相同的数据管理原则。

此部署选项适合希望采用数据网格而不采用过于复杂的方法的小型公司或绿地项目。 对于计划构建更复杂的内容的组织来说，此部署也可以是起点。 在这种情况下，计划稍后扩展到多个登陆区域。

源系统一致和客户一致的登陆区域

在之前的模型中，我们没有考虑其他订阅或本地应用程序。 通过添加与源系统一致的登陆区域来管理所有传入数据，可以稍微更改上一个模型。 数据加入是一个困难的过程，因此拥有两个数据登陆区域很有用。 加入大体上仍然是使用数据最具有挑战性的部分之一。 加入通常需要额外的工具来解决集成问题，因为它的挑战不同于集成的挑战。 它有助于区分提供数据和消耗数据。

在此关系图左侧的体系结构中，CDC、用于拉取 API 的服务，或用于动态生成数据集的数据湖服务等服务可促进所有数据加入。 此平台中的服务可以从本地、云环境或 SaaS 供应商拉取数据。 此类型的平台通常也有更多的开销，因为与基础操作应用程序有更多的耦合。 你可能希望将此与任何数据使用区别对待。

在关系图右侧的体系结构中，组织优化消耗，并让服务专注于将数据转化为价值。 这些服务可以包括机器学习、报告等。

这些体系结构域遵循数据网格的所有原则。 域拥有数据的所有权，并可直接将数据分发到其他域。

中心、泛型和特殊数据登陆区域

下一个部署选项是上一个设计的另一次迭代。 此部署遵循受治理的网格拓扑：数据通过中心分布，其中数据按域进行分区、逻辑隔离且未集成。 此模型的中心使用自己的（与域无关的）数据登陆区域，并且可以由中央数据管理团队拥有，负责监督哪些数据分发到哪些其他域。 该中心还承载有助于数据加入的服务。

对于需要使用标准服务消耗、使用、分析和创建新数据的域，请使用通用数据登陆区域。 此单个订阅包含一组标准服务。 此外，应用数据虚拟化，因为大部分数据产品已保留在中心内，并且不需要较多重复数据。

此部署允许“特殊项”：当无法对域进行逻辑分组时，可以预配额外的登陆区域。 当区域或法律边界适用，或者域具有唯一和不同的要求时，可能需要它们。 在应用强大的全球子公司治理（海外活动除外）的情况下，可能还需要它们。

如果组织需要控制哪些数据由哪些域分发和使用，那么中心部署是一个不错的选择。 如果你要解决大型数据使用者的时变问题和非易失性问题，则这也是一个选项。 可以对数据产品设计进行高度标准化，从而使域能够按时间顺序查看并执行重新交付。 这种模式在金融行业尤其常见。

功能和区域一致的数据登陆区域

预配多个数据登陆区域有助于根据工作和共享数据的一致性和效率对功能域进行分组。 所有数据登陆区域都遵循相同的审核和控制，但仍然可以在不同的数据登陆区域之间获得灵活性和更改设计。

确定要对共享数据登陆区域进行逻辑分组的功能数据域。 例如，如果具有区域边界，则可以实现相同的模板。 所有权、安全性或法律边界可能强制实施域隔离。 灵活性、更改速度以及功能分离或销售也是需要考虑的重要因素。

可在数据域中找到进一步指导和最佳做法。

不同的登陆区域并不独立。 它们可以连接到托管在其他区域的数据湖。 这样，域就可在企业中进行协作。 还可以应用多语言持久化来混合不同的数据存储技术。 多语言持久化允许域直接从其他域读取数据，而无需复制数据。

在部署多个数据登陆区域时，了解每个数据登陆区域都有管理开销。 必须在所有数据登陆区域之间应用 VNet 对等互连，必须管理额外的专用终结点等。

如果数据体系结构很大，那么部署多个数据登陆区域是一个不错的选择。 可以将更多登陆区域添加到体系结构中，以满足各种域的共同需求。 这些额外的登陆区域使用虚拟网络对等互连连接到数据管理登陆区域及所有其他登陆区域。 对等互连允许跨登陆区域共享数据集和资源。 通过跨不同区域拆分数据，可跨 Azure 订阅和资源分散工作负载。 此方法有助于有机地实现数据网格。

需要不同数据管理区域的大型企业

在全球范围内运营的大型企业在其组织的不同部分之间可能具有截然不同的数据管理要求。 可以同时部署多个数据管理和数据登陆区域来解决此问题。 下图显示了此类体系结构的示例：

多个数据管理登陆区域应证明开销和集成复杂性是合理的。 例如，对于组织外部的任何人不得看到组织（元）数据的情况，另外使用一个数据管理登陆区域可能比较合理。

结束语

向数据网格过渡是涉及细微差别、权衡和注意事项的文化转变。 可使用云规模分析来获取最佳做法和可执行资源。 本文的参考体系结构提供了启动实现的起点。

下一步

• 数据市场