数据网格原则与逻辑架构

数据的巨大鸿沟

我们到底指的是什么数据？答案取决于你问谁。当今的环境分为运营数据和分析数据。运营数据位于微服务提供的业务能力背后的数据库中，具有事务性，保持当前状态并满足运行业务的应用程序的需求。分析数据是随着时间推移的业务事实的时态和聚合视图，通常经过建模以提供回顾性或未来视角的见解；它训练 ML 模型或提供分析报告。

当前的技术、架构和组织设计状态反映了这两个数据平面的分歧 - 两个存在级别，集成但分离。这种分歧导致了脆弱的架构。不断失败的 ETL（提取、转换、加载）作业以及错综复杂的数据管道不断增长，对于许多试图连接这两个平面、将数据从运营数据平面流向分析平面，然后再流回运营数据平面的人来说，这都是司空见惯的景象。

图 1：数据的巨大鸿沟

分析数据平面本身已分化为两种主要的架构和技术堆栈：数据湖和数据仓库；数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。对于本次对话，我将把这两种技术堆栈之间的舞蹈放在一边：数据仓库试图接入数据科学工作流，数据湖试图为数据分析师和商业智能提供服务。数据网格的原始撰写文章探讨了现有分析数据平面架构的挑战。

图 2：分析数据的进一步划分 - 仓库

图 3：分析数据的进一步划分 - 湖

数据网格认识并尊重这两个平面之间的差异：数据的性质和拓扑结构、不同的用例、数据消费者的个人角色，以及最终的各种访问模式。但是，它试图在不同的结构下连接这两个平面 - 基于领域而不是技术堆栈的倒置模型和拓扑结构 - 并专注于分析数据平面。当今管理两种数据原型可用的技术差异不应导致处理它们的组织、团队和人员的分离。在我看来，运营和事务数据技术和拓扑结构相对成熟，并且在很大程度上由微服务架构驱动；数据隐藏在每个微服务的内部，通过微服务的 API 进行控制和访问。是的，确实有创新的空间来真正实现多云原生运营数据库解决方案，但从架构的角度来看，它满足了业务的需求。但是，分析数据的管理和访问仍然是规模化时的摩擦点。这就是数据网格关注的地方。

我相信，在未来的某个时刻，我们的技术将发展到将这两个平面更紧密地结合在一起，但就目前而言，我建议我们将他们的关注点分开。

领域所有权

数据网格的核心是去中心化和责任分配，将责任分配给最接近数据的人，以支持持续变化和可扩展性。问题是，我们如何分解和去中心化数据生态系统的组件及其所有权。这里的组件由分析数据、其元数据以及为其提供服务所需的计算组成。

数据网格遵循组织单元的缝隙作为分解轴。我们当今的组织是根据其业务领域进行分解的。这种分解将持续变化和演变的影响（在很大程度上）定位到领域的边界上下文。因此，使业务领域的边界上下文成为数据所有权分配的理想选择。

在这篇文章中，我将继续使用与原始撰写文章相同的用例，“一家数字媒体公司”。可以想象，这家媒体公司根据其运营（因此支持运营的系统和团队）进行划分，例如“播客”，管理播客发布及其主持人的团队和系统；“艺术家”，管理艺术家入职和支付的团队和系统，等等。数据网格认为，分析数据的拥有权和服务应尊重这些领域。例如，管理“播客”的团队，在提供发布播客的 API 的同时，还应负责提供代表“已发布播客”随时间推移的历史数据，以及其他事实，例如“收听量”随时间推移的变化。有关此原则的更深入探讨，请参阅面向领域的 数据分解和所有权。

逻辑架构：面向领域的 数据和计算

为了促进这种分解，我们需要建立一个架构，该架构按领域排列分析数据。在此架构中，领域与组织其他部分的接口不仅包括运营能力，还包括访问领域提供的分析数据。例如，“播客”领域提供运营 API 来“创建新的播客剧集”，但也提供分析数据端点来检索“过去 <n> 个月的所有播客剧集数据”。这意味着架构必须消除任何摩擦或耦合，以使领域能够独立于其他领域提供其分析数据并发布计算数据的代码。为了实现规模化，架构必须支持领域团队在发布和部署其运营或分析数据系统方面的自主权。

以下示例演示了面向领域的 数据所有权原则。这些图仅是逻辑表示和示例。它们并非旨在完整。

每个领域可以公开一个或多个运营 API，以及一个或多个分析数据端点

图 4：符号：领域、其分析数据和运营能力

