《云数据湖》第六章：数据格式的深度探究-灵析社区

第六章：数据格式的深度探究

设计不仅仅关乎外观和感觉，设计是关于它的运作方式。 ———史蒂夫·乔布斯

传统上，数据仓库是建立在专有的数据格式上的，通过优化查询模式来提升性能。随着云数据湖的应用场景越来越多，尤其是湖仓一体化架构的兴起，越来越多的客户和解决方案提供商正在投资于能够直接在云数据湖上运行类似仓库的查询的功能。这使我们更接近实现一种架构的承诺，即在特定用途下最小化在数据存储之间来回复制数据的需求。这种无障碍数据存储的承诺导致了越来越多的开放数据格式的出现，这些格式使得可以直接在云数据湖存储上运行类似仓库的查询。在本章中，我们将详细介绍三种这样的格式：Apache Iceberg、Delta Lake和Apache Hudi。本章可能是本书中最技术性的一章，我们将对这些格式进行详细的探讨，包括它们是如何满足设计目标的。我希望这一章能为您提供足够的知识，以了解这些格式的设计原因，这样当您评估其中一种格式时，可以提出正确的问题，找到适合您的云数据湖架构的正确数据格式。

为什么我们需要这些开放数据格式？

如果我必须用一句话总结对开放数据格式的需求，我会说开放数据格式本质上使得云数据湖存储能够存储表格数据。这引出了两个问题：为什么我们需要存储表格数据，以及为什么在云数据湖存储中存储表格数据会成为一个问题？让我们详细探讨这些问题。

我们为什么需要存储表格数据呢？

在《数据格式》一章中，我提到了存储在云数据湖中的数据的关键假设，如下所示：

存储在数据湖中的活跃交易数据在很大程度上以表格格式存在（按行和列组织）。
写入一次的数据会被多次读取。
读取模式主要依赖于对数据的条件选择，其中具有某些列相似值的数据会被过滤返回或进行聚合分组。

让我们看看为什么存储在数据湖中的数据通常是表格形式。虽然大数据分析系统中的数据可以来自任何来源，具有任何大小和格式，正如《什么是大数据？》中所示的六个V（体量、速度、多样性、价值、准确性、可视化），但这些数据本身被认为价值较低，噪音较多。大数据架构的主要价值主张是从这些价值较低的数据中生成高价值的洞察。生成这些高价值洞察的过程涉及各种操作，主要归类为几个高级类别，详见表6-1。

表格数据结构适用于这些常见的数据湖操作，因为它提供了将相似数据组合在一起的灵活性。当相似数据被分组时，获取所需数据子集并进行计算所需的交易次数更少。这就是为什么大多数数据格式都优化了存储表格数据。

在大数据分析系统中，进入系统的数据不一定是表格形式；然而，正如之前所说，这些数据被认为是低价值的原始数据。这些数据经过一系列转换，作为第一步转换为表格数据，然后再进行进一步处理。您可以回顾《数据的一天》以了解更多关于数据湖区域的信息。除原始数据区域以外的其他区域中的数据通常具有表格性质。

在云数据湖存储中存储表格数据为什么会成为问题呢？

当你想到表格数据时，你可能直观地想到一个可以将数据按行和列进行组织的电子表格。大多数数据库和数据仓库的存储方式都是按照这种方式进行组织的。然而，正如我们在《云数据湖存储》中所看到的，数据湖架构使用的存储是通用的对象存储，旨在存储各种类型的数据而不施加任何限制。因此，用于存储支持网站、博客以及在线相册中的照片等内容的系统，也用于存储用于大数据分析应用的数据。这样做非常具有吸引力的主要原因是低成本和能够存储任何大小和格式的数据，而不会施加任何限制；这种组合使得组织可以将所有他们拥有的数据带入数据湖存储，而不会耗尽资金。

与此同时，数据湖存储本身在存储和处理表格数据方面具有一些明显的限制，如下所示：

现有数据的更新

