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

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

使用平台进行解耦时，选择合适的域粒度和规则级别并不简单。 本文包含多个场景，为您提供详细指导。

云规模分析

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

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

下图概述了具有数据管理登陆区域和单个数据登陆区域的云规模分析平台。 并非所有 Azure 服务都在关系图中表示。 为了突出此架构中的核心概念——资源组织，内容被简化。

基于云的分析框架对必须预配的确切数据体系结构类型不明确。 可以将它用于许多常见的云规模分析解决方案，包括（企业）数据仓库、数据湖、Data Lake 房屋和数据网格。 本文中的所有示例解决方案都使用数据网格体系结构。

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

单个数据登陆区域

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

在此模型中，所有功能数据域都驻留在相同的数据登陆区域。 单个订阅包含一组标准服务。 资源组隔离不同的数据域和数据产品。 标准数据服务（如 Azure Data Lake Store 和 Azure 逻辑应用）适用于所有域。

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

对于希望采用数据网格而不希望过于复杂的小型公司或绿地项目，此部署选项可能会非常有用。 对于计划构建更复杂的内容的组织来说，此部署也可以是一个起点。 在这种情况下，计划在未来扩展到多个着陆区。

源系统对齐和消耗者对齐的登陆区域

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

在此关系图左侧的体系结构中，服务可促进所有数据载入，例如 CDC、用于拉取 API 的服务或用于动态生成数据集的数据湖服务。 此平台中的服务可以从本地、云环境或 SaaS 供应商拉取数据。 这种类型的平台通常也有更多的开销，因为它与底层业务应用程序有更多的耦合。 您可能希望对待此问题的方式与处理数据使用情况的方式有所不同。

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

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

枢纽、通用和特殊数据登陆区

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

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

此部署允许“特殊功能”：在无法对域进行逻辑分组时提供的额外着陆区域。 当区域或法律边界适用或您的领域有独特且相互对立的需求时，可能需要使用它们。 在强大的全球子公司治理适用于海外活动但存在例外的情况下，你可能还需要它们。

如果你的组织需要控制哪些数据由哪些域分发和使用，则中心部署是一个很好的选择。 如果解决大型数据使用者的时间变体和非易失性问题，则这也是一个选项。 可以严格标准化数据产品设计，使域能够进行时间旅行并执行重新传送。 这种模式在金融业中尤其常见。

功能和区域对齐的数据登陆区域

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

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

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

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

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

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

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

以全球规模运营的大型企业可以在组织的不同部分之间形成鲜明的数据管理要求。 可以将多个数据管理和数据登陆区域一起部署，以解决此问题。 下图显示了此类体系结构的示例：

多个数据管理登陆区域应该证明开销和集成复杂性。 例如，其他数据管理登陆区域对于组织（meta）数据不能被组织外部的任何人看到的情况可能有意义。

结论

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

后续步骤

• 数据市场