数据网格（Data Mesh）的四大原则与逻辑架构

数据网格（Data Mesh）是一种面向大规模数据管理的新型架构范式，旨在帮助组织更高效地管理分析型数据、提升数据可用性，并释放数据产品的业务价值。我们希望借助数据增强并改善商业和生活的方方面面，这要求我们在大规模数据管理方式上实现一次范式转变。过去十年的技术进步，在很大程度上解决了数据体量和数据处理算力的扩展问题，却没有真正解决规模化的其他关键维度：数据格局的持续变化、数据源的快速增长、数据用例和数据用户的日益多样化，以及组织对变化的响应速度。

数据网格正是为应对这些挑战而提出的。它建立在四项核心原则之上：面向领域的去中心化数据所有权与架构、数据即产品、自助式数据基础设施即平台，以及联邦式计算治理。每一项原则都为技术架构和组织结构提供了一种新的逻辑视角。

数据网格要解决的核心问题：数据之间的巨大鸿沟

我们究竟该如何定义数据？答案取决于你问的是谁。

如今的数据格局大体可以划分为两类：操作型数据和分析型数据。

操作型数据通常存储在支撑微服务的数据库中，具有事务性，用于维护系统当前状态，并满足业务应用的运行需求。分析型数据则是对业务事实随时间变化形成的聚合视图，通常经过建模，用于提供回顾性或前瞻性洞察；它既可用于训练机器学习模型，也可用于生成分析报告。

当前的技术、架构和组织设计，都反映了这两个数据平面的分化：它们相互关联，却又彼此独立。这种分化造成了架构上的脆弱性。对于许多试图连接这两个平面的人来说，持续失败的 ETL，即提取、转换、加载作业，以及日益复杂的数据管道迷宫，都是再熟悉不过的场景。数据先从操作型数据平面流向分析型数据平面，又试图再回流到操作型平面；而在这一过程中，复杂性不断累积。

图 1：数据的巨大鸿沟

分析型数据平面本身又进一步分化为两大架构和技术栈：数据湖与数据仓库。数据湖主要支持数据科学的访问模式，数据仓库则主要支持分析和商业智能报表的访问模式。本文暂不展开讨论这两个技术栈之间复杂的关系，例如数据仓库如何尝试集成数据科学工作流，或数据湖如何尝试服务数据分析师和商业智能场景。关于当前分析型数据平面架构所面临的挑战，数据网格的原始论述中已有更深入的讨论。

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

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

数据网格识别并尊重这两个平面之间的差异：数据的性质和拓扑结构不同，用例不同，数据消费者的角色不同，最终的数据访问模式也不同。然而，数据网格尝试以一种新的结构连接这两个平面：它采用基于领域而非技术栈的倒置模型和拓扑结构，并重点关注分析型数据平面。

当前用于管理这两类数据原型的技术差异，不应必然导致组织、团队和人员的割裂。在我看来，操作型和事务型数据的技术架构与拓扑结构已经相对成熟，并且主要由微服务架构驱动：数据被封装在各个微服务内部，并通过微服务的 API 进行控制和访问。当然，要真正实现多云原生的操作型数据库解决方案，仍然存在创新空间；但从架构角度看，它已经能够较好地满足业务需求。相比之下，大规模分析型数据的管理与访问仍然是痛点，而这正是数据网格关注的重点。

我相信，未来某个时刻，技术会发展到能够让这两个领域更加紧密地结合。但就目前而言，我建议将它们的问题分开讨论。

数据网格的四大核心原则与逻辑架构

数据网格的目标，是为大规模地从分析型数据和历史事实中获取价值奠定基础。这里的“大规模”，指的是数据格局不断变化，数据源和数据消费者数量持续增长，用例所需的转换和处理方式日益多样，以及组织需要快速响应变化。

为了实现这一目标，我认为任何数据网格的实现都应遵循以下四项基本原则。它们共同兑现规模化的承诺，同时为数据可用性提供必要的质量和完整性保障：

1. 面向领域的去中心化数据所有权与架构；
2. 数据即产品；
3. 自助式数据基础设施即平台；
4. 联邦式计算治理。

虽然这些原则的具体实践、技术和实现方式会随着时间不断演进和成熟，但原则本身应保持稳定。

我希望这四项原则能够共同构成必要且充分的条件，在保证系统可扩展性和弹性的同时，解决数据孤岛化和运营成本增加等问题。接下来，我们将深入探讨每一项原则，并设计支撑这些原则的概念架构。

