数据网格解决了大规模数据环境中，异构数据的存储、访问问题。要了解数据网格，就需要从数据系统的源头开始，了解数据系统是如何从硬编码、SQL、数据库、数据仓库、数据湖一路发展到数据网格。每一项技术都是为了解决特定问题而存在，了解技术的演进，能够帮助我们理解在现实场景中哪种技术对我们更有价值。原文：What is Data Mesh Anyway?^[1]

简介

数据网格（Data Mesh）是个相对比较新的术语，但其概念本身已经存在了数十年。在这篇以寓言形式叙述的文章中，您将了解数据系统是如何发展的，数据网格是如何从分布式数据系统演化而来，为什么我们需要数据网格。

背景

那是一个隆冬的清晨，Acme Widgets的首席数据系统架构师Debby正心不在焉的研究咖啡里涌起的漩涡，一边看着日历，一边思考着如何度过这一天。她已经在这里工作了将近25年，目睹了各种曾经火热的炒作及其最后的消亡，就像窗外的露珠一样。她反思了在自己的职业生涯中，是如何教导许多高管做出正确决定的。作为数据生态系统的领导者，她充分意识到，如果设计不当，她的世界将充满数据崩溃的灾难。有些人有能力理解这一点，但还有些人会被淹没在术语的海洋中，无法清楚的理解概念。在这些不幸的情况下，Debby小心翼翼但坚定的确保讨论清晰，并帮助每个人在正确的道路上团结一致。

她的电话响了起来，是公司的CTO Ted打来的，让她放下手头的事情，参加一个视频电话会议，包括Ted在内的许多高管都在上面。Ted在感谢Debby参加电话会议后，开始说：“我刚刚听说了一个奇妙的概念，叫做数据网格，公司管理层感到有点困惑：我们为什么不用它？”

Debby叹了口气，提炼数据管理的概念始终带有挑战性，在视频会议时代尤其如此，因为最近的新冠疫情重新定义了工作场所。她毫不犹豫地回答：“当然，Ted，我们正在使用它。”

“嗯？”公司的首席架构师Aaron问道，“我不记得看到过任何一份高层设计文档涉及到这一概念。”

“Debby总是知道她负责范围内的事情，这次应该也一样。”Ted说，“麻烦你给我们介绍一下关于这个概念的概述，为什么它有用，我们如何在Acme中使用它？”

在她的整个职业生涯中，Debby一直坚持在杂乱的行业术语中保持清晰的思维，用技术的进步来推动战略，而不是把战略硬塞进一些流行词汇中。她意识到，现在就是一个这样的时刻。

数据系统的演进

为了更清楚的理解这个概念，Debby从数据系统的发展开始说起。她解释说，在20世纪70年代关系型系统出现之前，数据都存储在文件中，是应用程序的附庸。如图1所示，当时没有共享的数据系统。可能有多个应用程序会访问这些文件，但所有的应用都是一个整体的一部分。只有应用程序才了解文件中的数据结构。模式（schema）这个术语还没有出现，即使有类似的概念，也只能局限于单个应用内部。要从该文件集访问数据，您必须了解这些应用程序中定义的确切schema，但最重要的是，你必须编写一个程序来访问数据。

图1. 基于文件的应用程序

Debby继续说，这导致了两个问题：

数据所在的位置是特定的。例如，如果你希望获得帐户号123的余额，你必须知道需要从第23个文件的第100条记录中读取第51列。如果添加一条新记录，第100条记录可能会变成第101条，文件可能会变成第24个。数据使用者必须知道特定的文件和记录的相对位置。类似地，如果要添加一个新列，第51列可能会变成第52列，程序也不得不理解对应的变更。

每次你想要获取数据的时候，都必须编写程序。大多数数据使用者不是程序员，所以不得不依靠程序员来获得需要的数据。而程序员资源有限，因此这种方式也受到了很多限制。数据访问几乎总是用于编程和面向数据处理，而不是用于专门的数据分析。换句话说，数据只是一堆供程序使用的文本，而无法让使用者获取有意义的洞见。

SQL的演进

Debby继续说，到20世纪70年代发生了重大突破——引入了一个被称为“数据库”的新概念，更具体地说，是基于IBM的一篇研究论文而发展起来的关系型数据库（relational database）。它戏剧性的改变了当时的思维方式，引入了两个强大的概念。

首先，仍然使用文件来存储数据，但将数据的物理位置与逻辑表示分离。例如，要读取上一节中显示的123账户的余额，用户不需要知道确切的位置，即文件、记录和列的位置，而只需要询问信息，系统就会转换为可以访问的准确位置并返回值，如图2所示。

图2. 数据库管理系统的角色

“有点像DNS是吗？acmewidgets.com这样的地址实际上指向了一个数字表示的IP地址。“，Ted说到。

