3、Hudi表服务概览：Clustering、Compaction、Clean、Archive、Indexing等服务的功能与触发机制

3.1 为什么需要表服务：从“写路径”到“后台治理”

Apache Hudi 的核心优势之一，是它将传统数据湖中由人工或外部调度器负责的“表维护工作”抽象为一系列内建的表服务（Table Services）。在仅关注写入路径时，Hudi 看起来只是一个带索引的存储格式；但真正让 Hudi 在长时间运行、高频写入、大批量更新场景下保持查询性能与文件稳定性的，正是这些在后台默默运行的服务。

可以把 Hudi 表服务理解为数据库中的“自动维护任务”：如同 PostgreSQL 的 autovacuum、ClickHouse 的 merge 线程，Hudi 通过一组可配置的服务，持续对表文件进行合并、清理、排序、索引同步等操作。理解这些服务的功能边界与触发机制，是进行 Compaction 调优的前提——因为 Compaction 并非孤立存在，它与 Clustering、Clean、Archive 共享文件组视图与时间线（Timeline），彼此之间存在资源竞争与顺序依赖。

3.2 五大表服务功能详解

3.2.1 Compaction（MOR 专属）

功能：Compaction 仅针对 Merge-On-Read（MOR）表。其核心任务是将某个文件组（File Group）中的 BaseFile（.parquet）与其后续追加的 LogFile（.log）进行合并，生成一个新的 BaseFile，并清理已合并的 LogFile。合并过程中需要根据记录键（Record Key）解决冲突——通常采用“后写覆盖先写”的策略，保证最终状态与写入顺序一致。

触发机制：Compaction 可通过以下方式触发：

• 内联（Inline）：在写入任务提交前同步执行，通过 hoodie.compact.inline=true 开启。
• 异步（Async）：写入完成后由独立进程或 Spark 作业触发，通过 hoodie.compact.async=true 开启。
• 调度条件：当未 compaction 的 delta 提交数达到 hoodie.compact.inline.max.delta.commits（默认 5）时触发。

3.2.2 Clustering（COW 与 MOR 通用）

功能：Clustering 解决的是“小文件问题”与“数据布局优化”。它将多个小文件组（或文件片）合并为更大的文件组，并可按指定列进行排序（如按时间戳或用户 ID），从而提升查询的谓词下推效率与文件扫描性能。Clustering 会重写数据，因此会产生新的文件版本。

触发机制：

• 通过 RUN CLUSTERING 命令手动触发（Spark SQL / 命令行）。
• 异步调度：当文件大小低于 hoodie.clustering.small.file.limit（默认 300MB）的文件数量达到阈值时自动触发。
• 支持计划（plan）与执行（execute）分离，便于先审查计划再执行。

3.2.3 Clean（所有表类型）

功能：Clean 负责删除不再需要的旧版本文件。Hudi 采用多版本并发控制（MVCC），每次写入都会生成新版本文件，但查询只需保留当前快照及最近 N 个版本。Clean 会根据保留策略删除过期文件，释放存储空间。

触发机制：

• 保留策略：hoodie.cleaner.commits.retained（默认 10）——保留最近 10 次提交对应的文件版本。
• 触发时机：每次写入完成后自动检查，若超出保留版本数则触发清理；也可通过 hoodie.clean.async=true 异步执行。

3.2.4 Archive（所有表类型）

功能：Archive 将 Timeline 中过旧的 Instant（操作记录）从活跃的 .hoodie 目录移动到 .hoodie/archive 目录下的归档文件中。Timeline 无限增长会降低元数据操作性能，Archive 保证 Timeline 保持精简。

触发机制：当活跃 Instant 数量超过 hoodie.archive.max.instants（默认 200）且小于 hoodie.archive.min.instants（默认 150）时触发。Archive 通常与 Clean 协同执行。

3.2.5 Indexing（索引服务）

功能：Indexing 维护记录键（Record Key）到文件组 ID（File Group ID）的映射关系。Hudi 支持多种索引实现：

触发机制：Indexing 在每次写入（UPSERT）时自动执行，用于判断记录是更新还是插入。此外，当启用 Metadata Table 时，索引的同步更新会作为写入事务的一部分自动完成。

3.3 服务间的协作关系与调度顺序

表服务并非独立运行，它们共享 Timeline 并存在隐式的顺序依赖。一个典型的写入周期中，服务执行顺序如下：

1. 写入提交：产生新的 commit/delta commit，更新 Timeline。
2. Clean 检查：若版本数超限，执行清理，删除旧文件。
3. Archive 检查：若 Instant 数超限，归档旧记录。
4. Compaction/Clustering 调度：若满足触发条件，生成计划并执行。

3.4 案例：一个典型 MOR 表的服务运行周期

假设有一个 MOR 表，配置了异步 Compaction（每 5 次提交触发一次）和自动 Clean（保留 10 个版本）。观察其运行过程：

# 写入端配置
hoodie.compact.async=true
hoodie.compact.inline.max.delta.commits=5
hoodie.cleaner.commits.retained=10
hoodie.archive.max.instants=200

# 时间线观察（.hoodie 目录）
# 第 1~4 次提交：仅追加 LogFile，无 Compaction
# 第 5 次提交后：触发 Compaction，生成新 BaseFile
# 第 11 次提交后：Clean 删除第 1 次提交的旧版本文件
# 第 200 次提交后：Archive 将最早的 Instant 归档

通过观察 .hoodie 目录下的文件变化，可以清晰看到各服务的执行痕迹：

• *.commit / *.deltacommit：记录写入操作。
• *compaction*：记录 Compaction 计划与执行状态。
• *clean*：记录清理操作。
• archive/：存放已归档的旧 Instant。

3.5 常见误区与调优复盘