原则一：面向领域的数据所有权

数据网格的核心在于去中心化，并将责任分配给最接近数据的人，以支持持续变化和规模化扩展。关键问题在于：我们应当如何分解并去中心化数据生态系统中的各个组成部分及其所有权？这些组成部分包括分析型数据、相关元数据，以及服务这些数据所需的计算能力。

数据网格以组织单元的边界作为分解轴。如今，许多组织都是围绕业务领域进行拆分的。这种拆分方式能够在很大程度上将持续变化和演进的影响限定在业务领域的限界上下文之内。因此，业务领域的限界上下文成为分配数据所有权的理想边界。

本文将继续沿用原文中的示例：一家海外数字媒体公司。可以想象，这家公司会根据不同领域组织其业务运营，并进一步划分支撑这些运营的系统和团队。例如，“播客”领域包括负责播客发布与托管平台的团队和系统；“艺人”领域包括负责艺人入驻和付费的团队和系统，等等。

数据网格理论认为，分析型数据的所有权和服务也应尊重这些领域边界。例如，负责“播客”领域的团队在提供用于发布播客的 API 的同时，也应负责提供相关历史数据。这些数据应包含“已发布播客”随时间变化的记录，以及其他相关数据，例如“收听量”随时间的变化。关于这一原则的进一步讨论，可参阅“面向领域的数据分解与所有权”。

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

为了支持这种分解方式，我们需要构建一种按领域组织分析型数据的架构。在该架构中，一个领域与其他组织单元之间的接口，不仅包括操作型功能，也包括该领域所服务的分析型数据访问能力。

例如，“播客”领域不仅提供“创建新播客节目”的操作型 API，也提供用于检索“过去 n 个月内所有播客节目数据”的分析型数据端点。这意味着，架构必须消除摩擦和耦合，使各个领域能够独立地向外提供分析型数据，并发布用于计算数据的代码。为了实现可扩展性，架构还必须支持领域团队在发布和部署其操作系统或分析型数据系统时拥有自主权。

以下示例展示了面向领域的数据所有权原则。图中内容仅为逻辑表示和示例，并非完整模型。

每个领域可以公开一个或多个操作型 API，也可以公开一个或多个分析型数据端点。

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

当然，每个领域也可能依赖其他领域的操作型能力和分析型数据端点。在示例中，“播客”领域会从“用户”领域获取“用户更新”的分析型数据，从而通过“播客听众人口统计”数据集呈现播客听众的人口统计特征。

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

注：在本例中，我使用命令式语言来描述对操作型数据或功能的访问，例如“向艺人付款”。这只是为了强调访问操作型数据与访问分析型数据之间的目的差异。我也意识到，在实践中，操作型 API 通常会通过更具声明性的接口来实现，例如访问 REST 风格资源或执行图查询。

原则二：数据即产品

现有分析型数据架构面临的一大挑战，是发现、理解、信任并最终使用高质量数据的成本和摩擦都很高。如果不加以解决，随着提供数据的地点和团队，也就是“领域”的数量不断增加，数据网格只会加剧这一问题。这是去中心化原则的必然结果。

“数据即产品”原则旨在解决数据质量问题，以及长期存在的数据孤岛问题；也就是海外某些研究机构所称的“暗数据”问题——组织在日常业务活动中收集、处理和存储的信息资产，却通常未能将其用于其他目的。

各领域提供的分析型数据必须被视为产品，而这些数据的消费者则应被视为客户。换言之，数据产品不仅要可用，还要让用户获得良好的使用体验。

原文列举了一系列能力，包括可发现性、安全性、可探索性、可理解性、可信度等。数据网格的实现应支持这些能力，以便将领域数据真正作为产品来管理。文章还详细介绍了组织需要引入的角色，例如领域数据产品负责人。该角色负责确保数据以产品形式交付，并用客观指标衡量其成效。

这些指标包括数据质量、缩短数据消费周期，以及通过净推荐值，即 NPS，衡量的数据用户总体满意度。领域数据产品负责人必须深入理解数据用户是谁、他们如何使用数据，以及他们习惯通过哪些原生方式消费数据。对数据用户的深入理解，有助于设计出真正满足其需求的数据产品接口。

实际上，对于网格上的大多数数据产品而言，都会存在一些具有特定工具和期望的传统用户角色，例如数据分析师和数据科学家。所有数据产品都可以开发标准化接口来支持这些角色。数据用户和产品负责人之间的持续沟通，是建立合适数据产品接口的必要环节。

每个领域都将包含数据产品开发人员这一角色，负责构建、维护并提供该领域的数据产品。数据产品开发人员会与该领域内的其他开发人员协同工作。每个领域团队可以服务一个或多个数据产品。此外，也可以组建新的团队，来服务那些并不自然归属于现有操作型领域的数据产品。

需要注意的是：与以往模式相比，这是一种责任倒置。数据质量的责任被上移到更靠近数据源的位置。

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

在架构层面，为了支持各领域自主地将数据作为产品提供和使用，数据网格引入了“数据产品”这一概念，并将其作为架构量子。

根据演化架构的定义，架构量子是架构中最小的独立部署单元，它具有高度功能内聚性，并包含实现其功能所需的全部结构元素。

数据产品是数据网格上的节点。它封装了实现其功能所需的三个结构组件，并以产品形式提供对领域分析型数据的访问。

第一，代码。
代码包括三类内容：

一是负责消费、转换并提供上游数据的数据管道代码。这些上游数据可能来自该领域的操作系统，也可能来自其他上游数据产品。

二是提供数据、语义模式、语法模式、可观测性指标和其他元数据访问能力的 API 代码。

三是用于强制执行访问控制策略、合规要求、数据血缘等特性的代码。

第二，数据与元数据。
这正是我们关注的核心：以多种形式呈现的底层分析型数据和历史数据。根据领域数据的性质及其使用模型，数据可以以事件、批处理文件、关系表、图等形式提供，同时保持一致的语义。

为了使数据真正可用，还需要一组相关元数据，包括数据计算文档、语义和语法声明、质量指标等；也包括数据固有的元数据，例如语义定义；还包括用于传达计算治理所预期行为特征的元数据，例如访问控制策略。

第三，基础设施。
基础设施组件支撑数据产品代码的构建、部署和运行，也支撑大规模数据与元数据的存储和访问。

图 6：数据产品组件作为一个架构单元

以下示例建立在上一节基础之上，展示了数据产品作为架构量子的作用。该图仅包含示例内容，并非完整呈现，也未包含所有设计和实现细节。虽然这仍然是一种逻辑表示，但它已经越来越接近实际的物理实现。

图 7：符号说明：域、其（分析）数据产品和操作系统

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

需要注意的是，数据网格模型不同于以往范式。在以往范式中，管道代码通常作为独立组件进行管理，并与其生成的数据相分离；基础设施，例如数据仓库实例或数据湖存储账户，也通常由多个数据集共享。而数据产品则是代码、数据和基础设施的组合，其粒度取决于特定领域的限界上下文。

原则三：自助式数据基础设施即平台

可以想象，要构建、部署、执行、监控并访问一个简单的六边形，也就是一个数据产品，需要配置和运行相当多的基础设施。配置这些基础设施所需的技能高度专业化，也很难在每个领域团队中复制。

更重要的是，团队若想自主拥有其数据产品，就必须能够访问一个更高层次的基础设施抽象层，以消除配置和管理数据产品生命周期中的复杂性和摩擦。这就引出了另一个原则：将自助式数据基础设施作为平台，以实现领域自主性。

数据平台可以被视为现有交付平台的一种延伸，用于运行和监控服务。然而，今天用于运行数据产品的底层技术栈，与服务交付平台仍然存在显著差异。这主要源于大数据技术栈与运维平台之间的差异。

例如，领域团队可能会将服务以容器化方式部署，并由交付平台通过容器编排系统进行调度；但相邻的数据产品可能会在云端大数据计算平台上，以分布式计算作业的形式运行其管道代码。这就需要配置和连接两套截然不同的基础设施。而在数据网格出现之前，这种互操作性和互联性并不是必要条件。

对于以研发流程为核心的组织而言，平台化能力还需要覆盖从目标制定、客户反馈、需求清理、评审排期，到开发、测试、发布和知识沉淀的完整链路。例如，团队可以借助 PingCode 这类智能化研发管理工具，将研发过程中产生的数据、知识和经验贯通起来，使数据在不同工具和环节之间更顺畅地流转，从而为后续的数据产品化和治理提供更完整的上下文。

我个人希望，在条件合适的情况下，我们会看到运维基础设施与数据基础设施的进一步融合。例如，也许可以在同一个编排系统上运行分布式数据处理任务。