数据湖存储系统主要是追加写入的存储系统。这意味着如果需要替换现有的任何数据，这个过程并不是非常直接。

模式强制和验证

模式指的是数据本身的描述。例如，我们知道地址具有以下字段：街道地址、城市名称、缩写州名和邮政编码。对象存储系统无法保证存储的地址具有所有这些字段。

正如我们在第5章中详细讨论的那样，确保数据湖的性能需要考虑许多因素。然而，所有这些因素都依赖于从业人员为其设计，而不是开箱即用的保证，因为对象存储系统本身不能保证性能。

由于其灵活性和低成本，云数据湖架构得到了广泛采用。因此，越来越多的业务关键查询和仪表板依赖于存储在通用对象存储中的数据。为了确保存储在通用对象存储系统中的数据可以针对支持业务关键场景的核心数据湖计算进行优化，客户和云数据从业者孵化了各种开放数据格式，这些格式主要对数据的表格性质提供了保证。处理数据的计算引擎也能理解这些开放数据格式，从而确保了优化的性能。尽管孵化出了越来越多的数据格式，但我们将深入研究其中的三种格式：Delta Lake、Apache Iceberg和Apache Hudi。

Delta Lake

Delta Lake是由Databricks（由Apache Spark的创始人创建的公司）孵化和维护的开放数据格式。正如我们在《Apache Spark》中所看到的，Apache Spark在云数据湖架构中实现了统一的编程模型，涵盖了各种场景，如批处理、实时流处理和机器学习场景。拼图的最后一块是消除需要数据仓库来支持BI场景的孤立。Delta Lake是Databricks推广的数据湖仓库模式的基础，除了批处理、实时处理和机器学习场景外，组织还可以直接在云数据湖存储上运行BI场景，而无需单独的云数据仓库。

为什么创建了Delta Lake呢？

Delta Lake成立作为数据湖仓库模式的基础构建模块，提供以下价值主张。

消除业务分析师、数据科学家和数据工程师之间的数据孤立。

正如在《Apache Spark》中所介绍的，Apache Spark的创建基于提供灵活的编程模型，支持各种应用程序，如批处理、实时流处理和机器学习。Apache Spark在客户采用率和关注度方面取得了广泛的成功，并且持续增长。通过Apache Spark，客户可以使用一种适用于数据工程师进行核心数据处理以及数据科学家进行机器学习场景的单一编程模型。然而，仍然需要将数据复制到数据仓库中，以便业务分析师能够利用类似SQL的语言进行查询，因为数据仓库提供了优化的查询性能。我们在《为什么需要这些开放数据格式？》中讨论的云对象存储的限制成为了这一过程的阻碍。Delta Lake是由Databricks创建的开放数据格式，使业务分析师可以直接利用云数据湖进行查询，为组织实现了数据湖仓库架构。

为批处理和实时流数据提供统一的数据和计算系统。

在洞察力方面，组织往往关注两个不同的方面：了解当前发生的情况以及从历史数据中了解模式。例如，当市场团队在社交媒体上发布一篇文章时，他们希望了解这篇文章当前的趋势。同样地，当他们在进行下一次营销活动时，他们会利用历史数据来了解过去的活动趋势，以帮助指导他们的策略。实时流处理是指对进入大数据湖的数据进行即时洞察的分析，即当前的情况。计算重点放在最近的数据上，以提高处理速度。然而，如果你想基于历史数据进行洞察，那么你会使用批处理管道对存储在数据湖中的数据进行处理。支持这两种路径的架构模式被称为lambda架构，它包括用于实时分析的热路径和用于分析历史数据的冷路径。虽然Spark提供了统一的编程语言来处理实时和批处理，但传统上实时和历史数据的分析是通过不同的数据管道进行的。Delta Lake减少了对这两条不同路径的需求。图6-1展示了lambda架构的图示表示。

支持对现有数据进行批量更新或更改