“完全正确。”，Debby说。数据库将请求转换为实际位置，读取数据并将值返回给用户。类似的，当引入新记录或新列时，只是在文件中进行更改，对用户的抽象可以保持不变。这就产生了一种叫做数据库管理系统（Database Management System）的新型系统，几乎所有的现代数据系统都遵循这一原则。数据库管理系统还将记录或文件移动到性能和可靠性最优的位置，而对最终用户完全透明。

其次，它引入了一种叫做结构化查询语言（SQL，Structured Query Language）的新语言来读取和写入数据，这种语言非常像英语，大多数业务用户可以很快学会，并且可以在不依赖程序员的情况下获取数据。这就产生了一个全新的概念，叫做临时数据分析。简而言之，SQL拉近了数据和用户之间的距离，并允许数据中的值被有效访问。

分布式数据库

Debby继续说到：“数据库管理系统越来越受欢迎，起到越来越突出的作用。”她很小心，没有使用关系数据库系统这个词。虽然关系是这种变化的一个重要组成部分，但数据库系统的概念超越了关系，所有数据库管理系统都做同样的事情：不同程度的抽象实际存储，并使用户非常容易的获得想要的数据。因此，她使用数据库这个术语来表示任何类型的数据库管理系统——关系型的或非关系型的。

由于数据库系统使用户很容易获得工作所需的数据，因此数据库的使用激增。很快，一家公司就有了多个数据库，每个数据库都是为特定的目的或由特定的部门建立的。例如，一个用于财务部门的数据库，由财务人员使用，而销售人员建立了另一个不同的数据库，如图3所示。

图3. 根据部门边界分离数据

当数据库沿着功能或部门边界划分时，这种方法很有效，但很快它就成了自己成功的牺牲品。Debby解释道，突然间，人们意识到如果他们能够访问某些数据，就可以利用这些数据进行大量的分析。例如，由于财务部门的员工无法访问销售数据，因此觉得他们无法做出有效预测。如果他们有来自销售部门和所有其他部门的数据，将能够更有效的完成工作。

---

数据全景图（Data Landscape）通过两种不同的方式扩展了对多个数据存储的访问：复制（Copy）和桥接（Bridge）。

数据复制（Data Copy）

Debby继续说，数据全景图演化出了两条路径。一条路径是从一个数据库复制数据到另一个数据库。因此，销售数据库将向财务数据库发送相关数据的快照。虽然这样做是可行的，但却违反了数据管理中的一个基本原则：应该只保留一个数据副本。创建副本会造成各种各样的问题，例如，不知道哪个副本是最新的，或者更糟的是，甚至不知道该副本是如何生成的。没人能保证副本经过了哪些转换，甚至不知道这种转换是否准确。这里有一个简单的例子，销售数据库将销售预测等级保存为1-5个等级，其中5是最高的销售可能性。然而，当复制数据时，数据工程师错误的假设它是一个“优先级”，即1比5更好，并根据1 - 5这5个值创建了优先级描述。这是个很小的错误，但结果却是毁灭性的，因为数据的意义完全不同了。因此，复制并不是一个好主意。

数据桥接（Data Bridge）

Debby解释说，为了避免复制数据，数据库供应商提供了连接其他数据库的桥梁来实时显示数据。图4显示了在销售数据库中有一个财务用户感兴趣的真实数据表，销售数据库管理员没有复制这些数据，只是简单的创建了一个桥接，在该桥接上可以在财务数据库中创建一个指针。当财务用户从该指针中选择数据时，它实际上会通过桥接实时的从销售数据库中提取数据。这解决了获取陈旧数据的问题，也消除了副本。一个实际例子是Oracle中的数据库链接。

图4. 数据桥接

“有时这被称为分布式数据库系统，应用程序和用户使用的数据分布在多个数据库中，但仍然可以通过一个数据库获得。”Debby解释道。

“听起来像是一个合理的解决方案，“观众沉思着，“有什么问题吗？”

Debby解释说，问题有很多：

1. 这通常是特定于供应商的解决方案，在大多数情况下，数据库需要位于同一供应商的平台上，才能使用桥接。
2. 有时供应商允许导入来自另一个供应商数据库的数据，但这仅限于支持的文件类型，例如Hadoop支持Parquet文件类型的外部表，但这种互操作性很有限。
3. 即使在这些情况下，接收数据的数据库也可能需要解析数据文件，这一过程称为序列化/反序列化(serde)，这会降低性能并抵消数据库引擎的优势。

然而，如果一个组织对单一的数据库供应商进行标准化，就有可能创建一个真正的分布式数据库平台。

“但是，”Aaron反驳道，“难道数据库平台不是最适合这个目的的吗？所有类型的数据库都需要单一的供应商完全破坏了这个概念。”

数据仓库的兴起

