Data Mesh的原则和逻辑架构
原文链接：
https://martinfowler.com/articles/data-mesh-principles.html
作者简介：Zhamak是ThoughtWorks的首席技术顾问，专注于企业的分布式系统架构和数字平台策略。作为ThoughtWorks技术顾问委员会的成员，她为创建ThoughtWorks技术雷达做出了贡献。
我们渴望通过数据来增强和改善商业和生活的各个方面，这驱使我们在大规模管理数据方面进行范式转变。 尽管过去十年的技术进步已解决了数据量和数据处理计算的规模问题，但它们无法解决其他方面的规模问题：数据格局的变化，数据来源的泛滥，数据用例和用户的多样性 ，以及对变化的响应速度。 Data Mesh解决了这些问题，它由以下四个原则组成：面向领域的去中心化数据所有权和架构，数据即产品，自助服务数据基础设施即平台，联合治理。 每个原则都驱动着技术架构和人员组织结构的新的逻辑视图。
当前，许多企业面临的挑战在于如何在技术架构和人员组织层面形成数据驱动、运用数据建立竞争优势以及规模化地利用数据驱动价值，“从单体数据湖到分布式数据网格”对上述痛点有深入的理解（我鼓励您先阅读该文章）。它提供了一种替代的观点，该观点吸引了许多组织的注意力，并给我们带来了一个不同前景的希望。虽然这篇文章描述了这种观点，但它在很多设计和实现的细节上留下了让人想象的空间。 我并不想在本文中过分规范这些，以至于扼杀了大家实现Data Mesh的想象力和创造力。但是，我认为作为推动范式向前发展的垫脚石，本文只负责在架构层面规范它的定义。
本文是上述文章的后续， 它通过列举Data Mesh的基本原则和这些原则驱动的高级逻辑架构，总结出了Data Mesh方法。 在我之后写文章深入研究Data Mesh核心组件的详细架构之前，建立高级逻辑模型是非常必要的。 因此，如果您正在为Data Mesh寻求确切的工具和方法，那么本文可能会让您感到失望。 如果您正在寻求简单且无关技术细节的模型来建立描述该方法的通用语言，请快来。
合理划分数据
数据到底是什么？ 这个问题的答案取决于您问谁。从现阶段的视角来看， 我们将数据分为业务数据和分析型数据。 业务数据位于业务微服务背后的数据库中，它具有事务性，能够记录当前状态并且满足业务应用的需求。 分析型数据是一段时间内业务事实形成的聚合视图，它的数据模型通常被用来支持历史数据分析或未来趋势预测， 也用于机器学习的模型训练或生成分析报告。
目前，技术、架构和组织结构的现状都反映了业务与分析数据平面的差异，它们集成在一起但是又相互独立存在。这种差异使架构变得脆弱。 对于那些试图连接这两个平面，想要将数据从业务数据平面流转到分析平面然后再返回到业务数据平面的人来说，不断失败的ETL（提取，转换，加载）流程以及日益复杂的数据管道迷宫是一个很常见的现象。
图1：合理划分数据
分析型数据平面本身已经分叉为两套主要的架构和技术栈：数据湖和数据仓库。 数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。 在本文中， 我暂不考虑这两种技术栈之间的交叉：数据仓库试图去引入数据科学工作流，而数据湖则试图服务于数据分析师以及商业智能。前文中提到的“从单体数据湖到分布式数据网格”探讨了现有分析数据平面架构的挑战。
图2: 分析型数据的进一步划分-数据仓库
图3：分析型数据的进一步划分-数据湖
图3：分析型数据的进一步划分-数据湖
Data Mesh认可并尊重这两个数据平面之间的差异：数据不同的数据性质和拓扑结构，不同的用例，不同的数据消费者，以及不同的访问模式。 但是，它试图以不同的结构（一个基于领域而不是技术栈的倒置模型和拓扑结构）连接这两个平面，并且将关注点放在分析型数据平面上。 当今管理这两种数据原型的可用技术的差异不应导致组织，团队和工作人员的分离。 我认为，业务型的和事务性数据的技术和拓扑结构相对成熟，并且在很大程度上由微服务架构驱动。 数据隐藏在每个微服务的内部，并通过微服务的API进行控制和访问。 是的，还需要继续创新才能真正实现多云原生业务型数据库解决方案，但从架构的角度来看，业务型数据平面已经满足了业务的需求。 然而，管理和访问分析型数据仍然是规模化问题。 而这便是Data Mesh的关注点。
我相信，在将来的某个时刻，不断发展的技术，将使这两个平面更加紧密地联系在一起，但就目前而言，我建议将它们的关注点分开。
Data Mesh的核心原理和逻辑架构
Data Mesh的目标是为大规模地从分析型数据和历史事实中获得价值提供基础，以适应数据格局的不断变化、数据源和消费者的大量涌现，用例所需的转换和处理的多样性，对变化的响应速度。 为了实现此目标，我认为，任何Data Mesh的实现都应体现四个基本原则，以实现规模化的承诺，同时保证数据可用所需的质量和完整性：1）面向领域的去中心化的数据所有权和架构，2 ）数据即产品； 3）自助式数据基础设施即平台； 4）联合治理。
尽管我预见这些原则的实践、技术和实现会随着时间的推移而变化和成熟，但是这些原则会保持不变。
我有意让这四个原则在总体上是必要和充分的；以实现具有韧性的扩展，同时解决不兼容数据的孤岛和增加的运营成本的担忧。 让我们深入研究每个原理，然后设计支持该原理的概念架构。
领域所有权
Data Mesh的核心是将责任分散，并分配给最接近数据的人，从而能够支持持续的变更和扩展。问题是，如何分解和分散数据生态和它们的所有权？这里的组件是由分析数据，元数据和服务数据所需的算力组成。
Data Mesh沿着组织单元的交界线作为分解轴。现在我们的组织是基于他们的业务领域来划分的。这样的划分，在很大程度上局部化了持续变更和演进所带来的影响。因此，通过业务领域的上下文来划分数据的所有权是一个很好的选择。
在本文中，我将继续使用和之前文章相同的用例，一家数字媒体公司。你可以想象这家公司是基于领域来划分业务，各个业务部门都有支持运营的系统和团队。例如，podcasts（播客）业务，其团队和系统管理 podcast 发行物和其主持人；还有 artists （艺术家）业务，其团队和系统负责artists的入职并支付其费用，等等。Data Mesh 的观点是分析数据的所有权和其提供的服务应该遵从于这些领域的划分。例如，对于管理 podcasts，以及提供 API 来发布 podcasts 的团队，他们应该同时提供过去一段时间内已经发布的“播客” 和收听率数据。想要更深入的了解这个划分原则，可以参考《面向领域的数据分解和所有权》这篇文章。
逻辑架构：面向领域的数据和计算
为了推动这样的划分，我们需要建立一个把分析数据安放到各个领域去的架构模型。在这个架构中，某领域暴露给组织中其他领域的接口，不仅仅暴露业务能力，还暴露对于这个领域的分析数据的访问能力。例如，Podcast 这个领域，不仅提供了“创建新一集的 podcast”的API，也提供了获取“过去n个月的所有 podcasts 数据”的接口。这意味着该架构必须移除所有阻力或者耦合，以便让领域对外暴露分析数据，发布计算数据的代码，这必须是独立于其他领域的。为了扩展，该架构必须支持各领域团队的自治，使得各领域团队能够自主发布和部署其业务系统和分析数据系统。
下面这个例子展示了面向领域的数据所有权原则。图例只是逻辑上和示例性的表示，并不试图展示完整的例子。
每个领域可以暴露一个或多个业务型API，以及一个或多个分析型数据端点。
图4: 注意：领域，及其包含的分析数据能力和业务能力
自然地，各个领域可以依赖其他领域的业务和分析数据 API。在下面这个例子中，podcasts 领域消费 users 领域提供的用户更新的分析数据，从而通过 podcasts 听众数据集，来提供 podcasts 听众人口统计全貌。
图5：示例：面向领域划分分析数据和业务能力所有权
在这个例子中，我使用了命令式的语言来访问业务数据或者能力，例如付钱给 artists。这只是想要强调访问业务数据和分析数据意图之间的不同。实际上业务API会使用一种更表意的方式来实现，例如访问 RESTFul 资源或者通过GraphQL 查询。
数据即产品
现有分析型数据架构的挑战之一是探索，理解，信任以及最终使用优质数据的高摩擦和高成本。 如果不解决，随着提供数据（即领域）的场所和团队数量的增加，该问题只会伴随着数据网格加剧。 这是Data Mesh 第一原则去中心化将会造成的结果。数据即产品原则旨在解决数据质量和陈旧的数据孤岛问题； 或Gartner所说的“暗数据”——“在正常的商业活动中收集，处理和存储的信息资产，通常不能用于其他目的”。领域提供的分析数据须被视为产品，数据的消费者也应该被视为客户。
“从单体数据湖到分布式数据网格”一文列举了一系列能力，包括可发现性，安全性，可探索性，可理解性，可信赖性等，所以在实现Data Mesh时应该把领域数据视为一种产品。这片文章还详细介绍了团队必须引入的领域数据产品负责人，该角色负责定义客观的度量指标来确保数据作为产品交付。这些度量指标包括数据质量，缩短数据消耗的前置时间，以及一般而言的通过净推荐值（Net Promoter Score）所体现的数据用户满意度。 领域数据产品负责人必须深入了解数据用户是谁，他们如何使用数据，以及他们消费数据的顺手方法。 对数据用户的深入了解可以设计出满足其需求的数据产品接口。实际上，网格上的大多数数据产品，都有一些常规的用户角色，比如数据分析师和数据科学家，基于他们独有的工具和需求来使用数据。 所有数据产品都可以开发标准化的接口来支持消费者。 数据用户与产品负责人之间的对话是建立数据产品接口的必要环节。
每个领域都会有数据产品开发人员，他们负责构建，维护和提供各自领域的数据产品。 数据产品开发人员将与该领域的其他开发人员一起工作。 每个领域团队可以服务一个或多个数据产品。 也可以组建新的团队，给那些不适合现有业务领域的数据产品提供服务。
注意：与过去的范式相比，这是一种责任的倒置模型。 数据质量的责任向上游转移，尽可能靠近数据源。
逻辑架构：将数据产品视为架构量子
在体系结构上，为了支持数据作为领域可以自主服务或使用的产品，Data mesh引入了数据产品的概念，并作为其架构量子。由演进式架构定义的架构量子是最小的架构单元，它可以独立部署，具有高度的功能内聚性，并包含其功能所需的所有结构元素。
数据产品是网格上的节点，它封装了其功能所需的三个结构组件，作为产品提供对领域分析数据的访问。
- 代码：包括
(a)数据流水线代码，负责消费，转换和服务来自业务领域系统或者上游数据产品的数据；
(b) API代码，提供对数据、语义和语法模式、可观察性指标和其他元数据的访问;
(c)强制约束性代码，包含诸如访问控制策略，合规性，来源等。
- 数据和元数据: 这就是我们的讨论内容，以多种语言形态提供底层的分析和历史数据。根据领域数据的性质及其消费模型，数据可以通过事件，批处理文件、关系型数据表、图等方式提供给消费者，同时保持相同的语义。为了使数据可用，需要定义一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等。有些元数据是数据所固有的，例如语法定义，而有些元数据通过计算治理传达数据特征，从而实现预期行为，例如 访问控制策略。
- 基础设施:基础设施组件支持构建、部署和运行数据产品代码，以及存储和访问大数据和元数据。
图6：数据产品的组成部分
下面的示例建立在上一节的基础上，展示了数据产品作为架构量子。图例只包括示例内容，并不试图包括完整的设计和实现细节。虽然这依旧是一种逻辑表示，但它离真实实现更近了一步。
图 7：注意：领域，及其包含的分析数据能力和业务能力
图 8：服务于面向领域分析数据的数据产品
注意:Data mesh模型不同于过去的范式，在过去的范式中，数据管道作为独立组件管理，与它们产生的数据无关; 基础设施，比如数据仓库或数据湖存储帐户的实例，通常会在许多数据集之间共享。数据产品是所有组件(代码、数据和基础设施)在领域限界上下文粒度上的组合。
自助数据基础设施平台
可以想象，要构建，部署，执行，监控和访问一个不起眼的六边形（即数据产品），需要搭建和运行相当多的基础设施。用来提供这些基础设施的技术是相对专业的，并且难以在各个领域中复制。最重要的是，团队能够自主管理其数据产品的唯一方法，就是团队可以访问基础设施的高级抽象——这层抽象移除了搭建数据产品和管理数据产品生命周期的复杂性和难度。这就需要一种新的原则，即使领域自治的自助数据基础设施即平台。
数据平台可以被视为对已经存在的可以运行和监控各种服务的交付平台的延伸。但现实是，用来操作数据产品的底层技术栈与针对业务服务的交付平台 所使用的技术栈大相径庭。这完全是由于大数据平台与业务平台之间技术栈的差异所导致的。例如，领域团队可能使用Docker容器来部署其服务，而交付平台使用Kubernetes进行编排；但是，相邻的数据产品可能正在以Spark作业的形式在Databricks群集上运行数据流水线代码。这需要搭建和连接两组非常不同的基础设施，数据网格之前的技术并不需要这种级别的互连性。我个人的希望是，在合理的地方开始看到业务和数据基础设施的融合。例如，我希望能够在和业务系统相同的编排系统上运行Spark，比如Kubernetes。
现实是，为了使多面手的开发人员可以开发分析数据产品，自助平台除了简化产品搭建外，还需要针对既有的领域开发人员提供一套新的工具和接口类别。自助数据平台必须能创建工具，以支持领域数据产品开发人员在创建、维护和运行工作流时减少对专业技术知识的依赖。上篇文章中提到了自助数据平台提供一系列功能列表，包括访问：可扩展的不同类型的数据存储，数据产品模式，数据管道声明和编排，数据产品血缘，计算和数据本地性等。
逻辑架构：多平面数据平台
自助服务平台功能可分为多个类别或平面，如模型中所述。注意：平面对存在层面的抽象表达-他们相互集成但独立。类似于物理或意识平面，或网络中的控制和数据平面。平面既不是层，也不意味着森严的分层访问模型。
图9：注意：平台中一个通过自服务接口提供了多种相关能力的平面
自助平台可以具有多个平面，每个平面服务于不同类型的用户。在以下示例中，列出了三个不同的数据平台平面：
- 数据基础设施配置平面：支持底层基础设施的配置，这是运行数据产品和网格所必需的。其中包括配置分布式文件存储，存储帐户，访问控制管理系统，运行数据产品内部代码的编排引擎，以及为数据产品集群提供分布式查询引擎等。我希望其他任何数据平台或高级数据产品开发人员都能直接使用这个平面提供的接口。这是一个相当底层的数据基础设施生命周期管理平面。
- 数据产品开发人员体验平面：这是典型的数据产品开发人员主要使用的接口。这些接口抽象了许多复杂的内容，以支持数据产品开发人员的工作流程。它提供了比“配置平面”更高的抽象级别。它使用简单的声明性接口来管理数据产品的生命周期。它会自动横切一些关注点，这些关注点被定义为为一组标准和全局约定，适用于所有数据产品及其接口。
- 数据网格监督平面：有些能力最好能在网格（数据产品形成的网络）层面全局地提供。尽管每个接口的实现可能都依赖于单独的数据产品功能，但在网格层面提供这些功能更为方便。例如，最好通过搜索或浏览数据产品的网格来提供发现特定用例的数据产品的能力；或者最好通过在数据网格上执行跨数据产品的数据语义查询操作来创造更高阶的洞见。
以下模型仅是示例性的，并不完整。尽管图中平面间存在层级，但并不表示平面间存在严格的层级关系。
图10：多平面的自服务数据平台 其中DP指的是数据产品
联合治理
正如你所看到的，数据网格遵循分布式系统架构，由独立的数据产品组成，每个数据产品具有独立的生命周期，通常由独立团队构建和部署 。然而，在大多数现实场景下，为了通过高阶数据集、洞见以及机器智能的形式获取价值，独立的数据产品需要相互操作；并能够让数据相互关联、合并、找到交集，或者对数据进行大规模的图或集合操作。为了实现这些操作，数据网格的实现需要一个治理模型，这个模型包含去中心化，领域自治，支持全局标准化的互操作性、动态拓扑，以及最重要的是由平台自动执行决策。我称之为联合计算治理。它是由领域数据产品经理和数据平台产品经理组成的联合所领导的决策模型，具备自治权和领域内的决策能力，同时创建和遵守一套全局规则，这套规则应用于所有数据产品及其接口，以确保一个健康和可互操作的生态系统。该小组有一项棘手的工作：如何保持中央中心化和去中心化之间的平衡；哪些决策需要作用于单个领域，那些决策需要作用于所有领域。 最终，全局决策有一个目的，即通过发现和组合数据产品来创造互操作性和复杂的网络效应。
Data mesh中治理的优先级不同于传统的分析型数据管理系统。虽然它们最终都希望从数据中获取价值，但是传统的数据治理试图通过中心化的决策权来达成目标并建立全局规范的数据呈现方式，但难以支持变更。相反的是， Data mesh 的联合计算治理拥抱变化和多种解释性上下文。
将系统置于恒定状态会导致演进的脆弱。-- C.S. Holling, ecologist
逻辑架构：向网格中嵌入的计算策略
支持型的组织结构、激励模型和架构对于联合治理模型的运行必不可少：它们有助于在尊重本地领域自治的同时，制定全局互操作性决策和标准，并有效实施全局政策。
图11：注意：联合计算治理模型
如前所述，哪些应该针对所有领域和其数据产品进行全局标准化，实施，甚至强制执行？哪些应该留给领域自己决策？在这两个问题之间作出平衡是一门艺术。例如，领域数据模型应该是领域自身需要关注的问题，因为领域最熟悉它。就像，如何定义“播客受众”数据模型的语义和语法，这件事情必须交给“播客领域”团队。然而，相比之下，如何识别“播客听众”是一个全局关注的问题。podcast 听众是“用户”群体（其上游限界上下文）的成员，他们可以跨越领域的边界并同时存在于“用户播放流”之类的其他领域。统一的标识让我们可以关联既是“podcast听众”又是“播放流听众”的“用户”的信息。
以下是 data mesh管理模型中涉及的元素的示例。 这不是一个全面的例子，仅说明了在全局范围内的相关问题。
图12：联合治理包含的元素示例：团队，动机//TODO，自动实现和全局标准化
作为中心化的职能， 数据网格之前的很多治理实践，不再适用于数据网格。例如，过去被认为非常重要的黄金数据集认证（即经过集中质量控制和认证过程并标记为可信赖的数据集）作为中心治理功能将不再适用。这源于以下事实：在以前的数据管理范例中，无论质量和格式如何，数据都是从业务领域数据库中提取，并集中存储在数据仓库或数据湖中，现在需要中心化的团队来对数据进行清洗，整理和加密；这通常由中央治理小组负责。数据网格完全分散了这些问题。领域数据集仅在领域内通过了质量保障处理（满足预期的数据产品质量指标和全局标准化规则）之后，才成为数据产品。领域数据产品经理最先决定如何衡量其领域的数据质量，因为他们最早了解产生数据的领域操作的详细信息。尽管有这样的本地化决策和自治权，但它们仍需要遵循由全局联合治理团队定义并由平台自动化的全局质量标准和SLO（服务水平目标）规格进行建模。
下表展示了中心化的数据治理（如数据湖、数据仓库）模型和数据网格之间的对比。
|
Data mesh之前的数据治理 |
Data mesh的数据治理 |
|
中心化的治理团队 |
联合治理团队 |
|
负责数据质量 |
负责定义如何对构成质量的模型进行建模 |
|
负责数据安全 |
负责定义数据安全的各个方面，即平台内置和自动监控的数据敏感度级别 |
|
负责遵守法规 |
负责定义平台的法规要求，将其构建到平台中并自动监控 |
|
中心化的数据监管 |
领域的联合数据监管 |
|
负责全局规范数据建模 |
负责建模多义性数据-跨越多个领域边界的数据元素 |
|
团队独立于领域 |
团队由领域代表组成 |
|
旨在定义明确的数据静态结构 |
旨在实现有效的网格操作，拥抱网格的持续变化和动态拓扑 |
|
单体数据湖/数据仓库使用的中心化技术 |
每个领域都使用的自助平台技术 |
|
通过管理的数据量或数据表的数量多少来衡量是否成功 |
基于网络效应 (代表网格上数据消耗的连接)来度量成功 |
|
手动的流程，需要人工干预 |
由平台实现的自动化流程 |
|
可以预防错误 |
通过平台的自动化流程监测问题和恢复 |
原则总结与顶层逻辑架构
综上所述，我们讨论了支撑Data mesh的四个原则。
- 面向领域的去中心化数据所有权和架构
因此，生产和消费数据的生态系统可以随着数据源的数量、用例的数量和数据访问模型的多样性的增加而扩展; 只需增加网格上的自治节点就可以实现这种扩展。
- 数据即产品
因此，针对分布在多个领域的数据，其使用者可以很方便地去发现、理解以及安全地去使用这些高质量的数据，同时获得良好的消费者体验。
- 自助数据基础设施即平台
因此，领域团队就可以通过平台抽象自主地创建和使用数据产品，从而隐藏了构建、执行和维护安全且可互操作的数据产品的复杂性。
- 联合治理
因此，数据用户可以从独立数据产品的聚合和关联中获得价值——数据网格就像遵循全局互操作性标准的生态系统，通过计算将标准整合到平台中。
这些原理形成了一个逻辑架构模型，使分析数据和业务数据在同一个领域中更加紧密地联系在一起, 同时尊重它们的基础技术的差异。这些差异包括分析数据的存储位置，处理业务服务和分析服务的不同计算机技术，查询和访问数据的不同方式等等。
图13：数据网格的逻辑架构
我希望到这里我们已经建立了一套通用的语言和逻辑思维模型，可以用来进一步详述Data Mesh组件的蓝图，例如数据产品，数据平台和必需的标准。