正如我们之前学到的，数据以低价值的原始数据的形式进入数据湖，并经过多次转换生成高价值的结构化、策划数据。随着原始数据的更改，这也会影响策划数据。新进数据通常会在高价值的策划数据中更改多行和多列，这并不罕见。举个例子，假设有一个包含四行四列的数据集，如图6-2所示。随着新数据的到来，行A被修改，行C被删除，行CC被新增到表中。对象数据存储层无法以简单的方式处理对现有数据的增量更新。因此，通常情况下，数据从头开始生成整个表。正如我们已经知道的，无论是从成本还是工程能量的角度来看，这都不是理想的解决方案。此外，如果在重新计算数据集时，数据使用者正在读取该数据集，他们将看到不准确或部分结果，因此这种重新计算需要在没有读取者的情况下进行，并且必须进行适当的协调。Delta Lake提供了一种管理这些增量更新的方式，无需对整个数据集进行更新，并且使数据的使用者能够在执行更新时继续读取数据集。

处理由于模式更改和不正确数据引起的错误

在表格数据格式中，模式指的是行和列值需要遵循的规范或描述。因为云数据湖存储系统对数据的大小或形状没有任何限制，所以输入的数据可能会有一些缺失部分，从而不符合计算引擎所期望的模式。例如，如果有一个包含地址的数据集，并且该数据集中有一些记录没有街道地址或邮政编码，从该数据集提取地址的计算引擎将会失败。同样地，随着时间的推移，数据源可能会添加新的字段或更改现有字段，计算引擎可能会因为同一数据集中存在旧数据和新数据，而导致混淆。这种情况的示例如图6-3所示。Delta Lake通过提供模式强制和模式验证的功能，可以优雅地处理这些场景，因此您可以确保对这些数据进行检查，并主动通过修复缺失值或拒绝不符合模式的记录来纠正这些问题。

这听起来非常棒。Delta Lake如何实现这些场景呢？Delta Lake致力于在数据湖存储中提供数据的ACID保证：原子性、一致性、完整性和持久性，为实现先前描述的场景奠定了基础。如果您想了解更多关于ACID事务的信息，请参阅《数据湖仓库的参考架构》。让我们来看看Delta Lake的内部结构以及它如何实现这些场景。

Delta Lake是如何工作的？

Delta Lake是一种用于在数据湖存储系统中存储表格数据的开放式存储格式，提供ACID保证。Delta Lake表由以下组件组成：

Data objects:

实际数据以Parquet文件的形式存储在表格中。您可以在《探索Apache Parquet》中了解Apache Parquet背后的概念。

Log:

事务日志或账本，用于跟踪表格中数据的更改。这些更改被称为操作，以JSON格式存储。Delta日志跟踪数据本身的更改，即插入、删除或更新操作，以及元数据或模式的更改，例如表格中的列的添加或删除。

Log checkpoints:

日志的压缩版本，包含到某个特定时间点的非冗余操作。考虑到随着时间的推移，对数据进行的操作数量可能很大，日志可能会变得非常庞大，因此日志检查点可作为性能优化的一种方式。

Delta Lake文档页面提供了有关如何使用Delta表格的详细说明。创建Delta表时，还会为该表创建一个日志。表格中的所有更改都记录在日志中，而这个日志对于保持表格中数据的完整性至关重要，从而提供了我们讨论的保证。

如图6-4所示，向Delta表进行写操作涉及两个组件：

通过修改Parquet文件对数据对象进行更新。
更新Delta日志，并将该修改与Delta日志中的唯一标识符相关联。

除非两个操作都完成，否则写操作将无法成功。因此，如果对表格进行了两次同时进行的写操作，它们会自动按顺序通过此日志进行串行化。第二次写操作需要等待第一次写操作成功并更新了日志后，才能完成自己的写操作并更新日志。有了这个带有事务账本的日志，调用者还可以进行时间穿梭，访问过去版本的数据。

除了提供ACID保证和支持时间穿梭等场景外，Delta表还提供了模式强制执行功能，您可以确保数据符合您指定的模式（例如，邮政编码必须是五位整数），以及模式演化功能，您可以通过设置默认值来确保较旧的数据与添加新列和演化的模式兼容。这使得在数据湖上实现类似SQL的场景成为可能。

