Apache Hudi 从零到一：初识表服务：压缩、清理及索引（五）

导读 本文介绍了 Apache Hudi 从零到一：初识表服务：压缩、清理及索引（五）。本文翻译自原英文博客 https://blog.datumagic.com/p/apache-hudi-from-zero-to-one-510。

主要内容包括以下几个部分：

1. 概述

2. 表服务

3. 回顾

分享嘉宾｜许世彦 Onehouse 开源项目负责人

编辑整理｜马信宏

出品社区｜DataFun

---

这个系列的前四篇文章深入探讨了读写的细节，为本篇文章所讨论的新主题——表服务，提供了充足的背景信息。本文内容将分为两个部分：第一部分将介绍表服务的概念，第二部分将涵盖三个具体的表服务——压缩、清理和索引。

01

概述

表服务可以定义为一种维护作业，它在不添加新数据的情况下操作表。在引入新记录时，我们通常优先考虑低延迟，这可能导致权衡并使存储未得到优化。运行表服务作业可以改善存储布局，为未来更高效的读写过程铺平道路。

表服务作业包括两个步骤：调度和执行。调度步骤旨在生成执行计划，而执行步骤则实施计划并对表进行实际更改。我们可以将 Hudi 中运行表服务的方法分为三种模式：内联模式（Inline）、半异步模式（Semi-async）和全异步模式（Full-async），如下所示，以提供对各种现实场景的灵活性。

表服务运行模式

在内联 (inline) 模式中，调度和执行在写入提交后同步进行，使它们“内联”。这样的操作最容易实现，因为两个步骤在现有的写入流程中自动按顺序执行。然而，显而易见的权衡是，它可能会给写入过程引入显著的延迟。

半异步 (semi-async) 模式保持内联调度并将执行与其分离，即执行异步于写入过程。在这种模式下，用户可以灵活地将服务执行器部署为一个单独的作业，甚至部署到不同的集群中，这可能是由于服务执行需要高计算资源。

全异步 (full-async) 模式是最灵活的模式，将表服务运行与写入过程完全解耦。这在管理湖仓项目中的大量表时特别有用，可以使用专门的调度器来优化调度和执行。

从 0.14.0 版本开始，Hudi 提供四种表服务：压缩、聚类、清理和索引。在接下来的部分中，我们将探讨压缩、清理和索引，并在后续文章中讨论聚类。

02

表服务

1. 压缩

回顾第一篇文章里介绍的存储布局，File Slice 在 MoR 表中可以包含多个日志文件和一个基础文件。随着新数据的进入，我们通过将所有日志文件合并到基础文件中来演化 File Slice ，从而在一个新的基础文件中创建 File Slice 的新版本。这个过程称为压缩，特定于 MoR 表。然而，这并不适用于 CoW 表，因为在写入时会自动生成新的基础文件，并且没有日志文件需要进行压缩。

在调度和执行压缩时，有很多配置需要管理。官方文档提供了详细的示例，展示了具体用法。在本文中，我们的重点是下图所示的通用内部工作流程。

Hudi 压缩工作流程

调度步骤根据可配置的压缩触发策略（CompactionTriggerStrategy）确定是否需要进行压缩。如果确定需要压缩，则生成一个压缩计划并将其保存到时间线（Timeline）中作为一个 .compaction.requested 操作。用户可以根据提交次数或经过时间等因素设置触发阈值。如果满足条件，压缩计划生成器将根据压缩策略（CompactionStrategy）扫描表格，控制哪些文件切片（File Slice）应进行压缩，并为每个文件切片生成压缩操作（CompactionOperation）以制定计划。

执行步骤从计划中加载所有序列化的压缩操作并并行运行它们。根据目标文件切片中基础文件的存在情况，使用合并句柄（MergeHandle）或创建句柄（CreateHandle）将合并记录写入新的文件切片。类似于写入过程，将返回一组写入状态（WriteStatus），报告执行过程中收集的统计数据，并在时间线上保存一个 .commit 操作，标记压缩成功。

压缩作业可能会消耗大量资源，因为在重写基础文件时会产生写放大。为了应对写放大问题，在 0.13.0 版本中引入了一个实验性的表服务，称为日志压缩（Log Compaction），仅通过将日志文件压缩成更大的文件来解决写放大问题。

2. 清理

对于新数据，Hudi 表不断添加文件切片 (File Slice) 来表示更新的版本，占用更多的磁盘空间。清理是旨在通过删除旧的和不需要的版本来回收存储空间的表服务。有关详细的使用信息，请参阅文档页面。

Hudi 清理工作流程

类似于压缩，Hudi 利用清理触发策略（CleaningTriggerStrategy）在调度时确定是否需要进行清理。目前，唯一支持的触发标准是提交次数。在配置的N次提交后，清理计划器将扫描相关分区，并根据 HoodieCleaningPolicy 确定是否有任何文件切片符合清理标准。符合条件的文件切片中的基础文件或日志文件的物理路径将用于生成一组CleanFileInfo 。然后基于此制定清理计划，并将其保存为 .clean.requested 操作。截至目前，支持三种清理策略：按提交清理、按文件版本清理和按小时清理。

清理执行相对简单：在加载计划并反序列化 CleanFileInfo 后，作业将并行执行目标文件的文件系统删除。统计数据最初在分区级别收集，然后汇总并保存到 .clean 操作中，表示清理完成。

3. 索引

索引表服务在 0.11.0 版本中首次作为实验性功能添加。目前，它的设计目的是为元数据表建立索引。由于需要事先了解元数据表的知识，我们将避免深入探讨索引过程，而是提供一个简要概述。欲了解更多信息，我建议参考官方文档、这篇博客（https://www.onehouse.ai/blog/asynchronous-indexing-using-hudi）和 RFC-45。

在第四篇文章中，我们提到了一个名为 updateLocation() 的索引 API，某些索引需要使用它来保持索引数据与写入数据同步。从表服务的角度来看，我们可以将其视为内联模式下运行的索引，即内联调度和内联执行。目前的索引服务被认为是在全异步模式下运行。元数据表可以看作是另一种包含多个索引的索引类型，也称为多模式索引。随着数据表大小的增长，内联更新元数据表可能会耗时。因此，我们需要异步表服务来保持高写入吞吐量，同时保持索引的最新状态。

03

回顾

在本文中，我们介绍了表服务的概念，深入探讨了压缩和清理的详细过程，并简要提及了索引。欢迎关注 Hudi 公众号 ApacheHudi 获取微信群信息，加入钉钉群：35087066，发送空邮件至 [e-mail] 参与讨论。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

许世彦

Onehouse

开源项目负责人

Onehouse 创始团队成员，开源项目负责人。Apache Hudi PMC 成员。

往期推荐

点个在看你最好看

SPRING HAS ARRIVED