我们希望通过数据来增强和改善业务和生活的各个方面，这要求我们大规模管理数据的方式发生范式转变。 虽然过去十年的技术进步已经解决了数据量和数据处理计算的规模，但它们未能解决其他方面的规模问题：数据格局的变化、数据源的扩散、数据用例和用户的多样性 ，以及对变化的响应速度。 数据网格解决了这些维度，建立在四个原则上：面向领域的去中心化数据所有权和架构、数据作为产品、自助数据基础设施作为平台以及联合计算治理。 每个原则都推动了技术架构和组织结构的新逻辑视图。
内容
- 数据的巨大鸿沟
- 数据网格的核心原理和逻辑架构
- 领域所有权
- 逻辑架构：面向领域的数据和计算
- 数据作为产品
- 逻辑架构：数据产品架构量子
- 自助数据平台
- 逻辑架构：多平面数据平台
- 联合计算治理
- 逻辑架构：嵌入在网格中的计算策略
- 原理总结和高层逻辑架构
最初的文章，如何从单一数据湖转移到分布式数据网格——我鼓励你在回到这里之前阅读它——理解当今架构和组织挑战的痛点，以便成为数据驱动的，使用数据竞争，或使用大规模数据来推动价值。它提供了另一种视角，此后引起了许多组织的关注，并为不同的未来带来了希望。虽然最初的文章描述了这种方法，但它留下了许多设计和实现的细节。我无意在本文中过于规范，扼杀围绕数据网格实现的想象力和创造力。然而，我认为它只负责澄清数据网格的架构方面，作为推动范式向前发展的垫脚石。
这篇文章是为了跟进而写的。它通过列举其基础原则以及这些原则驱动的高级逻辑架构来总结数据网格方法。在我在以后的文章中深入研究数据网格核心组件的详细架构之前，建立高级逻辑模型是必要的基础。因此，如果您正在寻找有关数据网格的确切工具和配方的处方，本文可能会让您失望。如果您正在寻找一种建立通用语言的简单且与技术无关的模型，那就来吧。
数据的巨大鸿沟
数据的真正含义是什么？答案取决于你问谁。当今的格局分为运营数据和分析数据。操作数据位于微服务提供的业务功能背后的数据库中，具有事务性，保持当前状态并满足运行业务的应用程序的需求。分析数据是业务事实随时间推移的时间和汇总视图，通常被建模以提供回顾性或未来视角的见解；它训练 ML 模型或提供分析报告。
技术、架构和组织设计的当前状态反映了这两个数据平面的分歧——两个存在层次，集成但分离。这种分歧导致了脆弱的架构。不断失败的 ETL（提取、转换、加载）作业和日益复杂的数据管道迷宫对于许多试图连接这两个平面、将数据从操作数据平面流向分析平面并返回到操作平面。
Figure 1: The great divide of data
分析数据平面本身已经分化为两个主要的架构和技术栈：数据湖和数据仓库； 数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。 在这次对话中，我将两个技术堆栈之间的关系放在一边：数据仓库试图加入数据科学工作流，数据湖试图为数据分析师和商业智能提供服务。 最初关于数据网格的文章探讨了现有分析数据平面架构的挑战。
Figure 2: Further divide of analytical data - warehouse
Figure 3: Further divide of analytical data - lake
数据网格承认并尊重这两个层面之间的差异：数据的性质和拓扑、不同的用例、数据消费者的个人角色，以及最终的不同访问模式。然而，它试图在不同的结构下连接这两个平面 - 基于域而不是技术堆栈的倒置模型和拓扑 - 重点放在分析数据平面上。当今管理这两种数据原型的可用技术的差异不应导致组织、团队和工作人员的分离。在我看来，操作和事务数据的技术和拓扑是比较成熟的，主要是由微服务架构驱动的；数据隐藏在每个微服务的内部，通过微服务的 API 进行控制和访问。是的，真正实现多云原生操作数据库解决方案仍有创新空间，但从架构的角度来看，它满足了业务的需求。然而，分析数据的管理和访问仍然是一个大规模的摩擦点。这是数据网格关注的地方。
我确实相信，在未来的某个时候，我们的技术会不断发展，让这两个飞机更加靠近，但就目前而言，我建议我们将它们的关注点分开。
数据网格的核心原理和逻辑架构
数据网格的目标是为从大规模分析数据和历史事实中获取价值奠定基础——大规模应用于数据环境的不断变化、数据源和消费者的扩散、用例所需的转换和处理的多样性、速度对变化的反应。为了实现这一目标，我建议任何数据网格实现都包含四个基本原则，以实现规模化承诺，同时提供使数据可用所需的质量和完整性保证：1）面向领域的分散数据所有权和架构，2 ) 作为产品的数据，3) 作为平台的自助数据基础设施，以及 4) 联合计算治理。
虽然我预计这些原则的实践、技术和实现会随着时间的推移而变化和成熟，但这些原则保持不变。
我打算让这四项原则共同成为必要和充分的；实现弹性扩展，同时解决不兼容数据孤岛或运营成本增加的问题。让我们深入研究每个原则，然后设计支持它的概念架构。
领域所有权
数据网格的核心是分散和将责任分配给最接近数据的人，以支持持续的变化和可扩展性。问题是，我们如何分解和分散数据生态系统的组成部分及其所有权。这里的组件由分析数据、其元数据以及为它提供服务所需的计算组成。
数据网格遵循组织单元的接缝作为分解轴。我们今天的组织是根据其业务领域进行分解的。这种分解将持续变化和进化的影响——在大多数情况下——本地化到域的有界上下文中。因此，使业务领域的有界上下文成为数据所有权分配的良好候选者。
在本文中，我将继续使用与原始文章“一家数字媒体公司”相同的用例。可以想象，媒体公司根据“播客”、管理播客发布的团队和系统及其主机等领域来划分其运营，因此支持运营的系统和团队； “艺术家”、管理入职和付费艺术家的团队和系统等。数据网格认为分析数据的所有权和服务应该尊重这些领域。例如，管理“播客”的团队在提供用于发布播客的 API 的同时，还应负责提供代表“已发布播客”随时间推移的历史数据以及其他事实，例如随时间推移的“收听率”。要更深入地了解这一原则，请参阅面向领域的数据分解和所有权。
逻辑架构：面向领域的数据和计算
为了促进这种分解，我们需要建模一个按域排列分析数据的架构。在此架构中，域与组织其他部分的接口不仅包括操作能力，还包括对域所服务的分析数据的访问。例如，“播客”域提供了操作 API 来“创建新的播客剧集”，还提供了一个分析数据端点，用于检索“过去 <n> 个月内的所有播客剧集数据”。这意味着架构必须消除任何摩擦或耦合，以让域提供其分析数据并发布计算数据的代码，独立于其他域。为了扩展，架构必须支持领域团队在发布和部署其操作或分析数据系统方面的自主权。
以下示例演示了面向领域的数据所有权原则。这些图只是逻辑表示和示例性的。它们并不打算完整。
每个域可以公开一个或多个操作 API，以及一个或多个分析数据端点
Figure 4: Notation: domain, its analytical data and operational capabilities
自然地，每个域都可以依赖于其他域的操作和分析数据端点。 在以下示例中，“播客”域使用来自“用户”域的“用户更新”分析数据，因此它可以通过其“播客听众人口统计”数据集提供播客听众的人口统计图。
Figure 5: Example: domain oriented ownership of analytical data in addition to operational capabilities
注意：在示例中，我使用了一种命令式语言来访问操作数据或功能，例如“付费艺术家”。这只是为了强调访问操作数据与分析数据的意图之间的区别。我确实认识到，实际上操作 API 是通过更具声明性的接口实现的，例如访问 RESTful 资源或 GraphQL 查询。
数据作为产品
现有分析数据架构的挑战之一是发现、理解、信任和最终使用高质量数据的高摩擦和成本。如果不解决，这个问题只会随着数据网格的增加而加剧，因为提供数据（域）的地方和团队的数量会增加。这将是我们第一个去中心化原则的结果。数据即产品原则旨在解决数据质量和古老的数据孤岛问题；或者正如 Gartner 所说的暗数据——“组织在日常业务活动中收集、处理和存储的信息资产，但通常无法用于其他目的”。域提供的分析数据必须被视为一种产品，而该数据的消费者应该被视为客户——快乐和高兴的客户。
原始文章列举了一系列能力，包括可发现性、安全性、可探索性、可理解性、可信赖性等，数据网格实现应支持将域数据视为产品。它还详细介绍了组织必须引入的领域数据产品所有者等角色，负责确保数据作为产品交付的客观措施。这些措施包括数据质量、减少数据消耗的前置时间，以及通过净推荐值获得的总体数据用户满意度。领域数据产品所有者必须深入了解数据用户是谁，他们如何使用数据，以及他们习惯于使用数据的原生方法是什么。这种对数据用户的深入了解导致设计出满足他们需求的数据产品界面。实际上，对于网格上的大多数数据产品，都有一些具有独特工具和期望的传统角色、数据分析师和数据科学家。所有数据产品都可以开发标准化的接口来支持它们。数据用户与产品所有者之间的对话是建立数据产品接口的必要环节。
每个域将包括数据产品开发人员角色，负责构建、维护和服务域的数据产品。数据产品开发人员将与该领域的其他开发人员一起工作。每个领域团队可以提供一个或多个数据产品。也可以组建新的团队来提供不适合现有运营领域的数据产品。
注意：与过去的范例相比，这是一种倒置的责任模型。数据质量的责任在尽可能靠近数据源的地方向上游转移。
逻辑架构：数据产生架构量子
在架构上，为了支持数据作为域可以自主服务或消费的产品，数据网格引入了数据产品的概念作为其架构量子。进化架构定义的架构量子是可以独立部署且具有高功能凝聚力的最小架构单元，并包含其功能所需的所有结构元素。
数据产品是网格上的节点，它封装了其功能所需的三个结构组件，作为产品提供对域分析数据的访问。
- 代码：它包括 (a) 负责消费、转换和服务上游数据的数据管道代码——从域的操作系统或上游数据产品接收的数据； (b) 提供对数据、语义和语法模式、可观察性指标和其他元数据的访问的 API 代码； (c) 用于执行特征的代码，例如访问控制策略、合规性、出处等。
- 数据和元数据：这就是我们在这里的全部目的，多语言形式的基础分析和历史数据。根据领域数据的性质及其消费模型，数据可以作为事件、批处理文件、关系表、图形等，同时保持相同的语义。为了使数据可用，有一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等；数据固有的元数据，例如它的语义定义，以及传达计算治理使用的特征以实现预期行为的元数据，例如访问控制策略。
- 基础设施：基础设施组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。
Figure 6: Data product components as one architectural quantum
以下示例建立在上一节的基础上，将数据产品演示为架构量子。 该图仅包含示例内容，并不旨在完整或包含所有设计和实施细节。 虽然这仍然是一个逻辑表示，但它越来越接近物理实现。
Figure 7: Notation: domain, its (analytical) data product and operational system
Figure 8: Data products serving the domain-oriented analytical data
注意：数据网格模型不同于过去将管道（代码）作为与其产生的数据的独立组件进行管理的范例；通常基础设施，如仓库或湖泊存储帐户的实例，在许多数据集之间共享。数据产品是所有组件（代码、数据和基础设施）的组合，以域的有界上下文为粒度。
自助数据平台
正如您可以想象的那样，要构建、部署、执行、监控和访问一个不起眼的六边形——一种数据产品——需要配置和运行相当多的基础设施；提供这种基础设施所需的技能是专门的，很难在每个领域中复制。最重要的是，团队可以自主拥有他们的数据产品的唯一方法是访问高级抽象的基础设施，从而消除配置和管理数据产品生命周期的复杂性和摩擦。这需要一个新的原则，将自助数据基础设施作为实现域自治的平台。
数据平台可以被认为是已经存在的用于运行和监控服务的交付平台的扩展。然而，如今操作数据产品的底层技术堆栈与服务交付平台看起来非常不同。这仅仅是由于大数据技术堆栈与操作平台的差异。例如，领域团队可能将他们的服务部署为 Docker 容器，而交付平台使用 Kubernetes 进行编排；但是，相邻的数据产品可能会在 Databricks 集群上将其管道代码作为 Spark 作业运行。这需要配置和连接两组非常不同的基础设施，在数据网格之前不需要这种级别的互操作性和互连性。我个人的希望是，我们开始看到运营和数据基础设施在有意义的地方融合。例如，也许在同一个编排系统上运行 Spark，例如Kubernetes。
实际上，为了使通才开发人员能够访问分析数据产品开发，对于现有的域开发人员配置文件，自助服务平台除了简化配置之外还需要提供一种新的工具和接口。自助数据平台必须创建工具，以支持域数据产品开发人员创建、维护和运行数据产品的工作流程，而现有技术所假定的专业知识较少；自助式基础设施必须具备降低当前成本和构建数据产品所需的专业化能力。最初的文章包括自助数据平台提供的一系列功能，包括访问可扩展的多语言数据存储、数据产品模式、数据管道声明和编排、数据产品沿袭、计算和数据局部性等。
逻辑架构：多平面数据平台
自助平台功能分为模型中所称的多个类别或平面。注意：一个位面代表了一个存在层次——既整合又分离。类似于物理和意识平面，或网络中的控制和数据平面。平面既不是层，也不意味着强大的分层访问模型。
Figure 9: Notation: A platform plane that provides a number of related capabilities through self-serve interfaces
自助服务平台可以有多个平面，每个平面服务于不同的用户档案。在以下示例中，列出了三个不同的数据平台平面：
- 数据基础设施供应平面：支持运行数据产品组件和产品网格所需的底层基础设施供应。这包括提供分布式文件存储、存储帐户、访问控制管理系统、运行数据产品内部代码的编排、在数据产品图上提供分布式查询引擎等。我希望其他数据平台平面或者只有高级数据产品开发人员直接使用此接口。这是一个相当低级的数据基础设施生命周期管理平面。
- 数据产品开发者体验平面：这是典型的数据产品开发者使用的主要界面。该接口抽象了支持数据产品开发人员工作流所需的许多复杂性。它提供了比“供应平面”更高级别的抽象。它使用简单的声明式接口来管理数据产品的生命周期。它自动实现被定义为一组标准和全局约定的横切关注点，适用于所有数据产品及其接口。
- 数据网格监督平面：有一组最好在网格级别提供的功能 - 连接数据产品的图形 - 全局。虽然这些接口中的每一个的实现都可能依赖于单独的数据产品功能，但在网格级别提供这些功能会更方便。例如，发现特定用例的数据产品的能力最好通过搜索或浏览数据产品的网格来提供；或关联多个数据产品以创建更高阶的洞察力，最好通过执行可以跨网格上的多个数据产品操作的数据语义查询来提供。
以下模型仅是示例性的，并不打算完整。虽然平面的层次结构是可取的，但下面没有暗示严格的分层。
Figure 10: Multiple planes of self-serve data platform *DP stands for a data product
联合计算治理
如您所见，数据网格遵循分布式系统架构；一组具有独立生命周期的独立数据产品，由可能的独立团队构建和部署。然而，对于大多数用例而言，为了以高阶数据集、洞察力或机器智能的形式获得价值，这些独立的数据产品需要互操作；能够关联它们、创建联合、查找交点或执行其他图形或对它们进行大规模设置操作。为了使任何这些操作成为可能，数据网格实现需要一个治理模型，该模型包含去中心化和域自主权、通过全球标准化的互操作性、动态拓扑以及最重要的是平台自动执行决策。我称之为联合计算治理。由域数据产品所有者和数据平台产品所有者联合领导的决策模型，具有自治和域本地决策权，同时创建并遵守一组全局规则——适用于所有数据产品及其接口的规则——以确保健康和可互操作的生态系统。该集团有一项艰巨的工作：保持集中和分散之间的平衡；哪些决策需要本地化到每个域，哪些决策应该针对所有域全局进行。最终，全球决策只有一个目的，即通过数据产品的发现和组合创造互操作性和复合网络效应。
数据网格中治理的优先级不同于分析数据管理系统的传统治理。虽然他们最终都开始从数据中获取价值，但传统的数据治理试图通过集中决策来实现这一目标，并在对变更的支持最少的情况下建立数据的全球规范表示。相比之下，数据网格的联合计算治理包含变化和多种解释上下文。
将系统置于恒定的紧身衣中可能会导致脆弱性演变。
——C.S. Holling，生态学家
逻辑架构：嵌入在网格中的计算策略
支持性的组织结构、激励模型和架构对于联邦治理模型的运作是必要的：达成互操作性的全球决策和标准，同时尊重本地域的自主权，并有效地实施全球政策。
Figure 11: Notation: federated computational governance model
如前所述，在全球标准化、平台对所有领域及其数据产品实施和强制执行的内容与由领域决定的内容之间取得平衡，是一门艺术。例如，域数据模型是一个应该本地化到最熟悉它的域的关注点。例如，“播客受众”数据模型的语义和语法如何定义必须留给“播客领域”团队。然而相比之下，关于如何识别“播客听众”的决定是一个全球关注的问题。播客听众是“用户”群体的成员——它的上游有界上下文——他们可以跨越域的边界并在其他域中找到，例如“用户播放流”。统一标识允许关联关于既是“播客听众”又是“蒸汽听众”的“用户”的信息。
以下是数据网格治理模型中涉及的元素示例。这不是一个全面的例子，只是说明了全球层面的相关问题。
Figure 12: : Example of elements of a federated computational governance: teams, incentives, automated implementation, and globally standardized aspects of data mesh
数据网格前治理的许多实践，作为一个集中的功能，不再适用于数据网格范式。例如，过去强调黄金数据集的认证——经过集中质量控制和认证并被标记为可信赖的数据集——作为治理的核心功能不再相关。这源于这样一个事实，即在以前的数据管理范例中，无论质量和格式如何，数据都从运营域的数据库中提取并集中存储在仓库或湖泊中，现在需要一个集中的团队进行清理、协调及其加密过程；通常在集中治理组的监管下。数据网格完全分散了这种担忧。域数据集只有在域内，根据预期的数据产品质量指标和全球标准化规则，经过质量保证过程后，才成为数据产品。领域数据产品所有者最适合决定如何衡量其领域的数据质量，因为他们首先要了解产生数据的领域操作的细节。尽管有这样的本地化决策和自主权，但他们需要遵守基于全球标准的 SLO 质量和规范建模，由全球联合治理团队定义，并由平台自动化。
下表显示了数据治理的集中式（数据湖、数据仓库）模型与数据网格之间的对比。
| 预数据网格治理方面 | 数据网格治理方面 |
|---|---|
| 中心化团队 | 联合团队 |
| 负责数据质量 | 负责定义如何对构成质量的内容进行建模 |
| 负责数据安全 | 负责定义数据安全的各个方面，即平台自动构建和监控的数据敏感度级别 |
| 负责遵守法规 | 负责定义平台自动构建和监控的法规要求 |
| 数据集中保管 | 按域对数据进行联合托管 |
| 负责全球规范数据建模 | 负责建模多义词 - 跨越多个领域边界的数据元素 |
| 团队独立于域 | 团队由领域代表组成 |
| 以定义明确的静态数据结构为目标 | 旨在实现有效的网格操作，包括网格的连续变化和动态拓扑 |
| 单体湖/仓库使用的集中技术 | 每个域使用的自助平台技术 |
| 根据管理数据（表格）的数量或数量衡量成功 | 基于网络效应衡量成功 - 表示网格上数据消耗的连接 |
| 人工干预的手动流程 | 平台实现的自动化流程 |
| 防止错误 | 通过平台的自动处理检测错误并进行恢复 |
原理总结和高层逻辑架构
让我们把它们放在一起，我们讨论了支撑数据网格的四个原则：
| 面向领域的去中心化数据所有权和架构 | 因此，随着数据源数量、用例数量和数据访问模型多样性的增加，创建和使用数据的生态系统可以扩展； 只需增加网格上的自治节点。 |
| 数据作为产品 | 让数据用户可以轻松地发现、理解和安全地使用高质量的数据并获得愉快的体验； 分布在多个域中的数据。 |
| 作为平台的自助数据基础设施 | 因此，领域团队可以使用平台抽象自主创建和使用数据产品，从而隐藏构建、执行和维护安全且可互操作的数据产品的复杂性。 |
| 联合计算治理 | 因此，数据用户可以从独立数据产品的聚合和关联中获得价值——网格表现为遵循全球互操作性标准的生态系统； 以计算方式融入平台的标准。 |
这些原则推动了一个逻辑架构模型，该模型在将分析数据和操作数据在同一域下更紧密地结合在一起的同时，尊重它们的基础技术差异。 这些差异包括分析数据的托管位置、用于处理操作服务与分析服务的不同计算技术、查询和访问数据的不同方式等。
Figure 13: Logical architecture of data mesh approach
我希望到此为止，我们现在已经建立了一种通用语言和一种逻辑思维模型，我们可以共同推进网格组件的详细蓝图，例如数据产品、平台和所需的标准化。
原文：https://martinfowler.com/articles/data-mesh-principles.html