何时你会使用Delta Lake

Delta Lake为存储在通用对象存储中的数据提供了更强的保证。需要记住的一点是，对于以Delta Lake格式存储的数据，您需要利用理解该格式的计算引擎来充分利用其功能。我建议您在预期要运行类似SQL查询或为机器学习模型提供数据集的数据上使用Delta Lake，以便能够保留版本信息。如果您使用Apache Spark，您可以在最小的修改下充分利用现有的管道，将现有数据转换为Delta Lake格式。

Apache Iceberg

Apache Iceberg是由Netflix作为孵化器开发的，它在数据湖存储上支撑着关键业务应用，而这些应用在《为什么在云数据湖存储中存储表格数据是个问题？》中描述的不足之处上运行。

为什么会创建Apache Iceberg？

Netflix是一家流行的视频流媒体公司，从一开始就建立了一个高度数据驱动的公司。数据支持其关键业务场景，例如根据用户的观看模式提供推荐内容，了解Netflix需要创建或分发的内容类型以吸引用户群体，并监控其服务的健康状况，仅举几例。尤其在像视频流媒体这样竞争激烈、市场上存在多个竞争对手的领域，数据驱动的洞察和业务是Netflix的关键区别之一。

根据Netflix技术博客的说法，Netflix使用的数据集存储在不同的数据存储中：Amazon S3作为支持其云数据湖的通用对象存储；MySQL作为操作性数据库；还有Redshift和Snowflake等数据仓库，仅举几例。Netflix的数据平台确保这些多样的数据存储作为一个单一的数据仓库对其消费者具有互操作性。这在图6-5中有所描绘。

具体来说，Netflix在其托管在Amazon S3的云数据湖中的数据上利用了Apache Hive表。Apache Hive表利用Apache Hadoop生态系统提供了一种表格格式，可用于运行类似SQL的查询。Netflix在通用对象存储解决方案中遇到了以下限制：

对现有数据集的更新

正如我们之前在《Delta Lake是为什么而创建的？》中所看到的，对象存储系统无法很好地处理对现有数据的更改。强一致性是指读取始终返回最后写入的数据的行为。AWS在2020年宣布了强一致性写入。然而，在Apache Iceberg成立时，Amazon S3提供的是最终一致性写入，这无法为Netflix用户提供可预测的读取数据。为了克服这个问题，写入操作需要以一种不与读取操作冲突的方式进行协调和编排。

Apache Hive的性能

Apache Hive将数据存储在对象存储文件系统中的文件和文件夹中。这意味着每当需要查询数据时，都需要列举文件和文件夹以找到感兴趣的数据。随着数据规模增长到PB级别，需要在该规模上列举文件变得非常昂贵，并为查询创建了性能瓶颈。

Apache Iceberg于2018年作为开源项目孵化，旨在克服在云数据湖上使用表格时遇到的这些限制。

Apache Iceberg是如何工作的？

有趣的是，Apache Iceberg建立在现有数据格式之上，因此您可以在现有数据上使用它。物理数据以Apache Parquet和Apache ORC等开放数据格式存储。描述Apache Iceberg的最简单方式是将其视为物理数据存储（Apache Parquet或Apache ORC）与如何组合和结构化形成逻辑表之间的翻译层。

Apache Iceberg将贡献到表格的文件存储在一个持久的树状结构中。表格的状态存储在多个描述元数据的文件中，包括：

一个目录文件，其中包含指向元数据最新版本的指针，它是最新元数据位置的主要来源。
一个快照元数据文件，用于存储有关表格的元数据，例如模式、分区结构等。
与该快照相关联的清单列表，其中每个清单文件都有一个条目。
一组清单文件，其中包含实际存储数据的文件路径列表，以及有关数据本身的指标，如数据集中列的最小值和最大值。

