什么是数据网格

这个周末我被一个数据网格推特线程所吸引（如果你还没有看过，值得一读）。数据网格显然触动了人们的神经。有些人不理解它们，而另一些人则认为它们是个坏主意。然而，“Demystifying Data Mesh”和“Putting Data Mesh to Work”文章比比皆是。为了理解混乱，我重新阅读了 Zhamak Dehghani 的原始和后续帖子。 Zhamak 是数据网格的创建者。在她的第二篇文章中，她确定了四个数据网格原则： 我相信将这些原则放在同等地位会造成混淆。第二个原则——数据作为产品——是数据网格的激励原因，值得单独考虑。一旦我们探索了“数据即产品”是什么，我们就可以讨论其含义：对去中心化、自助服务基础设施和联合治理的需求。应用程序数据就像任何其他产品一样拥有客户。数据科学家、业务分析师、财务、销售运营、产品经理和工程师都使用应用程序数据。机器学习模型、图表、图形、报告，甚至其他 Web 服务都建立在应用程序数据之上。作为“真正”产品的一部分，应用程序数据越来越多地暴露给付费客户（Stripe 的 Sigma 就是一个例子）。然而，组织并不将数据视为一种产品。虽然开发团队花时间记录、版本控制、重构和管理 Web 服务数据模型和 API，但数据在很大程度上被忽略了。拥有 ETL 管道的组织要么直接公开 Web 服务数据模型，要么拥有一个构建修剪整齐的数据仓库的集中团队。非常适合低延迟 Web 服务的数据模型很难让人类使用。一个中心化的数据仓库团队只是将痛苦隐藏在一群倒霉的数据工程师背后，他们肩负着解释内部模式、在迁移时追踪数据、构建自己的（通常是不准确的）数据模型以及拼命支撑单一数据管道的艰巨任务.提议将所有服务 API 和数据建模集中起来是很疯狂的，但这就是我们对数据所做的。相反，我们需要的是让组织像对待任何其他面向公众的 API 一样谨慎对待数据。数据必须具有明确定义的模式、版本化、强制兼容性保证、良好的文档记录等。基本上，组织需要表现得好像他们的数据正在被人类使用，因为它是！但是如何构建数据产品呢？我已经说过，集中式团队在这方面做得不好；我们已经尝试了几十年，但效果不佳。数据产品必须由拥有数据的团队以去中心化的方式构建；他们是理解它的人。权力下放是其他三个原则的用武之地，这也是我认为很多困惑所在。为了揭开这些原则的神秘面纱，我将使用现代服务堆栈进行比较。

现代服务堆栈是去中心化的 (a)，这一点应该不会让人感到惊讶。此类堆栈通常具有由数十个或数百个团队 (a) 拥有的数百或数千种不同的服务。每个团队都可以定义、构建和拥有自己的 API。团队还部署和监控他们自己的服务 (b)。自行部署提高了功能交付速度：开发人员不必等待单独的按钮推动者团队来部署更改。并且一个集中的团队不会部署他们不理解的软件（听起来很熟悉？）。但应用程序开发人员并不总是具备定义结构良好的 API 或解决复杂部署问题所需的技能。通过服务基础架构团队、DevOps 文化和嵌入式站点可靠性工程师 (SRE) 进行联合治理 (c)，作为对去中心化的抗衡。集中式团队定义标准序列化格式、服务框架以及 API 建模和兼容性规则。这些“服务基础设施”或“服务平台”团队编写工具来执行标准并帮助应用程序开发人员生成干净的服务脚手架。委员会风格的设计审查出现，为应用程序开发人员提供 API 建模指导。同样，DevOps 文化和嵌入式站点可靠性工程师 (SRE) 已经出现，以帮助应用程序开发人员可靠地部署他们的更改。 DevOps 通过自动化工具提供防护栏，因此开发人员可以自信地使用蓝/绿部署、金丝雀、动态预生产环境和 A/B 拆分来部署他们的服务。如果错误率增加，高度进化的 DevOps 组织甚至可能会自动回滚进行监控。此外，现场可靠性工程师可以加入应用程序开发团队，以协助解决运营问题和工具开发。数据网格采用服务堆栈最佳实践并将其应用于数据层。应用程序开发团队不仅应该为其业务逻辑定义 API（以 Web 服务的形式）；他们也应该为他们的数据这样做。两者所需的基础设施和文化非常相似。应用程序团队需要基础设施来定义他们的数据产品，将他们的内部数据转换为数据产品格式，并将数据产品传输到其目标数据库。

数据产品模式是使用标准格式定义的，如协议缓冲区、Avro 或 JSON 模式。模式元数据——版本控制、所有权、沿袭、评论、使用等——使用数据目录附加，如 Amundsen、Datahub 和 Marquez（空间正在蓬勃发展）。使用诸如 Confluent 的模式注册表或插入 CI/CD 管道以运行预提交检查的本土验证器之类的工具来强制执行兼容性规则。开发人员很快发现他们希望公开的数据产品与他们的内部数据库模式不匹配（他们的数据工程师十年前可能会告诉他们）。需要数据管道来传输数据并将其转换为面向用户的格式。数据管道不是新的——它是 ETL——而是新的。集中式团队不负责转移和转换，应用程序开发人员负责。必须建立一个去中心化的数据平台。自动化管道生成工具可以建立在 Airflow、Prefect 和 dbt 之上。应用工程师可以定义他们的数据产品和转换，工具可以自动生成他们的转换工作流。如果数据管道是基于流的，传输和转换是通过流系统和流处理器（如 Kafka Streams、Flink 等）完成的。从配置自动生成简单转换的工具也需要在这里构建。发件箱模式等最佳实践也在不断涌现。部署需要以与服务 CI/CD 管道相同的方式自动化。与微服务相同的部署和编排工具可以重新用于分布式数据管道。 GDPR 及其分支是真实的。不应暴露敏感数据。安全性和合规性历来是通过数据仓库团队集中实施的。现在，我们需要基础设施和工具来做到这一点。数据目录可以在这里发挥作用，谷歌云的 DLP 解决方案等自动化检测工具也可以发挥作用。访问控制（谁可以访问什么数据）需要通过配置中的策略来实施。当然还有其他基础设施要求； DataOps 运动涵盖了很多。我在这里并不详尽，重点是数据网格存在许多与服务堆栈相同的基础设施需求，并且有许多工具可以解决它们。

如果您强迫我为最小可行数据网格定义基础架构，我会说：仅靠技术并不能构建数据网格。向分散的数据管道和数据仓库的转变需要组织内部的文化变革。正如应用程序开发人员可能不具备定义完善的服务 API 的所有技能一样，他们可能也不具备定义完善的数据产品或运行数据管道的技能。同样，面向服务的体系结构 (SOA) 也存在相同的问题，并且可以应用相同的解决方案。数据基础架构团队、DataOps 文化和嵌入式数据工程师有助于弥合技能差距并提供防护。需要创建“数据基础设施”或“数据平台”团队来构建分布式数据平台基础设施——上面基础设施部分中列出的内容。基础设施团队还必须构建 DataOps 工具来提供防护并灌输 DevOps 最佳实践。使用数据质量检查和监控（Anomalo 和 BigEye）、管道测试（模式和数据）以及标准服务部署实践。 DataOps 重点关注敏捷文化，并支持精益制造最佳实践和统计过程控制 (SPC)；文化和工具一样多。中央委员会定义标准序列化格式、转换框架以及数据建模和兼容性规则。设计委员会的出现为应用程序开发人员为其数据产品提供数据建模指导。近十年前，LinkedIn 的团队负责审查服务 API 和数据产品并提供指导。正如 SRE 嵌入应用程序开发团队一样，数据工程师也可以嵌入。嵌入式数据工程师负责定义数据产品、维护数据管道以及在团队内构建数据工具。最重要的是，应用团队需要相信数据是他们需要投资的产品。这是妨碍他们“真正”工作的东西。在组织内寻找冠军会有所帮助。随着 Stripe 的 Sigma 等面向用户的数据产品越来越普及，应用团队将面临数据仓库团队一直以来的痛苦。工程师将开始要求自己的数据产品；这对他们来说很直观——这与他们一直在使用面向服务的架构和 DevOps 做的事情是一样的。

如果您强迫我定义最小可行数据网格的文化，我会说：与现代服务堆栈一样，数据网格必然存在缺陷。缺乏标准和 REST 学究是一个真正的问题。许多服务堆栈开始时没有一套明确的标准。团队使用自己的框架和工具构建服务，并且不遵守 REST 或 gRPC 最佳实践。出现的是一个分布式的单体应用，其 API 的文档记录很差。在软件中工作足够长的时间，你最终会遇到对 REST 的执着。对名词、动词、URN 以及执行 REST 的“正确”方式大喊大叫的人。像理查森成熟度模型之类的东西（没有什么反对的，但有些人太投入了）。敏捷忍者和黑带出现在文化方面，决定如何“做”敏捷。创建认证并编写厚厚的 gobbledygook 大部头书，以便供应商和顾问可以赚钱。数据网格也存在所有这些风险。这并不意味着数据网格不再是一个坏主意，而是意味着面向服务的架构或敏捷是坏主意。它们只是可以使用或误用的工具和实践，就像任何其他工具和实践一样。从数据产品开始，看看它会把你带到哪里。我在这里交替使用数据仓库、数据集市和数据湖。 Zhamak 使用术语数据平面。

我没有以任何方式参与数据网格项目。我是 Zhamak 作品的粉丝。