数据系统的源头

数据网格解决了大规模数据环境中，异构数据的存储、访问问题。要了解数据网格，就需要从数据系统的源头开始，了解数据系统是如何从硬编码、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指向行数据库。在事务系统中，应用程序和用户通常只选择少量的行及其所有的列。由于选择了所有列，系统将不得不读取所有列数组并从中选择几行，这又将显著影响性能。类似的，更新和删除个别记录在事务系统中很常见，但在仓库中却不常见，因此，列式设计会损害事务系统。列式系统针对聚合查询进行了优化，