该清单还包含有关数据集的元数据，例如列的上下界，类似于行组头信息。这在图6-6中有所描绘。

让我们来看一个示例，介绍Apache Iceberg如何进行写入操作，如图6-7所示。

初始时，Apache Iceberg表格具有行A、B、C和D，并存储在两个数据文件中。存在指向这些数据文件的清单文件，以及包含指向这两个清单文件的指针的清单列表。让我向您介绍Apache Iceberg在管理对数据集进行更改时的步骤：

首先，当对行A进行修改时，该数据将被写入一个新的数据文件，并创建一个新的清单文件来指向该新行。然后创建一个新的快照，并将其保存在清单列表文件中。接下来，Apache Iceberg更新目录，使其指向这个新的清单列表文件。只有当所有这些操作都成功完成时，写入才会成功，并且仅当目录文件更新元数据指针到最新版本时，写入操作才会完成；这样可以控制多个写入操作。
当删除行C并插入行CC时，会重复类似的过程，目录现在指向数据的最新版本。
当有一个读取查询只针对行A和B进行过滤时，清单文件可以帮助指示可以跳过包含行CC和D的数据文件，从而避免不必要的文件读取，提高查询性能。

何时我们使用Apache Iceberg?

与Delta Lake类似，Apache Iceberg用于策划数据和增强数据区域，其中数据采用表格格式，并用于查询。它在需要强大保证的数据中具有优先级。由于更新频繁，通常用于表格中的策划数据区域。Apache Iceberg非常适合在不需要特定格式的基础数据的情况下，需要对数据进行结构保证的场景。Apache Iceberg在架构中提供以下功能，您可以利用这些功能：

支持模式演化：当模式更新时，即添加新列或删除现有列时，这些更新会被保留在快照中，您可以利用它们来了解模式随时间的演变。
数据分区优化：如同我们在《数据格式》中所看到的，将相似的数据放置在一起可以提高查询性能，因为您优化了最小事务数以获取所需的数据。当基础数据发生变化时，您可以继续更改数据文件的组织方式并更好地对数据进行分区，而应用程序仍然可以调用清单，而无需了解这些优化，从而灵活地优化数据布局而无需担心影响应用程序。
时间旅行或回滚：在机器学习场景中，模型是使用特定版本的数据构建的，随着数据的变化，模型的行为也会改变。在Apache Iceberg中，您可以通过关联特定的快照或版本，将应用程序与数据的某个版本关联起来，从而保存特定版本的数据快照。这个概念被称为快照隔离。此外，如果您的更新有问题或错误，您可以更轻松地管理快照并回滚到以前的版本。

尽管Netflix孵化了Apache Iceberg，但它已被多个客户和数据提供商广泛采用作为数据湖的开放数据格式。Apache Iceberg已被Apple、Airbnb、LinkedIn和Expedia Travel等组织采用。此外，数据平台提供商如Dremio、Snowflake和AWS在其云服务中提供了对Apache Iceberg的原生支持。

Apache Iceberg与Delta Lake非常相似，都提供了数据湖中数据的表格结构；然而，它们实现这一目标的方式是通过元数据层。Apache Iceberg还支持非Parquet文件格式，因此如果您需要以不同格式的数据具有表格表示，Apache Iceberg非常适合。通过扫描计划等功能，您可以快速缩小查询感兴趣的大型数据集，从而大大优化在大型数据集上操作的性能。

Apache Hudi

Apache Hudi是由Uber孵化的，Uber最初是最早的打车应用之一。多年来，Uber发展成为一家移动服务提供商，提供额外的服务，如食品配送（Uber Eats和Postmates）、包裹投递、快递员、货运运输、与Lime合作提供电动自行车和电动滑板车租赁服务，以及与当地运营商合作提供渡轮运输服务。Uber快速扩张的基础在于该组织的数据驱动文化。数据和先进的机器学习能力支持Uber的关键业务运营，如预测司机的预计到达时间、为Uber顾客提供有意义的晚餐订购建议，以及确保乘客和乘客的安全，等等。这些功能的及时性，即实时推荐或操作，对于确保出色的顾客体验至关重要。当然，这对于Uber的客户满意度和品牌非常重要。面对与Netflix类似的挑战，以及其他涉及实时洞察力重要性的挑战，Uber孵化了Apache Hudi，以提供对数据湖中数据的强大保证和及时洞察力。Apache Hudi旨在支持这些操作和大规模的数据保证，在2020年的150 PB数据湖上支持每日约5000亿条记录的更新，随着Uber作为业务的不断扩大，这个规模还在增长。

