《流式Data Mesh》第一章：Data Mesh介绍-灵析社区

第一章：Data Mesh介绍

年轻人认为在某个时候，数据架构是容易的，然后数据的规模、速度和多样性增长了，我们需要新的、更复杂的架构。实际上，数据问题一直都是组织问题，因此从未被真正解决过。 ——Gwen（Chen）Shapira，《Kafka: The Definitive Guide（O'Reilly）》

如果你在一家不断发展的公司工作，你会意识到公司增长与数据入口规模之间存在着正相关关系。这可能是由于现有应用程序的增加使用或新添加的应用程序和功能所导致的。数据工程师的任务是在保持服务级别协议（SLA）的同时，组织、优化、处理、管理和提供这些不断增长的数据给消费者。很可能，这些SLA是在没有数据工程师的参与下向消费者保证的。当你开始处理如此大量的数据时，你会首先学到的是，当数据处理开始逼近这些SLA所做出的保证时，更多的关注点会放在保持SLA内，而数据治理等方面则会被边缘化。这反过来会导致对所提供数据的不信任，最终也会对分析产生不信任——而这些分析可以用来改进运营应用程序以产生更多收入或防止收入损失。

如果将这个问题在企业的所有业务线上复制，你会发现很多不满的数据工程师试图在数据湖和数据处理集群的能力范围内加快数据流水线的速度。这正是我经常发现自己处于的位置。

那么，什么是数据网格（data mesh）？在“数据网格”中，“网格”一词来自于“服务网格”（service mesh）一词，它是一种在平台级别而非应用程序层面上添加可观测性、安全性、发现和可靠性的手段。服务网格通常作为一组可扩展的网络代理与应用程序代码一起部署（有时称为旁路模式）。这些代理处理微服务之间的通信，并作为引入服务网格特性的点。

微服务架构是流数据网格架构的核心，并引入了一种根本性的变化，通过创建松耦合、更小、易于维护、敏捷和独立可扩展的服务，将单块应用程序分解为部署在任何单块架构容量之外的服务。在图1-1中，你可以看到将单块应用程序分解以创建更可扩展的微服务架构的过程，而不会失去应用程序的业务目的。

数据网格（data mesh）旨在实现微服务对单块应用程序所取得的目标。在图1-2中，数据网格试图创建一种松耦合、更小、易于维护、敏捷和独立可扩展的数据产品，超越任何单块数据湖架构的能力范围。

Zhamak Dehghani（本书中简称为ZD）是数据网格模式的先驱者。如果你对ZD及她的数据网格博客不熟悉，我强烈建议你阅读她的博客以及她非常受欢迎的书籍《Data Mesh》（O'Reilly）。在本书中，我将简要介绍数据网格架构模式的基本概念，帮助你对构成数据网格的支柱有一个基本的理解，以便在整本书中能够更好地参照这些概念。

在本章中，我们将先介绍数据网格的基础知识，然后在第二章中介绍流数据网格。这将有助于打下更好的基础，以便更好地理解流数据的相关概念。接下来，我们将讨论其他与数据网格相似的架构，以帮助区分它们。这些其他架构在设计数据网格时往往会让数据架构师感到困惑，因此在将数据网格引入流数据之前，最好先搞清楚这些概念。

数据分割

ZD的博客讨论了数据分割（data divide），在图1-3中有所示，以描述数据在企业中的流动。这个基础概念将有助于理解数据如何驱动业务决策以及相关的单块问题。

简单概括一下，操作数据平面包含支持业务应用程序的数据存储。

通过提取、转换和加载（ETL）过程，将操作数据复制到分析数据平面，因为您不希望在操作数据存储上执行分析查询，这会占用生成业务收入所需的计算和存储资源。分析数据平面包含数据湖/数据仓库/数据湖仓库，用于获取洞察力。这些洞察力会反馈到操作数据平面，以进行改进和业务增长。

在操作数据平面上，借助Kubernetes的帮助，应用程序已从笨重的单块应用程序发展为敏捷和可扩展的微服务，它们互相通信，形成了一个服务网格。然而，在分析数据平面上的情况并非如此。数据网格的目标就是这样：将单块的分析数据平面分解为一种去中心化的解决方案，以实现敏捷、可扩展和易于管理的数据。在本书中，我们将始终提到操作数据平面和分析数据平面，因此在我们开始构建流数据网格示例时，早期建立这种理解非常重要。

数据网格支柱

数据网格架构的基础由表1-1中定义的支柱支持。我们将在以下部分快速总结它们，涵盖每个支柱的重要概念，以便在后面的章节中专注于实现流数据网格。

请注意，这里提到的表1-1是书中的一个表格，我无法直接提供其中的具体内容。

数据所有权和数据作为产品构成了数据网格支柱的核心。自助式数据平台和联邦计算数据治理是支持前两个支柱的存在。我们将简要讨论这四个支柱，并在接下来的每一章节中专门探讨其中的一个支柱，从第三章开始。

数据所有权

正如之前提到的，数据网格的主要支柱是将数据分散，使其所有权归还给最初生成数据的团队（或至少是那些最了解和关心数据的团队）。该团队中的数据工程师将被分配到一个特定的领域，其中他们是数据专家。一些领域的示例包括分析、库存和应用程序。他们很可能以前是在单块数据湖中进行读写操作的团队。

领域负责从真实数据源捕获数据。每个领域会对数据进行转换、丰富，并最终将数据提供给其消费者。

有三种类型的领域：

仅生产者领域：只产生数据，并不从其他领域消费数据。
仅消费者领域：只从其他领域消费数据。
生产者和消费者领域：分别向其他领域生产和消费数据。

数据即产品

由于数据现在属于一个领域，我们需要一种方法在领域之间提供数据。由于这些数据需要可消费和可用，因此需要将其视为任何其他产品，以便消费者能够获得良好的数据体验。从现在开始，我们将称任何被提供给其他领域的数据为数据产品。

确定数据产品的“良好体验”是一个需要在数据网格的各个领域之间达成一致的任务。达成共识的定义将有助于在网格中参与的各个领域之间提供明确定义的期望。表1-2列出了一些思考的想法，这些想法将有助于为数据产品消费者创造“良好体验”，并在领域中构建数据产品时提供帮助。

联邦计算数据治理

由于领域用于创建数据产品，并且在多个领域之间共享数据产品最终构建了一个数据网格，因此我们需要确保提供的数据遵循一些准则。数据治理涉及创建和遵守一组全局规则、标准和政策，应用于所有数据产品及其接口，以确保协作和互操作的数据网格社区。这些准则必须在参与数据网格领域之间达成共识。

在考虑为数据网格设置数据治理时，以下是一些需要考虑的事项：授权、身份验证、数据和元数据复制方法、模式、数据序列化以及令牌化/加密。

自助式数据平台

由于遵循这些支柱需要一套高度专业化的技能，因此必须创建一套服务来构建数据网格及其数据产品。这些工具需要与更广泛的工程师可访问的技能兼容。在构建数据网格时，有必要使领域中的现有工程师能够执行所需的任务。领域必须从其操作存储中捕获数据，对数据进行转换（联接或丰富、聚合、平衡），并将其数据产品发布到数据网格中。自助服务是使数据网格易于采用且易于使用的“简化按钮”。简而言之，自助服务使领域工程师能够承担数据工程师在企业各个业务线中负责的许多任务。数据网格不仅分解了单块数据湖，还将数据工程师的单块角色分解为领域工程师可以执行的简单任务。

数据网格图示

图1-4显示了三个不同的领域：数据科学、移动应用和库存。

数据科学领域消费来自应用领域的数据，应用领域拥有来自移动应用的数据。库存领域消费数据科学领域的数据，用于库存物流，例如减少距离或将供应移动到更有购买倾向的位置。最后，应用领域可能会消费新训练模型的引用，将其加载到移动应用程序中，以创建更新的个性化体验。

数据治理在数据产品的生产者和消费者之间创建访问控制，并提供诸如模式定义和血统等元数据。在某些情况下，主数据以及参考数据可能与实施相关。数据治理还允许我们为这些资源创建适当的访问控制。

连接领域之间的边缘在它们之间复制数据。它们建立了领域之间的连接，创建了"网格"。图1-4是一个数据网格的高级图表，我们将在接下来的章节中深入探讨。