“完全准确，”Debby同意道，“这就是为什么这种方法不是很成功。许多数据库供应商生产适合特定用途的系统。还有其他类型的数据库，如NoSQL、文件（Document）、时间序列（Time Series）、图（Graph）等，为一个典型组织的所有需求选择单一技术是不切实际的。”

所以整个行业都在考虑这个问题。自20世纪90年代以来，另一个概念进入了数据领域——数据仓库（data warehouses）。更准确的说，这个概念主要关注分析处理（analytical processing），而不是事务处理（transactional processing），在此之前，事务处理在数据系统中更常见。仓库沿着称为维度模型（dimensional model）的关系模型的分支建立，两者之间的最大区别是，在维度模型中，只有少数表（称为“fact”）允许增长以捕获细节，而其他类型的不会经常修改的数据则存储在称为“dimension”的表中。

“可以举例说明有哪些不同类型的技术吗?””Ted问道。

Debby解释说，在用于事务处理的典型关系型数据库系统中，数据存储在记录中，每个记录都是被打包在一起的列的组合，如图5左侧标签Row Database下所示。

图5. 行数据库和列数据库的区别

Debby指着图继续解释说，行数据库（Row Database）有999行，每一行都用“行开始”标记，这就是为什么数据库系统知道记录在哪里分割。另一种类型的数据库称为列数据库（Column Database），如图5右侧所示。列数据库不以记录的形式存储数据，而是以列的形式。在本例中，它接受名为Account No的列的所有值，并以该名称创建一个列组。然后它对所有其他列重复这个过程。

“但是为什么呢？”Aaron好奇的问。

“记住，一个典型的分析性查询需要一个聚合函数，例如所有余额的总和，或平均值、最小值、最大值等，”Debby解释道。“对于行数据库，必须找到记录标记的开头，定位列，获取值，并对所有行重复这一操作，这需要花费很多时间。在列数据库中，它可以一次性获得整个列值，并应用聚合函数，使处理速度大大提高。”

那么，Ted沉思着，为什么所有的关系型数据库技术都是用这种列式方法设计的呢？

回到图5，Debby指向行数据库。在事务系统中，应用程序和用户通常只选择少量的行及其所有的列。由于选择了所有列，系统将不得不读取所有列数组并从中选择几行，这又将显著影响性能。类似的，更新和删除个别记录在事务系统中很常见，但在仓库中却不常见，因此，列式设计会损害事务系统。

列式系统针对聚合查询进行了优化，而事务系统针对单个记录访问进行了优化。

仓库还进行了额外的优化，如存储索引、位图索引等，以使分析查询更快。现在大家可以理解为什么系统需要不同的工具。

当针对特定目的的分析平台建立后，组织需要通过它聚合来自各种运营系统的数据，如图6所示。

图6. 所有数据汇聚到数据仓库

在这种方法中，数据从源系统中提取出来，转换并加载到数据仓库中。这将操作数据库所用的技术与仓库所用的技术分离开来。分析型用户可以根据需要访问仓库，并且使用适当的技术构建仓库。

Debby说：“所有人都很高兴，直到2010年。”听众们感到很困惑：“为什么？然后发生了什么？”

单一数据仓库的问题

单一仓库解决了许多问题，Debby继续说：

1. 该技术专注于适配目标，而将实际的技术选择留给了运营系统。
2. 分析用户不会影响运营系统的性能。
3. 分析平台可以应用某些数据转换来达成对数据的更好的理解。例如，虽然运营系统可能已经将0和1存储为Inactive和Active，但仓库可以存储实际的描述性值，以避免误解。

然而也有局限性，Debby继续说：

1. 仓库总是一个副本，数据从来都不是最新的，而是和最近的ETL作业一样。
2. 单个数据仓库的概念对于某些组织来说并不实际，从而出现了多仓库。原因在于数据规模对于单个仓库来说太大了，组织边界要求将数据放在多个仓库中，监管要求跨地理边界创建仓库，例如，特定国家的数据需要在该国境内，等等。

数据湖（Data Lake）来了

“但最重要的问题之一，”Debby打趣道，“是存储非结构化数据的需求，这导致出现了另一个概念：数据湖。”

Debby解释说，数据湖与数据仓库非常相似，也用于分析目的。然而，数据湖可以接受和存储的数据种类要灵活得多，甚至可以是完全非结构化的数据。通常，数据仓库是结构化的，有专门的软件来优化数据的存储和访问，而数据湖是非结构化的，使用非专有软件，这明显降低了成本，但没有优化数据访问。成本通常是在两种格式之间做决定时的重要考量因素，较低的成本允许组织可以低成本的长期存储数据。

“因此，”Ted总结道，“仓库是结构化的，拥有专有的软件和数据格式，因此具有更好的性能。数据湖是非结构化的，没有专有软件，因此性能较低，但这使得它们更便宜，可以更灵活的接受任何类型的数据。我说对了吗？”