自然地，每个领域都可能依赖于其他领域的运营和分析数据端点。在以下示例中，“播客”领域使用“用户”领域的“用户更新”分析数据，以便它可以通过其“播客听众人口统计”数据集提供播客听众人口统计的概况。

图 5：示例：除了运营能力之外，面向领域的 分析数据所有权

注意：在示例中，我使用了命令式语言来访问运营数据或能力，例如“支付艺术家”。这仅仅是为了强调访问运营数据与分析数据的意图之间的差异。我确实认识到，在实践中，运营 API 是通过更具声明性的接口实现的，例如访问 RESTful 资源或 GraphQL 查询。

数据即产品

现有分析数据架构的挑战之一是发现、理解、信任以及最终使用高质量数据的摩擦和成本很高。如果不加以解决，随着提供数据的领域（团队）数量的增加，这个问题只会加剧。这将是我们第一个去中心化原则的结果。数据即产品原则旨在解决数据质量和长期存在的数据孤岛问题；或者正如 Gartner 所称的暗数据 - “组织在日常业务活动中收集、处理和存储的信息资产，但通常无法用于其他目的”。领域提供的分析数据必须被视为产品，而该数据的消费者应被视为客户 - 快乐且满意的客户。

原文列出了数据网格实现应支持的一系列功能，包括可发现性、安全性、可探索性、可理解性、可信赖性等，以便将域数据视为产品。它还详细说明了组织必须引入的域数据产品所有者等角色，负责确保数据作为产品交付的客观指标。这些指标包括数据质量、数据消费的缩短交付时间，以及通过净推荐值实现的总体数据用户满意度。域数据产品所有者必须深入了解数据用户是谁、他们如何使用数据以及他们习惯使用的原生方法。这种对数据用户的深入了解会导致设计满足其需求的数据产品界面。实际上，对于网格上的大多数数据产品来说，存在一些具有独特工具和期望的传统角色，例如数据分析师和数据科学家。所有数据产品都可以开发标准化界面来支持它们。数据用户和产品所有者之间的对话是建立数据产品界面的必要环节。

每个域将包括数据产品开发人员角色，负责构建、维护和服务域的数据产品。数据产品开发人员将与域中的其他开发人员一起工作。每个域团队可以服务一个或多个数据产品。也可以组建新的团队来服务不自然地适合现有运营域的数据产品。

注意：与过去范式相比，这是一个责任倒置模型。数据质量的责任向上游转移，尽可能靠近数据源。

逻辑架构：数据产品作为架构量子

从架构上讲，为了支持数据作为域可以自主服务或消费的产品，数据网格引入了数据产品的概念作为其架构量子。架构量子，如演化架构中所定义，是架构的最小单元，可以独立部署，具有高度的功能内聚性，并包含其功能所需的所有结构元素。

数据产品是网格上的节点，它封装了其功能所需的三个结构组件，提供对域分析数据的访问，将其作为产品。

• 代码：它包括 (a) 用于数据管道的代码，负责消费、转换和服务上游数据 - 从域的运营系统或上游数据产品接收的数据；(b) 用于 API 的代码，提供对数据、语义和语法模式、可观察性指标和其他元数据的访问；(c) 用于执行特性（如访问控制策略、合规性、来源等）的代码。
• 数据和元数据：这就是我们都在这里的原因，以多种形式存在的底层分析数据和历史数据。根据域数据的性质及其消费模型，数据可以作为事件、批处理文件、关系表、图形等形式提供，同时保持相同的语义。为了使数据可用，有一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等；内在的元数据，例如其语义定义，以及用于计算治理的元数据，用于实现预期行为，例如访问控制策略。
• 基础设施：基础设施组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。

图 6：数据产品组件作为单个架构量子

以下示例基于上一节，展示了数据产品作为架构量子。该图仅包含示例内容，并非旨在完整或包含所有设计和实现细节。虽然这仍然是一个逻辑表示，但它更接近物理实现。

图 7：符号：域、其（分析）数据产品和运营系统

图 8：服务于面向域的分析数据的数据产品

注意：数据网格模型不同于过去的范式，在过去的范式中，管道（代码）作为独立于其生成数据的组件进行管理；并且基础设施（如仓库或湖存储帐户的实例）通常在多个数据集之间共享。数据产品是所有组件（代码、数据和基础设施）的组合，以域的边界上下文的粒度进行组合。

自助数据平台