为什么Apache Hudi会被创建？

Apache Hudi的动机与Apache Iceberg和Delta Lake基本相似，即旨在克服用于数据湖存储的通用对象存储的固有限制。具体而言，Uber希望解决以下情况：

高效写入的Upserts

Upsert是一种概念，当数据不存在时，将其作为插入操作进行写入，如果行已存在，则将其作为更新操作进行写入。在不支持upsert的情况下，会出现多行而不是一行，需要编写额外的计算来获取这些行并筛选出最新的数据。这种解决方案成本更高，处理时间更长。对象存储系统主要是追加写入，不具备内在支持upsert的概念。

理解增量修改

正如我们在之前的章节中所看到的，数据处理管道运行作业以处理大量数据集，生成高度精选的数据，这些数据包括输入数据的聚合、过滤和连接版本。通常情况下，当输入数据发生变化时，这些处理引擎会重新计算整个数据集上的精选数据。为了加快洞察力的获取时间，不需要重新处理整个批处理，可以只针对发生变化的数据集运行重新计算，从而仅处理增量变化。为了做到这一点，需要了解自上次作业以来发生了什么变化，而数据湖存储本身并不自然地支持这种操作。

支持实时洞察力

正如我们在“为什么创立Delta Lake？”中所看到的，虽然有编程模型可以在实时和批处理流之间实现统一的计算，但实际的架构和实现方式是不同的。例如，在需要做出决策的情况下，如为特定行程寻找最佳司机，将实时的司机位置数据与地图和交通优化的批处理数据结合起来，以预定最佳司机。类似地，在Uber Eats中提供推荐时，将实时的客户点击流数据与可能存储在图数据库中的推荐数据相结合，以提供正确的推荐。再次强调，数据湖存储本身并不是为这些情景而设计的。

Apache Hudi的主要设计目标是通过支持upsert和增量处理来提高效率，从而实现数据的及时更新，而无需从头重新计算整个数据集。

Apache Hudi是如何工作的？

Apache Hudi，像其他格式一样，是一种用于存储表格数据的开放数据格式。在支持实时流式处理场景和批处理场景的lambda架构中，数据有两种写入模式：

连续摄入大量数据-想象一下大量的Uber车辆实时传输信息。
批量大规模摄入数据-想象一下每日定期执行的销售或营销数据的导入。

为了支持这些模式，Apache Hudi提供了两种类型的表格：

写入时复制（Copy on Write）

有一个真实数据源，读写表格的操作都与此数据源进行交互。每次写入操作都会立即以更新的形式写入Apache Hudi表格，并且这些更新会近实时地反映给读取者。数据以针对读取进行优化的列式格式（如Apache Parquet）进行存储。

读时合并（Merge on Read）

每次写入操作都会以优化写入的数据格式（如行式数据格式，如Apache Avro）写入缓冲区。然后，这些数据会更新到供读取者使用的表格中，其中数据以列式格式（如Apache Parquet）进行存储。

Apache Hudi由三个主要组件组成，这些组件用于存储表格的数据：

数据文件（Data files）包含实际数据的文件。对于写入时复制的表格，数据以列式格式存储。对于读时合并的表格，数据以增量写入的形式存储在行式格式中，并与完整数据集以列式格式存储在一起。
元数据文件（Metadata files）元数据文件是表格上存储的所有事务的完整集合，按照时间顺序进行排序。Apache Hudi表格上有四种类型的事务：