”简而言之，是的。“Debby同意道。然而这条界线已经模糊了，拥有专有软件的数据仓库也可以将非专有格式的数据存储为外部表。但是，达不到传统数据仓库的性能，并且可能会增加成本。因此，许多组织遵循双重模式：

1. 数据湖用于长期数据存储、非结构化存储和性能不太关注的分析需求。归档系统、机器学习需要获取的长期数据等都属于这一类。
2. 短期的、访问频率从中到高的数据和需要性能的地方可以使用数据仓库。短期报告或商业智能功能以及假设分析在这里就很好用。

一般来说，与数据仓库相比，数据湖提供了更便宜但性能更差的解决方案，在许多情况下可能是可以接受的。

Debby承认，一些供应商实际上在他们的产品中提供了这两种功能，但会强调功能的不同之处。此外，就像之前的数据仓库一样，组织也可以创建多个数据湖来解决安全性、地理偏好、技术、供应商云平台等方面的问题。一刀切不是万能的，所以大多数组织都有多个数据湖和数据仓库平台。

数据网格（Data Mesh）介绍

”我明白了，”Aaron说，“但这和我们之前讨论的数据网格有什么关系呢？”

Debby笑着说，关键是现在有许多不同的数据库和数据存储。多个数据仓库、多个数据湖和多个运营系统都可以作为组织内用户的潜在数据源，一个典型用户可能需要访问所有这些数据库中的数据。他们可以怎么做呢？Acme是否需要创建一个超级数据仓库，并从所有其他源复制所有数据，让所有分析用户访问单个数据存储？如图7所示。

图7. 超级数据仓库

Debby停顿了几秒，好让大家思考这个问题的重要性。

Ted说：“建造这样一个超级数据湖或数据仓库不仅极其昂贵，而且增加了时延，这使得它远不如追踪源本身那么有吸引力，所以这是不现实的。”

“准确地说，”Debby同意道，“这就是为什么Acme没有选择这样做的原因。”相反，Acme认识到将会有多个合法的数据源，每个数据源都有其独特的技术、数据格式等，并且客户可以自由地从最相关的数据源中提取他们想要的数据，如图8所示。

图8. 数据网格

Debby解释说，有多个数据存储可供所有用户访问，这些数据库中的数据不需要复制到中央数据仓库或数据湖中。

然后Debby向大家介绍这样做的好处：

1. 没有中心化数据湖或数据仓库，因此，与之相关的成本不再是一个问题，而这个成本是相当大的。
2. 对客户可用的数据没有时延，因为没有ETL将数据移动到中央数据存储中，所以数据可以立即使用。
3. 没有中央数据存储，所以不用争论它应该是数据湖还是数据仓库，每个数据存储都可以配置为数据湖或数据仓库。
4. 因为没有中央数据存储，所以没有关于技术的争论，每个数据存储都可以用适当的技术存储数据。例如，数据库1可以是一个内置Hadoop集群，而数据库2可以是一个为时间序列数据构建的云本地数据存储。
5. 每个数据库都是独立管理的，其中一个不可用并不影响对其他的访问。
6. 每个数据库都可以决定自己的授权策略。授权指的是用户访问数据集的能力。每个数据存储可以遵循其自己的权限管理系统，无需拥有中心化权限系统。

不是个好主意吗?

Aaron似乎并不相信：“这些都是很好的理由，但肯定有不那么令人满意的东西。”

“是的，有。”Debby同意道。首先，最后一个优势：权限的独立性，在某些情况下可能是劣势。由于权限管理通常是特定于数据库技术的，因此需要在数据存储中管理用户访问数据的权限。这给用户获取所需数据带来了复杂性。因此，当需求发生变化时，很难确定应该从用户那里撤销哪些访问权限。单一的中央数据存储将具有单一的权限管理系统，因此管理权限将容易得多。然而，Debby断言，与优点相比，这只是一个小缺点。

大家表示赞同。

“但用户怎么在所有这些数据库中找到他们要找的东西呢？”Ted问道。

“啊哈！这是数据存储的一个长期问题，”Debby笑着说。“答案是什么？一个中央数据目录（Data Catalog）。”

大家想要了解更多，但他们意识到时间已经到了，因此不情愿的离开了视频电话会议。Debby答应他们以后会再举行一次会议来继续这个问题的讨论。

结论

总的来说：

1. 数据网格只是允许用户访问符合其数据需求的最符合逻辑的位置，而不是将数据复制到一个中心位置。
2. 每个数据库都是独立管理的。
3. 每个数据库都可以使用最适合达成目标的技术。
4. 这些数据存储的数据总是最新的。
5. 一个中央目录和一个授权过程使这种设置成为可能。

References:
[1] https://arupnanda.medium.com/what-is-data-mesh-anyway-c65886cab127

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind