本章介绍了Delta Lake的起源及其最初设计旨在解决PB级系统中的数据完整性问题。如果你对Delta Lake的历史已有了解，并且想深入了解Delta Lake是什么，它的架构以及Delta事务协议，可以跳到本章后面的“什么是Delta Lake？”部分。

Delta Lake的诞生

在本节中，我们将简要回顾Delta Lake的演变历程：它的起源和灵感来源，以及作为湖仓格式在社区中的采用，确保每个企业最重要资产——数据的完整性。Delta Lake湖仓格式的开发旨在解决传统数据湖和数据仓库的局限性。它提供了ACID（原子性、一致性、隔离性、持久性）事务、可扩展的元数据处理，并在一个平台上统一了各种数据分析任务，例如批处理和流处理工作负载、机器学习和SQL查询。

数据仓库、数据湖和湖仓

在数据系统中，经历了许多技术进步（例如高性能计算[HPC]和对象数据库）；对于过去几十年中在查询和聚合大量业务数据系统方面的技术进展，可以简化为数据仓库、数据湖和湖仓的演变。总体来说，这些系统都用于解决在线分析处理（OLAP）工作负载。

数据仓库

数据仓库是专门构建用于快速聚合和处理大量结构化数据的系统（见图1-1）。为了保护这些数据，数据仓库通常使用关系数据库来提供ACID事务，这是确保业务应用数据完整性的重要步骤。

数据仓库在ACID事务的基础上，包含了管理功能（如备份与恢复控制、门控控制等），以简化数据库操作，并且具有性能优化（如索引、分区等），从而更快速地为最终用户提供可靠的结果。尽管数据仓库功能强大，但在面对大数据场景中的大量数据、各种分析需求（包括事件处理和数据科学）以及数据流速时，往往很难扩展以应对这些挑战。这一局限性是一个关键因素，通常需要使用更具扩展性的解决方案，如数据湖或分布式处理框架（如Apache Spark）。

数据湖

数据湖是可扩展的存储库（如HDFS、云对象存储，如Amazon S3、ADLS Gen2和GCS等），用于存储大量原始数据，直到需要时才进行处理（见图1-2）。与传统数据库不同，数据湖设计用于处理互联网规模的数据量、数据流速和数据种类（例如结构化、半结构化和非结构化数据）。这些特征通常与大数据相关联。数据湖改变了我们存储和查询大量数据的方式，因为它们被设计成能够将工作负载分布到多台机器或节点上进行扩展。数据湖是基于文件的系统，运行在商用硬件的集群上。传统上，数据仓库是通过单机扩展的；需要注意的是，尽管大规模并行处理的数据仓库已经存在很长时间，但它们通常成本较高，且维护复杂。同时，虽然数据仓库主要设计用于结构化（或表格）数据，数据湖则可以以任何用户选择的格式存储数据，为开发人员提供了更大的存储灵活性。

虽然数据湖可以处理所有与数据科学和机器学习相关的数据，但它们本质上是一种不可靠的数据存储形式。数据湖并不提供ACID保护，而是遵循BASE模型——基本可用、软状态、最终一致。缺乏ACID保证意味着存储系统在处理失败时会导致存储处于不一致状态，出现孤立的文件。随后对存储系统的查询可能包括一些不应该出现的文件，从而导致重复计数（即错误的结果）。

这些不足之处共同作用，可能导致基础设施不适合BI查询，出现不一致和缓慢的性能，以及复杂的设置。由于缺乏事务保护、模式管理等，数据湖的创建往往会导致不可靠的数据沼泽，而非干净的数据存储库。

湖仓（Lakehouses）

湖仓将数据湖和数据仓库的最佳特性结合起来，用于OLAP工作负载。它将数据湖的可扩展性和灵活性与数据仓库的管理特性和性能优化融合在一起（见图1-3）。此前曾有过一些尝试，旨在让数据仓库和数据湖并行共存。但这种方法代价高昂，带来了管理复杂性、数据重复以及不同系统间报告、分析、数据科学的协调问题。随着数据工程实践的发展，湖仓的概念应运而生。湖仓消除了需要多个不连贯系统的情况，提供了一个统一的、连贯的平台，适用于所有形式的数据分析。湖仓提高了数据查询的性能，并简化了数据管理，使组织更容易从数据中获得洞察。

Delta Lake、Apache Iceberg和Apache Hudi是最受欢迎的开源湖仓格式。正如你所猜测的，本书将重点介绍Delta Lake。

从“Project Tahoe”到Delta Lake：早期的几个月

2021年在线聚会《From Tahoe to Delta Lake》回顾了Delta Lake的创建历程。此次面板讨论邀请了“老派”开发者和Delta Lake的维护者Burak Yavuz、Denny Lee、Ryan Zhu和Tathagata Das，以及Delta Lake的创始人Michael Armbrust，还包括“新派”Delta Lake维护者，创建了delta-rs项目的QP Hou和R. Tyler Croy。

Delta Lake的最初项目名称是“Project Tahoe”，因为Michael Armbrust在2017年滑雪时首次提出为数据湖提供事务可靠性的想法，而地点正是位于加利福尼亚的湖泊——塔霍湖（Lake Tahoe）。塔霍湖是一个标志性的大型湖泊，象征着该项目旨在创建的大规模数据湖。Michael是Apache Spark™的提交者和PMC成员，是Delta Lake的维护者，也是Spark SQL、Structured Streaming和Delta Lake的原始创始人之一，同时还是Databricks的杰出软件工程师。 从“Project Tahoe”到“Delta Lake”的名称过渡发生在2018年新年左右，由Jules Damji提出。更名的原因是希望借用自然界中河流流入三角洲的过程，河流携带的沉积物最终积累并形成肥沃的土地供作物生长。这一比喻非常契合该项目的目标，因为它代表了数据流汇聚到一个受管理的数据湖中，数据从中提炼出有价值的洞察。Delta这个名字也与项目的架构相契合，该架构设计用来处理大规模和高流速的数据流，使数据可以被处理并拆分成不同的流或视图。

那么，Armbrust为何创建Delta Lake？他创建它是为了应对Apache Spark文件同步的局限性。具体来说，他希望能够处理大规模的数据操作，并且需要强大的事务支持。因此，开发Delta Lake的动机源自于对可扩展事务日志的需求，旨在处理庞大的数据量和复杂的操作。

在Delta Lake创建初期，有两个值得注意的使用案例，突显了其高效性和可扩展性。Comcast利用Delta Lake提升了其数据分析和机器学习平台，并成功管理了PB级的数据。这一转变将其计算资源的使用从640个虚拟机减少到64个虚拟机，同时简化了作业维护，从84个作业减少到3个。通过优化处理流程，Comcast的计算资源使用减少了10倍，作业数减少了28倍。苹果的资讯安全团队则使用Delta Lake进行实时威胁检测和响应，每天处理超过3000亿个事件，并每天写入数百TB的数据。这两个案例展示了Delta Lake相比传统数据管理方法的卓越性能和成本效益。我们将在第11章中进一步探讨更多使用案例。

什么是Delta Lake？

Delta Lake是一个开源存储层，支持ACID事务、可扩展的元数据处理，并实现流数据与批处理数据处理的统一。它最初是为与Apache Spark和大规模数据湖工作负载配合使用而设计的。

通过Delta Lake，您可以构建一个统一的数据平台，选择适合的高性能查询引擎来处理各种工作负载，包括（但不限于）商业智能（BI）、流分析/复杂事件处理、数据科学和机器学习，如图1-4所示。

然而，随着Delta Lake的发展，它已经被优化设计，以支持多种工作负载（如小数据、中等数据、大数据等）。它还被设计为能够与多个框架（例如Apache Spark、Apache Flink、Trino、Presto、Apache Hive和Apache Druid）、服务（例如Athena、Big Query、Databricks、EMR、Fabric、Glue、Starburst和Snowflake）以及编程语言（.NET、Java、Python、Rust、Scala、SQL等）兼容工作。

常见使用场景

从初创公司到大型企业，各类组织的开发人员都使用Delta Lake来管理其大数据和人工智能工作负载。常见的使用场景包括：

现代化数据湖

Delta Lake通过提供ACID事务、可扩展的元数据处理和模式强制，帮助组织现代化其数据湖，从而确保数据的可靠性和性能提升。

数据仓库

数据仓库技术和方法都有不同的应用。Delta Lake湖仓格式使得可以应用数据仓库技术，为各种分析工作负载提供快速的查询性能，同时也保证了数据的可靠性。

机器学习/数据科学

Delta Lake为机器学习和数据科学团队提供了可靠的数据基础，帮助他们更快速地访问和处理数据，从而加速模型的构建和部署。

流数据处理

Delta Lake统一了流数据和批处理数据的处理。这样，开发人员就可以实时处理数据并对其进行复杂的转换。

数据工程

Delta Lake为数据工程团队提供了一个可靠且高效的平台，帮助他们构建和管理数据管道，确保数据的质量和准确性。

商业智能

Delta Lake支持SQL查询，使得业务用户可以轻松访问和分析数据，从而帮助他们做出数据驱动的决策。

总的来说，Delta Lake被数据工程师、数据科学家和业务用户等各类团队广泛使用，用于管理和分析大数据及人工智能工作负载，确保数据的可靠性、性能和可扩展性。

关键特性

Delta Lake包括以下几个关键特性，这些特性是开放湖仓格式的基础（欲深入了解这些特性，请参见VLDB研究文章《Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores》）：

ACID事务

Delta Lake确保数据修改是原子性、一致性、隔离性和持久性的，即具备ACID事务保护。这意味着，当多个并发客户端或任务访问数据时，系统能够保持数据的一致性。例如，如果在数据修改过程中出现故障，Delta Lake会回滚更改，确保数据保持一致性。

可扩展的元数据

Delta Lake表的元数据是事务日志，它根据前述的ACID事务保证事务一致性。在PB级别的表中，表的元数据本身可能非常复杂，维护起来具有挑战性。Delta Lake的可扩展元数据处理功能旨在有效管理大规模数据集的元数据，而不会影响查询或处理性能。

时间旅行

Delta Lake的时间旅行功能允许您查询表的历史版本，以访问历史数据。通过Delta事务日志实现，它使您能够指定版本或时间戳，以查询数据的特定版本。这对于数据审计、合规性检查和数据恢复等多种使用场景非常有用。

批处理/流处理统一

Delta Lake与Apache Spark的结构化流处理（Structured Streaming）一起设计，简化了流处理逻辑。与其为批处理和流处理提供不同的API，结构化流处理使用相同的内存中的数据集（Dataset）/数据框（DataFrame）API处理这两种场景。这允许开发人员使用相同的业务逻辑和API，唯一的区别是延迟。Delta Lake提供存储系统的ACID保障来支持这一统一。

模式演变/强制

Delta Lake的模式演变和模式强制确保了数据的一致性和质量，通过对写操作强制执行模式，并允许用户在不破坏现有查询的情况下修改模式。它们还防止开发人员不小心插入具有错误列或类型的数据，这对于维护数据质量和一致性至关重要。

审计历史

该功能提供了对所有数据变更的详细日志，包括谁进行了更改、更改了什么以及何时进行的更改。这对于合规性和监管要求至关重要，因为它允许用户跟踪数据的变更历史，确保数据修改操作的正确性。Delta事务日志使这一切成为可能。

DML操作

Delta Lake是最早提供数据操作语言（DML）操作的湖仓格式之一。最初，它扩展了Apache Spark，支持各种操作，如插入、更新、删除和合并（即CRUD操作）。今天，用户可以通过多种框架、服务和语言有效地修改数据。

开源

Delta Lake的根源建立在Databricks的基础上，Databricks具有丰富的开源经验（Databricks的创始人是Apache Spark的原创作者）。Delta Lake诞生后不久，便被捐赠给Linux基金会，以确保开发人员可以自由使用、修改和分发该软件，同时促进数据工程社区的合作和创新。

性能

尽管Delta Lake是一个湖仓存储格式，但它经过优化设计，可以提高查询和处理的速度，无论是数据摄取还是查询，默认配置都能提供良好的性能。虽然您可以不断调整Delta Lake的性能，但大多数情况下，默认配置已经足够适应您的场景。

易用性

Delta Lake从一开始就以简便为设计理念。例如，使用Apache Spark将表写入Parquet文件格式时，您可以执行以下命令：

lua
 代码解读
复制代码
data.write.format("parquet").save("/tmp/parquet-table")

而如果是将数据写入Delta格式，您只需执行：

lua
 代码解读
复制代码
data.write.format("delta").save("/tmp/delta-table")

Delta Lake表的结构

Delta Lake表或Delta表由几个关键组件组成，这些组件协同工作，提供一个强大、可扩展且高效的数据存储解决方案。主要组成部分如下：

数据文件

Delta Lake表将数据存储为Parquet文件格式。这些文件包含实际的数据，存储在分布式的云存储或本地文件存储系统中，如HDFS（Hadoop分布式文件系统）、Amazon S3、Azure Blob存储（或Azure Data Lake Storage [ADLS] Gen2）、GCS（Google Cloud存储）或MinIO。选择Parquet格式是因为它在存储和查询大数据集时具有高效性。

事务日志

事务日志，也称为Delta日志，是Delta Lake的一个关键组件。它是对Delta Lake表上执行的每个事务的有序记录。事务日志通过记录对表的所有更改，确保ACID属性。每个事务都会作为一个新的JSON文件记录在_delta_log目录中，其中包含关于事务的元数据，例如执行的操作、添加或移除的文件以及事务时表的模式。

元数据

Delta Lake中的元数据包括关于表的模式、分区和配置设置的信息。这些元数据存储在事务日志中，并且可以通过SQL、Spark、Rust和Python API进行检索。元数据有助于通过提供模式强制执行和演变、分区策略和数据跳跃的信息来管理和优化表。

模式

Delta Lake表的模式定义了数据的结构，包括列、数据类型等。模式在写操作时强制执行，确保所有写入表的数据都遵循定义的结构。Delta Lake支持模式演变（如添加新列、重命名列等），允许随着数据的变化，表的模式也能随之更新。

检查点

检查点是事务日志的定期快照，帮助加速恢复过程。Delta Lake默认每10次事务合并一次事务日志的状态。这样，客户端读取者可以快速从最近的检查点恢复，而无需从头开始重放整个事务日志。检查点以Parquet文件格式存储，并由Delta Lake自动创建。

图1-5是Delta Lake表结构的图示表示。

Delta事务协议

在前一节中，我们描述了Delta Lake表的结构。Delta事务日志协议是定义客户端如何以一致的方式与表进行交互的规范。其核心是，所有与Delta表的交互都必须首先读取Delta事务日志，以确定需要读取哪些文件。当客户端修改数据时，客户端会启动创建新的数据文件（即Parquet文件），然后将新的元数据插入事务日志，以提交对表的修改。事实上，许多最初的Delta Lake集成（如delta-spark、Trino连接器、delta-rust API等）都由不同的社区维护代码库。Rust客户端可以写入，Spark客户端可以修改，Trino客户端可以读取相同的Delta表，且不会发生冲突，因为它们都独立遵循相同的协议。

实现这一规范将ACID属性带入存储在分布式文件系统或对象存储中的大规模数据集合。根据规范定义，该协议的设计目标包括：

可序列化的ACID写入

多个写入者可以同时修改一个Delta表，同时保持ACID语义。

读取的快照隔离

读取者可以读取Delta表的一致快照，即使在面对并发写入时，也能保证一致性。

可扩展性到数十亿个分区或文件

对Delta表的查询可以在单台机器上进行规划，也可以并行处理。

自描述

Delta表的所有元数据都与数据一起存储。这一设计消除了维护单独的元存储的需求，使得使用标准文件系统工具可以复制或移动静态表。

支持增量处理

读取者可以跟踪Delta日志，以确定在特定时间段内添加了哪些数据，从而支持高效的流式处理。

理解Delta Lake事务日志的文件级别

为了更好地理解这一过程，让我们来看一下在创建Delta表时文件级别发生了什么。最初，表的事务日志会自动创建在_delta_log子目录下。随着对表的更改，操作会作为有序的原子提交记录到事务日志中。每次提交都以JSON文件的形式写出，从000...00000.json开始。对表的进一步更改会生成后续的JSON文件，文件名按数字顺序递增，因此下一次提交会写为000...00001.json、000...00002.json，以此类推。每个数字递增的JSON文件表示表的新版本，如图1-5所示。

请注意，数据文件的结构并未发生变化；它们作为由查询引擎或写入Delta表的语言生成的独立Parquet文件存在。如果您的表使用Hive风格的分区，您将保持相同的结构。

单一真实来源

Delta Lake允许多个读取者和写入者同时操作给定的表。它是一个集中存储库，用于跟踪所有用户对表的更改。这个概念非常重要，因为随着时间的推移，数据湖中的处理作业不可避免地会失败，导致一些部分文件没有被删除。随后的处理或查询将无法确定哪些文件应该被包含在查询中。因此，为了随时向用户展示数据的正确视图，Delta日志是唯一的真实来源。

元数据与数据的关系

由于Delta事务日志是唯一的真实来源，任何希望读取或写入Delta表的客户端都必须首先查询事务日志。例如，当我们在创建Delta表时插入数据时，最初会生成两个Parquet文件：1.parquet和2.parquet。这个事件会自动添加到事务日志，并作为提交000...00000.json保存到磁盘（见图1-6中的A）。

在随后的命令（图1-6中的B）中，我们执行了一个删除操作，导致表中的某些行被移除。Delta不会修改现有的Parquet文件（1.parquet、2.parquet），而是创建了一个第三个文件（3.parquet）。

多版本并发控制（MVCC）文件和数据观察

对于对象存储中的删除操作，创建包含未受影响行的新文件比修改现有的Parquet文件更为高效。这个方法还提供了多版本并发控制（MVCC）的优势。MVCC是一种数据库优化技术，它创建数据的副本，从而允许数据在并发读写的情况下安全地操作。这种技术还使得Delta Lake能够提供时间旅行功能。因此，Delta Lake为这些操作创建多个文件，提供原子性、MVCC和高效性。

注意
我们可以通过使用删除向量来加速这一过程，这种方法将在第8章中介绍。

图1-6中的B所示的Parquet文件的移除和创建操作，被封装在一个单一事务中，并记录在Delta事务日志中的000...00001.json文件里。关于原子性的一些重要观察点如下：

• 如果用户在没有读取Delta事务日志的情况下直接读取Parquet文件，他们将会读到重复数据，因为所有文件（1.parquet、2.parquet、3.parquet）中的行都被复制了。
• 删除和添加操作被封装在同一个事务日志000...00001.json中。当客户端查询Delta表时，它记录这两个操作及其文件路径，以代表该快照。对于该事务，文件路径将仅指向3.parquet。
• 注意，删除操作是软删除（或墓碑标记），即文件（1.parquet、2.parquet）的物理移除尚未发生。文件的物理删除将在执行VACUUM命令时发生。
• 先前的事务000...00000.json的文件路径指向原始文件（1.parquet、2.parquet）。因此，当通过时间旅行查询Delta表的旧版本时，事务日志指向构成该旧版本快照的文件。

观察元数据与数据之间的交互

虽然我们现在更好地理解了在单个数据文件和元数据文件层级发生了什么，那么它们是如何协同工作的呢？我们通过跟踪图1-7中的数据流来研究这个问题，图1-7展示了一个常见的数据处理失败场景。初始时，表由两个Parquet文件（1.parquet 和 2.parquet）表示，时间戳为t0。

在 t1 时，作业 1 提取了文件 3 和文件 4，并将它们写入存储。然而，由于某些错误（例如网络故障、存储暂时离线等），3.parquet 只写入了文件 3 的一部分，且文件 4 完全未被写入。因此，3.parquet 是一个部分文件，任何后续查询这些构成该表的文件的客户端将返回不完整的数据。

更复杂的是，在 t2 时，同一处理作业的新版（作业 1 v2）成功完成任务。它生成了新版本的 3.parquet 和 4.parquet。但是，由于部分文件 3’.parquet（被圈出）与 3.parquet 一同存在，任何查询这些文件的系统都会导致重复计数。

然而，由于 Delta 事务日志追踪哪些文件是有效的，我们可以避免出现前述情况。因此，当客户端读取 Delta Lake 表时，引擎（或 API）首先验证事务日志，查看表中已发布的最新事务。然后，它更新客户端表，反映任何新更改。这确保了客户端的表版本始终是同步的，客户端无法对表做出分歧或冲突的更改。

让我们在 Delta Lake 表上重复同样的部分文件示例。图 1-8 显示了相同的场景，其中表由两个 Parquet 文件（即 1.parquet 和 2.parquet）表示，

在 t1 时，作业 1 在创建 3.parquet 时失败。然而，由于作业失败，事务并未提交到事务日志中，因此没有新文件被记录；可以注意到，事务日志中仅列出了 1.parquet 和 2.parquet。任何在 t1 时对 Delta 表的查询都只会读取这两个文件，即使存储中有其他文件。

在 t2 时，作业 1 v2 完成，输出文件是 3.parquet 和 4.parquet。由于作业成功，Delta 日志仅包含两个成功文件的条目。也就是说，3’.parquet 不包含在日志中。因此，任何在 t2 时查询 Delta 表的客户端将只看到正确的文件。

表功能

最初，Delta 表使用协议版本映射到一组功能，以确保在 Delta 发布新功能时，用户的工作负载不会被破坏。例如，如果客户端想要使用 Delta 的更改数据提取（CDF）选项，用户需要升级协议版本并验证工作负载，以访问新功能（图 1-9）。这确保了任何与特定协议版本不兼容的读写操作会被阻止，以防止数据损坏。

但这个过程会减慢功能的采用，因为它要求客户端和表必须支持该协议版本中的所有功能。例如，在协议版本 4 中，您的 Delta 表同时支持生成列和 CDF。为了让客户端能够读取该表，它必须同时支持生成列和更改数据提取（CDF），即使您只想使用 CDF。换句话说，Delta 连接器只能实现所有功能，以支持新版本中的某个单一功能。

在 Delta Lake 2.3.0 中引入的 表功能（Table Features）取代了表协议版本，表示表使用的功能，以便连接器可以知道读取或写入表所需的功能（图 1-10）。

这种方法的优点是，任何连接器（或集成）可以选择性地实现它们感兴趣的某些功能，而不必处理所有功能。查看启用的表功能的快速方法是运行查询 SHOW TBLPROPERTIES：

arduino
 代码解读
复制代码
SHOW TBLPROPERTIES default.my_table;

输出将类似于以下内容：

要深入了解，请参考 Delta 事务协议中的“表功能”部分，访问 GitHub 页面。

Delta Kernel

如前所述，Delta Lake 提供了跨多个框架、服务和语言的 ACID 保证和性能。截至目前，每当 Delta Lake 添加新功能时，连接器必须完全重写，因为元数据和数据处理之间存在紧密耦合。Delta Kernel 通过抽象化所有协议细节来简化连接器的开发，这样连接器就不需要理解这些细节。Kernel 本身实现了 Delta 事务日志规范（如前所述）。这使得连接器只需基于 Kernel 库进行开发，带来以下优势：

模块化

创建 Delta Kernel 使得 Delta Lake Rust 和 Scala/JVM 之间更容易保持一致性，从而使两者都可以成为一等公民。所有的元数据（即事务日志）逻辑都通过 Kernel 库进行协调和执行。这样，连接器只需关注如何在各自的框架/服务/语言中执行操作。例如，Apache Flink/Delta Lake 连接器只需要关注读取或修改由 Delta Kernel 提供的特定文件。最终客户端无需理解事务日志的语义。

可扩展性

Delta Kernel 将元数据（即事务日志）逻辑与数据处理解耦。这使得 Delta Lake 更加模块化、可扩展和高度可移植（例如，您可以将整个表及其事务日志复制到新的位置以进行 AI 工作负载）。这也扩展了 Delta Lake 的可扩展性，现在连接器可以接收到读取文件的列表，而无需直接查询事务日志。Delta Lake 已经有很多集成，通过解耦元数据逻辑和数据处理，它将使我们更容易维护各种连接器。

Delta Kernel 实现了以下抽象：

• 提供稳定的 API，供连接器使用。

• 对于表扫描查询，连接器只需指定查询模式，以便 Kernel 仅读取所需的列，并且查询过滤器让 Kernel 跳过不需要的数据（文件、行组等）。这些 API 将保持稳定并向后兼容。连接器应该只需升级 Delta Kernel 版本，而不需要重写客户端代码——即它们会自动支持通过“表功能”更新的 Delta 协议。

• 内部实现协议特定的逻辑。 Delta Kernel 将实现以下所有操作：

  • 读取 JSON 文件
  • 读取 Parquet 日志文件
  • 重播日志并跳过数据
  • 读取 Parquet 数据和 DV 文件
  • 转换数据（例如，通过 DV 过滤）

  虽然 Kernel 内部实现了协议特定的逻辑，但可以添加更好的引擎特定实现（例如，Apache Spark 或 Trino 可能具有更强的 JSON 和 Parquet 读取能力）。

• 提供优化性能的 API。 这些 API 包括连接器执行表操作（如数据扫描）所需的 Table API，以及为性能敏感的组件提供优化实现的 Engine API。

截至目前，Delta Kernel 仍处于早期阶段，构建您自己的 Kernel 连接器超出了本书的范围。如果您希望深入了解如何构建自己的 Kernel 连接器，请参考以下资源：

• “[Umbrella Feature Request] Delta Kernel APIs to simplify building connectors for reading Delta tables”
• Delta Kernel—Java
• Delta Kernel—Rust
• “Delta Kernel: Simplifying Building Connectors for Delta”

Delta UniForm

如在“Lakehouses（或数据湖仓）”一节中所述，存在多种湖仓格式。Delta 通用格式（Delta Universal Format，简称 UniForm）旨在简化 Delta Lake、Apache Iceberg 和 Apache Hudi 之间的互操作性。从根本上讲，湖仓格式由元数据和数据（通常为 Parquet 文件格式）组成。

这些湖仓格式的不同之处在于它们如何创建、管理和维护与数据相关的元数据。在 Delta UniForm 中，其他湖仓格式的元数据与 Delta 格式的元数据同时生成。这样，无论您使用 Delta、Iceberg 还是 Hudi 客户端，都可以读取数据，因为它们的 API 都可以理解这些元数据。Delta UniForm 包括以下支持：

• Apache Iceberg 支持（作为 Delta Lake 3.0.0 的一部分，发布于 2023 年 10 月）
• Apache Hudi 支持（作为 Delta Lake 3.2.0 的一部分，发布于 2024 年 5 月）

有关如何启用这些功能的最新信息，请参考 Delta UniForm 文档。

总结

在本章中，我们解释了 Delta Lake 的起源、它是什么以及它做了什么、它的结构和事务协议。我们强调了 Delta 事务日志是单一的真实数据源，因此它是元数据和数据之间关系的唯一来源。尽管这一过程还处于早期阶段，但这促使了 Delta Kernel 的发展，作为简化为 Delta Lake 各种框架、服务和社区项目构建 Delta 连接器的基础。不同湖屋格式之间的核心区别在于它们的元数据，因此 Delta UniForm 通过生成所有格式的元数据将它们统一起来。