在后面的章节中，我们还将讨论如何通过组建一个遵循ZD分散式数据平台愿景精神的数据团队来识别和构建领域。再次强调，图1-4是一个非流式数据网格的高级视图。这样的实施并不意味着流式处理是发布数据供消费使用的唯一解决方案。其他替代方案可以在领域之间和领域内传输数据。第2章专门介绍了流式数据网格及其优势。

其他类似的架构模式

前一部分以ZD的愿景为基础，以非常高的层次总结了数据网格架构。许多数据架构师喜欢指出现有的数据架构与数据网格具有相似的特征。这些相似之处可能足以让架构师将他们的现有实现标记为符合和满足数据网格的支柱。这些架构师可能完全正确或部分正确。其中一些数据架构包括数据织物、数据网关、数据即服务、数据民主化和数据虚拟化。

数据编织（Data Fabric）

数据编织是一种与数据网格非常相似的模式，两者都提供了涵盖数据治理和自助服务的解决方案：发现、访问、安全性、集成、转换和血缘（图1-5）。在撰写本文时，关于数据网格和数据编织之间的区别尚不清楚。简单来说，数据编织是一种元驱动的方式，用于连接不同的数据集和相关工具，提供一致的数据体验，并以自助服务的方式提供数据。

虽然数据网格和数据织物都致力于解决许多相同的问题，即能够在一个单一的组合数据环境中处理数据，但方法是不同的。数据织物使用户能够在分布式数据之上创建一个单一的虚拟层，而数据网格进一步赋予了分布式的数据生产者以管理和发布数据的权力。数据织物通过在数据织物内部的API中应用数据集成，实现了低至无代码的数据虚拟化体验。

然而，数据网格允许数据工程师为进一步接口编写代码的API。数据织物是一种跨多种技术和平台提供数据访问的架构方法，基于技术解决方案。一个关键的区别是，数据网格不仅仅是技术：它是一个涉及人员和流程的模式。与数据织物拥有整个数据平台的所有权不同，数据网格允许数据生产者专注于数据生产，数据消费者专注于数据消费，并允许混合团队使用其他数据产品、融合其他数据创建更有趣的数据产品，并在此过程中考虑一些数据治理问题。

在数据网格中，数据是分散的，而在数据织物中，允许数据的集中化。而像数据湖这样的数据集中化方式会带来与之相关的巨大问题。数据网格试图通过将数据域分解为更小、更敏捷的群组，将微服务的方法应用于数据。值得庆幸的是，支持数据织物的工具也可以支持数据网格。显而易见，数据网格将需要支持域工程中数据产品的自助服务，并提供构建和提供数据产品的基础设施。

在图1-6中，我们可以看到数据网格具有数据织物的所有组件，但以网格的形式实施。简而言之，数据织物是数据网格的子集。

数据网关和数据服务

数据网关类似于API网关，但是用于服务数据：数据网关的作用类似于API网关，但侧重于数据方面。数据网关提供抽象、安全性、扩展性、联邦性和基于契约的开发功能。 ——Bilgin Ibryam在2020年5月的InfoQ文章《云原生时代的数据网关》中提到

同样，数据即服务（DaaS）是一种模式，它从其原始来源提供数据，通过遵循开放标准进行完全管理，并由软件即服务（SaaS）提供。这两种架构模式都提供数据，但DaaS更注重从云端提供数据。可以说，DaaS在云端实现了数据网关，而以前可能只能在本地环境中实现。

图1-7显示了一个示例。将数据网关和DaaS的概念结合起来，更容易将数据标识为来自原始来源，特别是如果数据在源头上是不可变的。将源自本地数据中心的数据复制到云端的SaaS中将是一项要求。

除了由SaaS提供支持之外，数据网格满足了DaaS的所有要求。在数据网格中，SaaS是一种选择，但目前还没有SaaS数据网格提供商可以使实施数据网格变得容易。

数据民主化（Data Democratization）

数据民主化是将数字信息对普通非技术用户的信息系统变得可访问的过程，而无需依赖IT的参与：

Data democratization means that everybody has access to data and there are no gatekeepers that create a bottleneck at the gateway to the data. It requires that we accompany the access with an easy way for people to understand the data so that they can use it to expedite decision-making and uncover opportunities for an organization. The goal is to have anybody use data at any time to make decisions with no barriers to access or understanding. ———Bernard Marr, “What Is Data Democratization? A Super Simple Explanation and the Key Pros and Cons,” Forbes, July 2017

数据网格通过其数据产品、自助服务和低代码方法来共享和创建数据，满足了这一定义。对数据的简单访问在保持企业数据驱动至关重要。快速获取数据以创建分析洞察将使企业能够更快地响应运营变化，从而节省高昂的成本。

数据虚拟化

数据虚拟化是一种特殊的数据集成技术，它可以在不将任何数据移动到新位置的情况下，提供对实时数据的访问，跨多个来源和非常大的数据量。许多人认为数据虚拟化是实现数据网格的解决方案，因为它可以满足数据网格架构的所有支柱，特别是不需要将任何数据移动到新位置的理念，这需要使用单独的ETL过程来复制数据。当我们开始讨论流数据网格时，我们需要了解数据虚拟化和数据复制之间的区别，流数据网格采用的是后者的方法。

如前所述，数据虚拟化不会将数据移动到新位置，因此在执行查询时不会多次复制数据，与数据复制不同。这在数据分布广泛时可能是有益的。然而，如果数据存在于多个全球区域，跨长距离执行查询将显著影响查询性能。使用ETL将数据从操作层复制到分析层的目的不仅是防止在操作数据存储上执行特定查询（这将影响支持业务的操作应用程序），还将数据更接近执行分析的工具。因此，仍然需要ETL，并且数据复制是不可避免的：

Data virtualization comes from a world-view where data storage is expensive and networking is cheap (i.e., on premise). The problem it solved is making the data accessible no matter where it is and without having to copy it. Copies in databases are bad because of the difficulty in guaranteeing consistency. Data replication is based on the view that copies aren’t bad (because the data has been mutated). Which turns out to be more useful when it’s the network that’s expensive (the cloud). Mic Hussey, principal solutions engineer at Confluent

考虑使用混合复制和虚拟化的方式。随着数据开始存储在不同的全球区域，将数据复制到一个区域，然后在该区域内实施数据虚拟化可能会更好。

专注于实施

ZD的数据网格定义中，并不要求使用流式处理。在数据网格中，可以使用批处理或流式处理API来提供数据产品。ZD还指出，数据网格应仅用于分析用例。我们将超越分析，将数据网格应用于提供DaaS和数据织物解决方案的架构。第二章将重点介绍流式处理在数据网格中的一些优势。

将数据网格的基本原理应用于流式处理环境将需要我们做出实现选择，以便通过示例构建流式数据网格。本书中所做的实现选择并不一定是流式数据网格的要求，而是为了在遵循ZD的数据网格支柱的同时，帮助将流式解决方案整合在一起的选择。流式实现所需的两个关键技术包括：（1）流式技术，例如Apache Kafka、Redpanda或Amazon Kinesis；（2）以异步资源形式公开数据的方式，使用AsyncAPI等技术。随着本书的进展，我们将重点介绍使用Kafka和AsyncAPI的实现。

Kafka

本书使用Apache Kafka作为流式数据平台的实现。本书不要求您了解Apache Kafka，但将涵盖使流式数据网格正常运行所需的重要功能。此外，Kafka可以用类似的流式平台如Apache Pulsar或Redpanda替代，它们都遵循Apache Kafka生产者和消费者框架。值得注意的是，那些能够将数据保存在提交日志中的流式平台将最好地实现本书中描述的流式数据网格模式。提交日志在第二章中有详细介绍。

AsyncAPI

AsyncAPI是一个开源项目，简化了异步事件驱动架构（EDA）。AsyncAPI是一个框架，允许实现者生成代码或配置，无论使用哪种语言或工具，以产生或消费流式数据。它允许您以简单、描述性和互操作的方式描述AsyncAPI配置中的任何流式数据。它将成为我们构建流式数据网格的基础组件之一。仅仅使用AsyncAPI无法完全定义流式数据网格中的数据产品。然而，由于AsyncAPI是可扩展的，我们将扩展它以包含先前定义的数据网格支柱。我们将在后续章节中详细介绍AsyncAPI的细节。

有了数据网格及其定义的支柱，让我们更深入地了解如何将本章讨论的支柱和概念应用于流式数据，从而创建一个流式数据网格。