“我想指出，所提供的链接都不是附属的，我从本文中提到的公司中没有任何收获。我做这一切是因为直到最近我才听说过数据网格，我很期待这次活动，并希望在此之前深入了解一下。我还认为这可能会让其他人感兴趣，并付出了额外的努力以清晰简洁的方式分享我的笔记。 ”

本文/报告的目的是根据 Zhamak Dehghani 在即将举行的 Datanova — 数据网格峰会之前关于 Martin Fowler 的前两篇文章，分享和解释我对数据网格的理解。许多句子直接取自扎马克的文章。

Dahghani 女士最近出版了一本关于该主题的书。我还没有读过它，但我毫不怀疑它会澄清这篇文章的一些内容。

作为图表的忠实粉丝，我尝试制作一些图表来解释一些概念。

在接下来的文章中，我首先简要介绍 Zhamak Dehghani。我继续解释什么是数据网格以及为什么它很重要。我简要总结一下它是如何工作的。最后，分享几个我自己的问题。

在本文末尾，您将找到数据网格技术术语表和本文使用的或您可能感兴趣的资源列表。

扎马克·德加尼是谁？

Zhamak Dehghani — source ThoughtWorks

Zhamak 拥有计算机科学专业的工程学士学位和信息技术管理硕士学位。她做了几年软件工程师。今天，她是 ThoughtWorks 的新兴技术总监，过去 10 年她一直在该公司工作。

“她在 2018 年创立了 Data Mesh 的概念，这是大数据管理向数据去中心化的范式转变，此后一直在向更广泛的行业宣传这一概念。

Zhamak 是 ThoughtWorks 技术顾问委员会的成员，并为创建 ThoughtWorks 技术雷达做出了贡献。她作为技术专家工作了 20 多年，并为分布式计算通信以及嵌入式设备技术方面的多项专利做出了贡献。” — 思想工场

什么是数据网格，为什么它很重要？

尽管我们仍然在通过科学方法发现或重新发现早已超越直觉的智慧，但在许多领域，人类已经对自己感兴趣的主题产生了透彻的理解：意识、生活、冲突、教与学等。 , 21 世纪的特点是两个尚未彻底分析的概念：敏捷方法和数据的力量。

数据和敏捷性可能早在我们开始创造特定术语来描述它们之前就已经存在，但只是“最近”，这要归功于我们新发现的计算能力，我们才真正了解它们的重要性。

数据网格是敏捷思维和对数据的透彻理解的结果。数据网格最简单的形式是处理数据的敏捷框架。

目前，数据湖是大型刚性结构。数据从这些刚性结构中提取、处理并作为一个单一的超级强大的数据平台提供服务。然而，数据湖存在一些“可扩展性”缺陷：

• 由于数据在一个地方全部处理，因此它们通常不利于轻松添加新的数据源，这在数据是黄金且高效处理是关键的世界中至关重要。
• 他们冒着负责摄取、处理或提供数据的专业团队之间沟通问题的风险。与中国耳语游戏类似，最终用户的需求很容易被那些摄取和处理数据的人误解。
• 它们不利于可互换的用例和实验。

（Simplified diagram of a data lake）

上图可能显示了添加新数据源将如何需要更新整个数据湖，这涉及各种流程和多个独立团队。每个新客户或新来源都意味着修改复杂性不断增加的结构。

刚性总比没有好，因此数据湖曾经是必要的。然而，敏捷总是比刚性好，数据网格是刚性数据湖的敏捷改进。

数据网格如何工作？

[ 重要的！ ] 这可能只是我遇到的一个问题。我认为数据产品是核心功能基于数据的产品。

数据产品是“通过使用数据促进最终目标的产品”——DJ Patil，Data Jujitsu。

汽车不是数据产品，但 GPS 是。在线流媒体服务是一种数据产品，但视频商店不是。但是，对于 Zhamak Dehghani 来说，由于产品就是数据本身，因此术语数据产品用于将特定数据域定义为产品。重要的是要理解，在这种情况下，数据产品是一个有据可查、高质量的特定领域数据集，数据消费者（数据科学家、分析师等）可以通过 API 使用它。数据网格的目标是为公司的最终数据产品（它向消费者提供的产品）提供服务。我将通过将 Dehghani 女士的“数据产品”称为“领域数据产品”来尝试澄清这一点。

数据网格是一个框架。虽然只有某些技术可能允许其实施，但并不限于特定技术。因此，Zhamak Dehghani 仅提供原理和逻辑架构来解释如何实现它。

数据网格基于四个原则：

面向领域的去中心化数据所有权和架构

数据网格是特定领域数据产品的网络。它比数据湖具有更好的扩展性，因为新的数据源或新的数据消费者只意味着添加一个新的域（数据产品），而不是重新访问整个数据湖。

数据作为产品

每个域都像消费者一样为数据工程师服务，并具有以下属性。

• 可发现：所有可用数据域的注册表（或市场）。
• 可寻址：允许数据消费者以编程方式访问的唯一地址。
• 值得信赖：域“所有者”提供数据的质量保险以及数据出处和数据沿袭作为与域数据产品相关的元数据。
• 自我描述的语义和语法：域元数据应该足够清晰，任何人都可以自己开始使用数据。
• 可互操作并受全球标准监管：得益于全球质量和识别标准，数据可以跨域处理。
• 安全并受全球标准监管：使用企业身份管理系统 (SSO) 和基于角色的访问控制。
• 领域数据跨职能团队：领域特定的产品所有者和数据工程师，能够处理从源到数据消费者的整个领域数据。

作为平台的自助数据基础设施

每个域的数据集都需要可供任何希望使用它们的人使用。访问数据集的数据消费者需要通过上一个原理中的属性描述找到一个完善的数据产品。

联合计算治理

数据湖的优势在于，如果不遵循数据湖标准，则没有任何效果。因此，保证整个数据网格的功能至少与数据湖一样的唯一方法是实施全局治理。全局治理意味着两套标准：全球标准和领域特定标准。其中包括与数据产品属性相关的标准，例如数据质量、数据集之间的交叉引用、命名约定、元数据语法等。

数据网格可以很容易地与 Python 进行比较。 Python 的强大之处不仅在于它是一种简单的编码语言，还在于任何遵循全球库标准的开发人员都可以构建一个新的 Python 库（一种代码产品）并使其在官方 Python 库的全球市场上可用。 每个开发人员还可以自由设置自己的附加库标准。

在她的文章中，Zhamak 将数据产品显示为属于域，但没有没有数据产品的域，所以在我的情况下，它们是相同的。

单个数据域（数据产品）可以表示如下：

（A single data domain and its components）

使用六边形表示单个数据域，我们可以像这样表示数据网格：

（A simple data mesh diagram with five data domains）

域 4 和域 5 使用来自其他域的数据，但它们也可能从自己的来源获取自己的数据。

Zhamak 还谈到了多平面数据平台。 （请参阅数据网格原理和逻辑架构）老实说，虽然她将平面定义为“代表一个存在层次——既集成又分离”，但我不确定平面是什么意思。 😅

我的理解是，数据网格需要多个接口，以便使用它的任何人都可以轻松访问其不同的组件。 例如，数据消费者需要访问数据产品（数据集和相关元数据）的完整注册表。 其他用户可能需要访问治理标准，并且能够轻松了解它们是全局的还是特定于某些域的。 其他用户可能需要访问数据网格本身的可视化表示、访问其基础架构等。

下图试图在单个图像中解释数据网格：

（The full data mesh as I understand it）

作为去中心化领域特定数据产品的网络，对于需要管理许多数据源和数据消费者的企业而言，数据网格有可能成为一个非常强大的解决方案，但对于数据网格的构建和工作方式没有清晰的界面在公司内部，扩展和维护结果可能比数据湖更加混乱和耗时。

结论和问题

我很高兴发现了数据网格，并期待了解更多信息并澄清一些混乱的元素。我期待着这次会议，阅读这本书，如果可能的话，我会更新这篇文章或写另一篇文章。

每个数据域都应该由一个独立的团队管理。这是否意味着公司需要为每个新领域雇佣一个全新的团队？这不违背域的可扩展性吗？

每个数据域的管道都必须遵循全局数据治理规则，那么治理规则的变化不会导致每个管道的变化吗？

除了上一个问题，每个域的域数据管道是否应该在一个公共基础设施中注册并独立地为每个域提供服务，类似于开源 Python 库？下图可以阐明我的意思：

（Data mesh code Registry concept）

这引发了其他问题，例如数据团队之间的脚本所有权。此外，如果修改脚本 5 以适应仅适用于域 2 的修改而不是新脚本，则需要为域 3 和 4 创建旧脚本 5 的副本。（域拥有自己的域似乎更简单代码，也许我正在将这种敏捷性推到很远。😆）

今天可能没有任何现有的特定数据网格技术，但在我看来，作为域管道功能、域数据集和访问全球治理标准的注册表的单一平台将是这样一项技术。现有的任何其他东西都可以作为更完整解决方案的 MVP 方法。

数据网格词汇表

• 数据网格：专注于去中心化数据管理的数据框架。
• 数据产品：将数据用作其核心功能的一部分的产品。
• 数据即产品：当数据是最终产品时。消费者是数据消费者：业务分析师、数据科学家、数据分析师、数据工程师等等。他们将“购买”数据并在自己的数据产品中使用。
• 领域：计算机程序的目标主题领域。在这种情况下，数据的目标主体。如果数据用于分析“用户配置文件”，则域为“用户配置文件”，如果用于分析“歌曲”，则域为“歌曲”。
• 域数据产品：特定于数据网格中唯一域的数据产品。
• 源域数据集：一个数据集，它紧密地代表创建时的原始数据，并且没有为特定消费者拟合或建模。
• 消费者对齐的域数据集：经过面向消费者的转换的源域数据集。
• 域数据团队：负责专门管理数据网格内的数据域的数据团队。
• 领域数据产品所有者：A P.O.负责将数据作为产品交付。
• 领域驱动设计：将系统分解为围绕业务领域能力构建的分布式服务。
• 架构量子：可以独立部署且具有高功能凝聚力的最小建筑单元，包括其功能所需的所有结构元素。
• 联合计算治理：由域数据产品所有者和数据平台产品所有者联合领导的决策模型，具有自治和域本地决策权，同时创建并遵守一组全局规则——规则适用于所有数据产品及其接口——以确保一个健康且可互操作的生态系统。