实际上，为了让通用型开发人员，也就是各领域现有开发人员，能够轻松开发分析型数据产品，自助式平台除了简化配置流程之外，还需要提供一类全新的工具和接口。自助式数据平台必须创建相应工具，支持领域数据产品开发人员创建、维护和运行数据产品的完整工作流，并降低现有技术所要求的专业知识门槛。换言之，自助式基础设施必须能够降低当前构建数据产品的成本和专业化程度。

原文列出了自助式数据平台应提供的一系列能力，包括可扩展的多语言数据存储、数据产品模板、数据管道声明与编排、数据产品血缘、计算与数据本地化等。

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

自助式平台的能力可以划分为多个类别或平面，如模型中所示。

注：这里的“平面”表示一种存在维度——它们彼此关联，又彼此分离。类似于物理平面与意识平面，或网络中的控制平面与数据平面。平面不是层级，也不意味着严格的分层访问模型。

图 9：符号说明：一个通过自助服务界面提供多种相关功能的平台平面

自助式平台可以包含多个平面，每个平面服务于不同的用户群体。以下示例列出了三个不同的数据平台平面。

第一，数据基础设施配置平台。
该平台支持配置运行数据产品及其产品网格所需的底层基础设施。这包括配置分布式文件存储、存储账户、访问控制管理系统、数据产品内部代码编排，以及在数据产品图上配置分布式查询引擎等。

我预计，只有其他数据平台或高级数据产品开发人员才会直接使用该接口。它本质上是一个相当底层的数据基础设施生命周期管理平台。

第二，数据产品开发者体验平台。
这是典型数据产品开发人员使用的主要接口。该接口抽象了支撑数据产品开发工作流所需的许多复杂性，其抽象级别高于基础设施配置平台。

它通过简单的声明式接口来管理数据产品生命周期，并自动实现横切关注点。这些横切关注点被定义为一组标准和全局约定，适用于所有数据产品及其接口。

第三，数据网格治理平面。
有些能力最好在网格层，也就是相互连接的数据产品图之上，以全局方式提供。虽然每个接口的实现可能依赖各个数据产品自身的能力，但在网格层提供这些功能会更加方便。

例如，为特定用例发现所需的数据产品，最好通过搜索或浏览数据产品网格来实现；再如，将多个数据产品关联起来，以创建更高层次的洞察，最好通过可在网格上跨多个数据产品运行的数据语义查询来实现。

以下模型仅为示例，并非完整模型。虽然理想情况下应追求平面之间的清晰划分，但下述内容并不暗示严格的层级关系。

图 10：多层次自助数据平台 *DP 代表数据产品

原则四：联邦式计算治理

如前所述，数据网格遵循分布式系统架构。它由一系列独立的数据产品组成，这些数据产品拥有各自独立的生命周期，并可能由不同团队构建和部署。

然而，对于大多数用例而言，为了获得高阶数据集、洞察或机器智能等形式的价值，这些独立的数据产品必须能够互操作。我们需要能够关联它们、创建并集、查找交集，或者在大规模条件下对它们执行其他图操作或集合操作。

为了实现这些操作，数据网格需要一种治理模型。该模型应同时具备以下特征：去中心化和领域自主权；通过全局标准化实现互操作性；支持动态拓扑结构；最重要的是，由平台自动执行决策。

我将其称为联邦式计算治理。

这是一种由领域数据产品所有者和数据平台产品所有者共同组成的联盟所主导的决策模型。在该模型中，各团队保有自主权和领域本地决策权，同时共同创建并遵守一套全局规则。这些规则适用于所有数据产品及其接口，用于保障生态系统的健康和互操作性。

这个团队面临一项艰巨任务：在集中化与去中心化之间取得平衡。他们需要判断哪些决策应根据具体领域在本地制定，哪些决策应在全局范围内制定。归根结底，全局决策只有一个目的：通过数据产品的发现和组合，实现互操作性，并释放叠加的网络效应。

数据网格的治理重点，与传统分析型数据管理系统的治理重点有所不同。虽然两者的最终目标都是从数据中获取价值，但传统数据治理通常试图通过集中式决策，以及建立全局规范的数据表示来实现这一目标，而对变化的支持却非常有限。相比之下，数据网格中的联邦式计算治理拥抱变化，也接受多种解释语境的存在。

让一个系统陷入一成不变的束缚，会使它变得脆弱。
——海外某生态学者

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

要让联邦式治理模式真正发挥作用，需要支撑性的组织结构、激励模型和架构。它们共同在尊重本地领域自主权的同时，推动形成全局互操作性决策和标准，并有效执行全局策略。

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

