一文彻底理解Apache Hudi的清理服务

欢迎关注微信公众号：ApacheHudi

Apache Hudi提供了MVCC并发模型，保证写入端和读取端之间快照级别隔离。在本篇博客中我们将介绍如何配置来管理多个文件版本，此外还将讨论用户可使用的清理机制，以了解如何维护所需数量的旧文件版本，以使长时间运行的读取端不会失败。

1. 回收空间以控制存储成本

Hudi 提供不同的表管理服务来管理数据湖上表的数据，其中一项服务称为Cleaner（清理服务）。 随着用户向表中写入更多数据，对于每次更新，Hudi会生成一个新版本的数据文件用于保存更新后的记录(COPY_ON_WRITE) 或将这些增量更新写入日志文件以避免重写更新版本的数据文件 (MERGE_ON_READ)。 在这种情况下，根据更新频率，文件版本数可能会无限增长，但如果不需要保留无限的历史记录，则必须有一个流程（服务）来回收旧版本的数据，这就是 Hudi 的清理服务。

2. 问题描述

在数据湖架构中，读取端和写入端同时访问同一张表是非常常见的场景。由于 Hudi 清理服务会定期回收较旧的文件版本，因此可能会出现长时间运行的查询访问到被清理服务回收的文件版本的情况，因此需要使用正确的配置来确保查询不会失败。

3. 深入了解 Hudi清理服务

针对上述场景，我们先了解一下 Hudi 提供的不同清理策略以及需要配置的相应属性，Hudi提供了异步或同步清理两种方式。在详细介绍之前我们先解释一些基本概念：

• Hudi 基础文件（HoodieBaseFile）：由压缩后的最终数据组成的列式文件，基本文件的名称遵循以下命名约定：<fileId>_<writeToken>_<instantTime>.parquet。在此文件的后续写入中文件 ID 保持不变，并且提交时间会更新以显示最新版本。这也意味着记录的任何特定版本，给定其分区路径，都可以使用文件 ID 和 instantTime进行唯一定位。
• 文件切片(FileSlice)：在 MERGE_ON_READ 表类型的情况下，文件切片由基本文件和由多个增量日志文件组成。
• Hudi 文件组(FileGroup)：Hudi 中的任何文件组都由分区路径和文件ID 唯一标识，该组中的文件作为其名称的一部分。文件组由特定分区路径中的所有文件片组成。此外任何分区路径都可以有多个文件组。

4. 清理服务

Hudi 清