正如你所想象的那样，为了构建、部署、执行、监控和访问一个简单的六边形 - 一个数据产品 - 需要配置和运行相当多的基础设施；配置此基础设施所需的技能是专门的，很难在每个域中复制。最重要的是，团队自主拥有其数据产品的唯一方法是能够访问基础设施的高级抽象，从而消除配置和管理数据产品生命周期的复杂性和摩擦。这需要一个新的原则，自服务数据基础设施作为平台，以实现域自治。

数据平台可以被认为是已经存在于运行和监控服务中的交付平台的扩展。但是，今天用于操作数据产品的底层技术堆栈与服务交付平台看起来非常不同。这仅仅是由于大数据技术堆栈与运营平台的差异。例如，域团队可能将其服务部署为 Docker 容器，而交付平台使用 Kubernetes 进行编排；但是，相邻的数据产品可能在其 Databricks 集群上运行其管道代码作为 Spark 作业。这需要配置和连接两组非常不同的基础设施，在数据网格之前，这两组基础设施不需要这种级别的互操作性和互连性。我个人希望我们开始看到运营基础设施和数据基础设施的融合，在有意义的地方。例如，也许在同一个编排系统（例如 Kubernetes）上运行 Spark。

实际上，为了使分析数据产品开发对通用开发人员（域中现有的开发人员配置文件）变得可访问，自服务平台需要提供新类别的工具和界面，除了简化配置之外。自服务数据平台必须创建工具，以支持域数据产品开发人员的工作流程，使用比现有技术假设的更少的专业知识来创建、维护和运行数据产品；自服务基础设施必须包括降低构建数据产品所需当前成本和专业化的功能。原始文章包括自服务数据平台提供的一系列功能，包括访问可扩展的多语言数据存储、数据产品模式、数据管道声明和编排、数据产品血缘、计算和数据位置等。

逻辑架构：多平面数据平台

自服务平台功能分为多个类别或平面，如模型中所述。注意：平面代表一个存在级别 - 集成但分离。类似于物理和意识平面，或网络中的控制和数据平面。平面既不是层，也不意味着强层次访问模型。

图 9：符号：通过自服务界面提供一系列相关功能的平台平面

自服务平台可以有多个平面，每个平面服务于不同的用户配置文件。在以下示例中，列出了三个不同的数据平台平面

• 数据基础设施配置平面：支持配置运行数据产品组件和产品网格所需的基础设施。这包括配置分布式文件存储、存储帐户、访问控制管理系统、运行数据产品内部代码的编排、在数据产品图上配置分布式查询引擎等。我预计其他数据平台平面或仅高级数据产品开发人员直接使用此界面。这是一个相当低级别的数据基础设施生命周期管理平面。
• 数据产品开发人员体验平面：这是典型数据产品开发人员使用的主要界面。此界面抽象了许多支持数据产品开发人员工作流程的复杂性。它提供了比“配置平面”更高的抽象级别。它使用简单的声明式界面来管理数据产品的生命周期。它自动实现作为一组标准和全局约定定义的跨领域问题，应用于所有数据产品及其界面。
• 数据网格监督平面：有一组功能最适合在网格级别（连接的数据产品的图）全局提供。虽然每个界面的实现可能依赖于单个数据产品的功能，但更方便地在网格级别提供这些功能。例如，发现特定用例的数据产品的功能最好通过搜索或浏览数据产品网格来提供；或者关联多个数据产品以创建更高阶的见解，最好通过执行可以在网格上的多个数据产品上运行的数据语义查询来提供。

以下模型仅为示例，并非旨在完整。虽然平面层次结构是可取的，但下面没有暗示严格的分层。

图 10：自服务数据平台的多个平面 *DP 代表数据产品

联邦计算治理

正如你所看到的，数据网格遵循分布式系统架构；一系列独立的数据产品，具有独立的生命周期，由可能独立的团队构建和部署。但是，对于大多数用例来说，为了以更高阶数据集、见解或机器智能的形式获得价值，需要这些独立的数据产品进行互操作；能够关联它们、创建联合、查找交集，或在它们上执行其他图形或集合操作，以实现规模化。为了使任何这些操作成为可能，数据网格实现需要一个治理模型，该模型包含去中心化和域自主权、通过全局标准化实现互操作性、动态拓扑，最重要的是平台自动执行决策。我称之为联邦计算治理。由域数据产品所有者和数据平台产品所有者联盟领导的决策模型，具有自治和域本地决策权，同时创建和遵守一组全局规则 - 应用于所有数据产品及其界面的规则 - 以确保健康和互操作的生态系统。该小组的任务艰巨：保持中心化和去中心化之间的平衡；哪些决策需要本地化到每个域，哪些决策应该在全局范围内为所有域做出。最终，全局决策只有一个目的，即通过发现和组合数据产品来创建互操作性和复合网络效应。

数据网格中治理的优先级不同于传统分析数据管理系统的治理。虽然它们最终都旨在从数据中获取价值，但传统数据治理试图通过中心化决策来实现这一目标，并建立数据的全局规范表示，而对更改的支持很少。相比之下，数据网格的联邦计算治理拥抱变化和多种解释性上下文。

将系统置于不变的束缚中会导致脆弱性演变。

-- C.S. Holling，生态学家

逻辑架构：嵌入网格的计算策略

为了使联邦治理模型发挥作用，需要有支持性的组织结构、激励模型和架构：为了达成全局决策和互操作性标准，同时尊重本地域的自治，并有效地实施全局策略。

图 11：符号：联邦计算治理模型

如前所述，在全球标准化、平台实施和强制执行的领域和数据产品之间取得平衡，以及将某些决策权留给领域，是一门艺术。例如，领域数据模型应该由最熟悉它的领域进行本地化。例如，"播客受众"数据模型的语义和语法定义应该由"播客领域"团队决定。然而，相反的是，如何识别"播客听众"是一个全球性问题。播客听众是"用户"群体的一部分 - 它的上游边界上下文 - 可以跨越领域边界，并在其他领域（如"用户播放流"）中找到。统一的识别允许关联关于既是"播客听众"又是"流听众"的"用户"的信息。

以下是一个数据网格治理模型中涉及的元素示例。它不是一个全面的示例，只是展示了全球层面相关的关注点。

图 12：联邦计算治理元素示例：团队、激励措施、自动化实施和数据网格的全球标准化方面

许多数据网格治理之前的实践，作为一种集中式功能，不再适用于数据网格范式。例如，过去对黄金数据集认证的强调 - 经过集中式质量控制和认证过程并被标记为可信的数据集 - 作为治理的中心功能，现在不再相关。这是因为在以前的数据管理范式中，数据 - 无论质量和格式如何 - 从运营领域的数据库中提取出来，并集中存储在仓库或湖泊中，现在需要一个集中式团队对其进行清理、协调和加密处理；通常在集中式治理组的监管下。数据网格完全分散了这种关注。领域数据集只有在本地（在领域内）经过质量保证过程，符合预期的数据产品质量指标和全球标准化规则后，才能成为数据产品。领域数据产品所有者最适合决定如何衡量其领域的數據质量，因为他们了解产生数据的领域运营的细节。尽管有这种本地化决策和自主权，但他们需要遵守由全球联邦治理团队定义的质量建模和 SLO 规范，并由平台自动执行。

下表显示了集中式（数据湖、数据仓库）数据治理模型与数据网格之间的对比。

数据网格治理之前的方面	数据网格治理方面
集中式团队	联邦团队
负责数据质量	负责定义如何建模构成质量的要素
负责数据安全	负责定义数据安全方面，例如平台自动构建和监控的数据敏感性级别
负责遵守法规	负责定义平台自动构建和监控的法规要求
数据集中式保管	领域对数据的联邦保管
负责全球规范数据建模	负责建模多义词 - 跨越多个领域边界的數據元素
团队独立于领域	团队由领域代表组成
目标是定义明确的静态数据结构	目标是使有效的网格操作能够实现，并拥抱不断变化和动态的网格拓扑
单体湖泊/仓库使用的集中式技术	每个领域使用的自助式平台技术
根据治理数据的数量或体积（表格）衡量成功	根据网络效应衡量成功 - 代表网格上数据消耗的连接
人工流程，需要人工干预	平台实施的自动化流程
防止错误	通过平台的自动化处理检测错误并恢复

原则总结和高级逻辑架构

让我们将所有内容整合在一起，我们讨论了支撑数据网格的四个原则

这些原则驱动了一个逻辑架构模型，该模型将分析数据和运营数据更紧密地整合到同一个领域，同时尊重它们的技术差异。这些差异包括分析数据可能托管的位置、处理运营服务与分析服务的不同计算技术、查询和访问数据的不同方式等等。

图 13：数据网格方法的逻辑架构

我希望到目前为止，我们已经建立了一种共同的语言和逻辑的思维模型，我们可以共同推进，详细说明网格组件的蓝图，例如数据产品、平台和所需的标准化。