如前所述，如何在平台为所有领域及其数据产品制定并执行的全局标准化规则，与各领域自主决定的本地规则之间取得平衡，是一门艺术。

例如，领域数据模型应由最熟悉该领域的团队负责。“播客受众”数据模型的语义和语法定义，必须由“播客领域”团队负责。与此相反，如何识别“播客听众”则是一个全局性问题。播客听众是“用户”群体的一员，而“用户”是其上游限界上下文。用户可以跨越多个领域边界，并出现在其他领域中，例如“流媒体用户”。统一的识别方式能够关联“播客听众”和“流媒体听众”的相关信息。

以下是数据网格治理模型中相关要素的一个示例。它并不是完整示例，仅用于说明全局层面需要关注的问题。

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

许多在数据网格出现之前作为集中式职能存在的治理实践，在数据网格范式下已不再适用。

例如，过去强调对“黄金数据集”进行认证，并将其作为治理的核心职能。所谓黄金数据集，是指经过集中式质量控制和认证流程，并被标记为可信的数据集。而在数据网格模式下，这种做法不再适用。

原因在于，在此前的数据管理范式中，无论数据质量和格式如何，数据都会从业务领域的数据库中被提取出来，并集中存储到数据仓库或数据湖中。这就需要一个集中式团队对数据进行清洗、协调和加密处理。通常，这些工作由集中式治理团队负责。

数据网格则从根本上改变了这一点。领域数据集只有在本地领域内，根据预期的数据产品质量指标和全局标准化规则完成质量保障流程之后，才能成为数据产品。领域数据产品所有者最了解产生数据的领域运营细节，因此他们最有能力决定如何衡量本领域数据的质量。

尽管决策是本地化且自治的，但这些决策仍然需要遵守基于全局标准的质量建模和服务等级目标，即 SLO 规范。该标准由联邦式治理团队定义，并由平台自动执行。

下表展示了集中式数据治理模型，即数据湖和数据仓库治理模型，与数据网格治理模型之间的对比。

数据网格之前的治理方式	数据网格中的治理方式
集中式团队	联邦式团队
负责数据质量	负责定义如何建立质量模型
负责数据安全	负责定义数据安全要求，例如平台需要构建并自动监控的数据敏感级别
负责遵守相关法规	负责定义平台需要构建并自动监控的合规要求
集中式数据托管	按领域划分的联邦式数据托管
负责全局规范化数据建模	负责对多义数据元素进行建模，即跨越多个领域边界的数据元素
团队独立于各个领域之外	团队由各领域代表组成
目标是构建定义明确且静态的数据结构	目标是实现高效的网格运转，以适应不断变化的动态网格拓扑
采用单体式数据湖或数据仓库所使用的集中式技术	各领域使用自助式平台技术
根据受管数据表的数量或数据体量衡量成功	根据网络效应衡量成功，即网格中代表数据消费关系的连接数量
依赖人工干预的手动流程	由平台执行的自动化流程
试图防止错误发生	通过平台自动化能力检测错误并进行恢复

数据网格原则总结与高级逻辑架构

现在，让我们总结全文。本文讨论了数据网格的四项基本原则。

数据网格原则	作用
面向领域的去中心化数据所有权与架构	使创建和使用数据的生态系统能够随着数据源数量、用例数量和数据访问模型多样性的增加而扩展。扩展方式是不断增加网格上的自治节点。
数据即产品	使数据用户能够轻松发现、理解并安全地使用高质量数据，同时获得良好的使用体验。这些数据分布在多个领域之中。
自助式数据基础设施即平台	使领域团队能够借助平台抽象，自主创建和使用数据产品，从而隐藏构建、运行和维护安全且可互操作的数据产品所需面对的复杂性。
联邦式计算治理	使数据用户能够从独立数据产品的聚合与关联中获得价值。作为一个生态系统，数据网格遵循全局互操作性标准，而这些标准通过计算能力嵌入平台之中。

这些原则共同驱动了一种数据网格逻辑架构模型。该模型将分析型数据和操作型数据更紧密地组织在同一领域之下，同时尊重二者在底层技术上的差异。这些差异包括分析型数据的托管位置、处理操作型服务和分析型服务所使用的不同计算技术，以及不同的数据查询和访问方式等。

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

我希望到目前为止，我们已经建立起一种共同的语言和逻辑思维模型。基于这一模型，我们可以继续推进，进一步细化数据网格组件的蓝图，包括数据产品、平台，以及所需的标准化体系。