数据网格解决了大规模数据环境中，异构数据的存储、访问问题。要了解数据网格，就需要从数据系统的源头开始，了解数据系统是如何从硬编码、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 解释说，问题有很多：
- 这通常是特定于供应商的解决方案，在大多数情况下，数据库需要位于同一供应商的平台上，才能使用桥接。
- 有时供应商允许导入来自另一个供应商数据库的数据，但这仅限于支持的文件类型，例如 Hadoop 支持 Parquet 文件类型的外部表，但这种互操作性很有限。
- 即使在这些情况下，接收数据的数据库也可能需要解析数据文件，这一过程称为序列化/反序列化(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 继续说：
- 该技术专注于适配目标，而将实际的技术选择留给了运营系统。
- 分析用户不会影响运营系统的性能。
- 分析平台可以应用某些数据转换来达成对数据的更好的理解。例如，虽然运营系统可能已经将 0 和 1 存储为 Inactive 和 Active，但仓库可以存储实际的描述性值，以避免误解。
然而也有局限性，Debby 继续说：
- 仓库总是一个副本，数据从来都不是最新的，而是和最近的 ETL 作业一样。
- 单个数据仓库的概念对于某些组织来说并不实际，从而出现了多仓库。原因在于数据规模对于单个仓库来说太大了，组织边界要求将数据放在多个仓库中，监管要求跨地理边界创建仓库，例如，特定国家的数据需要在该国境内，等等。
数据湖（Data Lake）来了
“但最重要的问题之一，”Debby 打趣道，“是存储非结构化数据的需求，这导致出现了另一个概念：数据湖。”
Debby 解释说，数据湖与数据仓库非常相似，也用于分析目的。然而，数据湖可以接受和存储的数据种类要灵活得多，甚至可以是完全非结构化的数据。通常，数据仓库是结构化的，有专门的软件来优化数据的存储和访问，而数据湖是非结构化的，使用非专有软件，这明显降低了成本，但没有优化数据访问。成本通常是在两种格式之间做决定时的重要考量因素，较低的成本允许组织可以低成本的长期存储数据。
“因此，”Ted 总结道，“仓库是结构化的，拥有专有的软件和数据格式，因此具有更好的性能。数据湖是非结构化的，没有专有软件，因此性能较低，但这使得它们更便宜，可以更灵活的接受任何类型的数据。我说对了吗？”
”简而言之，是的。“Debby 同意道。然而这条界线已经模糊了，拥有专有软件的数据仓库也可以将非专有格式的数据存储为外部表。但是，达不到传统数据仓库的性能，并且可能会增加成本。因此，许多组织遵循双重模式：
- 数据湖用于长期数据存储、非结构化存储和性能不太关注的分析需求。归档系统、机器学习需要获取的长期数据等都属于这一类。
- 短期的、访问频率从中到高的数据和需要性能的地方可以使用数据仓库。短期报告或商业智能功能以及假设分析在这里就很好用。
一般来说，与数据仓库相比，数据湖提供了更便宜但性能更差的解决方案，在许多情况下可能是可以接受的。
Debby 承认，一些供应商实际上在他们的产品中提供了这两种功能，但会强调功能的不同之处。此外，就像之前的数据仓库一样，组织也可以创建多个数据湖来解决安全性、地理偏好、技术、供应商云平台等方面的问题。一刀切不是万能的，所以大多数组织都有多个数据湖和数据仓库平台。
数据网格（Data Mesh）介绍
”我明白了，”Aaron 说，“但这和我们之前讨论的数据网格有什么关系呢？”
Debby 笑着说，关键是现在有许多不同的数据库和数据存储。多个数据仓库、多个数据湖和多个运营系统都可以作为组织内用户的潜在数据源，一个典型用户可能需要访问所有这些数据库中的数据。他们可以怎么做呢？Acme 是否需要创建一个超级数据仓库，并从所有其他源复制所有数据，让所有分析用户访问单个数据存储？如图 7 所示。
图 7. 超级数据仓库
Debby 停顿了几秒，好让大家思考这个问题的重要性。
Ted 说：“建造这样一个超级数据湖或数据仓库不仅极其昂贵，而且增加了时延，这使得它远不如追踪源本身那么有吸引力，所以这是不现实的。”
“准确地说，”Debby 同意道，“这就是为什么 Acme 没有选择这样做的原因。”相反，Acme 认识到将会有多个合法的数据源，每个数据源都有其独特的技术、数据格式等，并且客户可以自由地从最相关的数据源中提取他们想要的数据，如图 8 所示。
图 8. 数据网格
Debby 解释说，有多个数据存储可供所有用户访问，这些数据库中的数据不需要复制到中央数据仓库或数据湖中。
然后 Debby 向大家介绍这样做的好处：
- 没有中心化数据湖或数据仓库，因此，与之相关的成本不再是一个问题，而这个成本是相当大的。
- 对客户可用的数据没有时延，因为没有 ETL 将数据移动到中央数据存储中，所以数据可以立即使用。
- 没有中央数据存储，所以不用争论它应该是数据湖还是数据仓库，每个数据存储都可以配置为数据湖或数据仓库。
- 因为没有中央数据存储，所以没有关于技术的争论，每个数据存储都可以用适当的技术存储数据。例如，数据库 1 可以是一个内置 Hadoop 集群，而数据库 2 可以是一个为时间序列数据构建的云本地数据存储。
- 每个数据库都是独立管理的，其中一个不可用并不影响对其他的访问。
- 每个数据库都可以决定自己的授权策略。授权指的是用户访问数据集的能力。每个数据存储可以遵循其自己的权限管理系统，无需拥有中心化权限系统。
不是个好主意吗?
Aaron 似乎并不相信：“这些都是很好的理由，但肯定有不那么令人满意的东西。”
“是的，有。”Debby 同意道。首先，最后一个优势：权限的独立性，在某些情况下可能是劣势。由于权限管理通常是特定于数据库技术的，因此需要在数据存储中管理用户访问数据的权限。这给用户获取所需数据带来了复杂性。因此，当需求发生变化时，很难确定应该从用户那里撤销哪些访问权限。单一的中央数据存储将具有单一的权限管理系统，因此管理权限将容易得多。然而，Debby 断言，与优点相比，这只是一个小缺点。
大家表示赞同。
“但用户怎么在所有这些数据库中找到他们要找的东西呢？”Ted 问道。
“啊哈！这是数据存储的一个长期问题，”Debby 笑着说。“答案是什么？一个中央数据目录（Data Catalog）。”
大家想要了解更多，但他们意识到时间已经到了，因此不情愿的离开了视频电话会议。Debby 答应他们以后会再举行一次会议来继续这个问题的讨论。
结论
总的来说：
- 数据网格只是允许用户访问符合其数据需求的最符合逻辑的位置，而不是将数据复制到一个中心位置。
- 每个数据库都是独立管理的。
- 每个数据库都可以使用最适合达成目标的技术。
- 这些数据存储的数据总是最新的。
- 一个中央目录和一个授权过程使这种设置成为可能。
References:
[1] https://arupnanda.medium.com/what-is-data-mesh-anyway-c65886cab127