提交（Commits）将一批记录作为原子写操作写入Apache Hudi表格中的数据集。
Delta提交（Delta commits）将一批记录作为原子写操作写入增量日志中，并稍后将其提交到数据集。此操作仅适用于读时合并类型的表格。
压缩（Compaction）通过重新组织文件结构来优化存储的后台进程，将增量文件合并到数据集的列式格式中。
清理（Cleans）删除不再需要的旧版本数据的后台进程。

索引（Index）一种数据结构，用于高效查找属于事务的数据文件。

Apache Hudi表格支持三种类型的读取操作：

快照查询（Snapshot queries）查询Apache Hudi表格中存储的特定快照数据。快照指的是给定时间点的数据版本。该查询返回与查询条件匹配的所有数据。
增量查询（Delta queries）查询在给定时间段内发生变化的数据。如果只关注数据的变化情况，可以使用增量查询。
优化读取查询（Read optimized queries）这种查询类型适用于读时合并的表格，返回以优化读取为目标存储的数据。该查询不包括尚未合并的增量文件中的数据。这种查询经过优化以提供更快的性能，但代价是数据可能不是最新的。

让我们将这些概念结合起来，通过一个具体的例子来了解Apache Hudi的工作原理。

Copy-on-write表

图 6-8 给出了对复制写表格上的事务的图形表示。

在复制写表格中，每次写操作，无论是插入新行、更新现有行还是删除现有行，都被视为一个提交操作。数据集的唯一真实源头以列格式保留，并且每次写操作都是一个原子操作，更新数据集。这些真实的快照被保留下来，可以看到数据在特定时间点的状态。在此支持的查询类型有快照查询和增量查询。

Merge-on-read表

图6-9展示了合并读取表格上的事务的图示表示。尽管这在很大程度上与复制写表格相似（如图6-8所示），但这里的关键区别是真实源头是分布式的。

在合并读取表格中，存在一个以列式数据格式优化读取的数据集，而写入操作则以写入优化格式存储在增量日志中，然后将其压缩成列式数据格式的主数据集。这些表格支持三种类型的查询：快照查询返回给定时间点的数据集版本，增量查询仅返回发生更改的数据，读取优化查询返回列式数据格式的数据集，提供更快的性能，但不包括尚未压缩的数据。

何时使用Apache Hudi?

Apache Hudi通过其支持不同类型的查询的不同类型的表格，为数据提供了强大的保证，包括原子写入和数据版本控制，从而提供更大的灵活性。Apache Hudi最初由Uber孵化，但随后在其他公司中得到了广泛的采用，如亚马逊、沃尔玛、Disney+ Hotstar、GE航空、罗宾汉和TikTok。近期成立的Onehouse公司提供了一个基于Apache Hudi构建的托管平台。

Apache Hudi旨在支持需要以实时和批量方式处理高频写入的表格。它还提供了根据性能和数据实时性要求使用不同类型查询的灵活性。

总结

在本章中，我们深入探讨了数据格式，并了解了这些数据格式如何提供强大的数据保证，改善查询性能，并通过利用数据湖存储降低成本。我介绍了Delta Lake及其用途。我还描述了由运行大规模数据湖的客户孵化的数据格式：Apache Iceberg和Apache Hudi。这些开放的数据格式可以实现真正无障碍的数据湖，可以支持各种计算，满足数据工程师、机器学习工程师、数据科学家和BI分析师的需求。尽管这些数据格式取得了重大进展，但构建基于这些数据格式的数据湖仍需要陡峭的学习曲线和强大的数据平台团队。像Dremio、AWS和Onehouse等数据解决方案提供商正在构建提供开箱即用的湖仓解决方案的托管数据平台解决方案。Tabular是一个相对较新的组织，他们基于Apache Iceberg提供了一个数据平台。根据组织的动机和工程资源，您可以在云数据湖上实现湖仓。在下一章中，我们将集中讨论端到端的决策策略，将我们在前六章中涵盖的所有概念整合起来。