一、引言Hudi 的 Merge on ReadMOR表通过将增量数据写入 Delta Log 文件来实现高吞吐写入但随着 Log 文件累积读取性能会逐步退化。Compaction 作为 Hudi 的核心 Table Service负责将 Delta Log 与 Base File 合并是平衡读写性能的关键机制。二、Compaction 机制原理Compaction 的本质就是将读时合并的开销前置为写时合并的后台任务在读写性能之间取得可控的平衡点。Hudi Compaction 采用计划与执行分离的两阶段模型这是其设计的核心特征设计优势解耦Schedule 可以由 Writer 在每次 commit 后触发Execute 可以由独立进程如独立 Spark 作业异步执行容错若 Execute 失败Plan 仍存在于 Timeline 上下次可直接重试执行无需重新调度灵活性支持 inline同步、async异步同进程、独立作业 三种执行模式Hudi 提供多种内置策略hoodie.compaction.strategy决定哪些 File Group 优先被 Compact策略说明适用场景LogFileSizeBasedCompactionStrategy按 Log 文件总大小降序排列优先 compact Log 最大的 File Group默认策略适合通用场景BoundedIOCompactionStrategy在 LogFileSize 策略基础上限制单次 Compaction 的总 IO 量IO 资源受限的环境UnBoundedIOCompactionStrategy不做 IO 限制compact 所有待合并的 File Group资源充足时快速追赶DayBasedCompactionStrategy按分区日期排序优先 compact 最新分区时间分区表关注最新数据读取性能Compaction核心触发参数# 每隔多少次 commit 触发一次 compaction schedule hoodie.compact.inline.max.delta.commits5 # 异步模式下的触发条件Flink 场景 compaction.delta_commits5 compaction.delta_seconds3600单个 File Group 的 Compaction 执行过程合并过程中读取 Base File 中的所有记录按顺序 replay 每个 Log Block 中的操作insert/update/delete使用 RecordMerger1.x或 HoodieRecordPayload0.x进行记录级合并输出最终结果到新的 Base File三、Hudi 1.x vs 0.xCompaction 的架构演进维度Hudi 0.xHudi 1.x影响记录合并模型HoodieRecordPayloadRecordMerger 接口合并逻辑更灵活、可插拔索引机制文件级 BloomFilter / HBase 索引Record-Level Index默认Compaction 时定位记录更高效并发控制OCC (Optimistic Concurrency Control)Non-Blocking Concurrency Control (NBCC)Compaction 不阻塞 WriterLog Compaction0.14 引入增强与完善减少 Snapshot Query 合并开销Table Services 调度与 Writer 耦合较紧统一 Table Service Manager调度更灵活、可观测存储抽象依赖 Hadoop FileSystem新 HoodieStorage 抽象Compaction 可运行于更多存储后端文件格式固定 Parquet Avro Log可扩展的 Reader/Writer 抽象为未来格式扩展做准备四、最佳实践Compaction 执行模式选择推荐方案生产环境首选独立的 Compaction 作业资源隔离、可独立扩缩容、失败不影响写入链路开发/测试环境Inline Compaction简单、无需额外作业Flink 实时场景异步 Compaction同一 Flink Job 内或独立 Compaction Job关键参数调优# 调度频率 # 每 N 次 delta commit 触发一次 Compaction Schedule hoodie.compact.inline.max.delta.commits5 # 建议值根据写入频率调整过于频繁会增加小文件合并开销 # 过于稀疏则 Log 堆积影响读性能 # IO 控制 # 使用 BoundedIO 策略时单次 Compaction 最大处理数据量(MB) hoodie.compaction.target.io512000 # 建议值根据集群可用资源设定避免 Compaction 占用过多 IO # 并行度 # Compaction 并行度Spark 场景 hoodie.compaction.parallelism200 # 建议值≈ 待 compact 的 File Group 数量避免过小导致长尾 # Compaction 策略 hoodie.compaction.strategyorg.apache.hudi.table.action.compact.strategy.LogFileSizeBasedCompactionStrategy # 异步 Compaction (Flink) compaction.async.enabledtrue compaction.delta_commits5 compaction.max_memory512 # Flink compaction task memory (MB)Compaction排查思路Compaction 积压pending 数持续增长 ├── 原因1Compaction 执行资源不足 → 增加并行度/独立作业资源 ├── 原因2写入速率 Compaction 速率 → 降低触发频率 or 增加资源 ├── 原因3大 File Group 导致单次 Compaction 耗时过长 → 使用 BoundedIO 策略 └── 原因4Compaction 失败重试 → 检查日志排查 OOM/数据问题
Hudi技术内幕：Compaction原理与实践
发布时间：2026/7/22 5:18:48
一、引言Hudi 的 Merge on ReadMOR表通过将增量数据写入 Delta Log 文件来实现高吞吐写入但随着 Log 文件累积读取性能会逐步退化。Compaction 作为 Hudi 的核心 Table Service负责将 Delta Log 与 Base File 合并是平衡读写性能的关键机制。二、Compaction 机制原理Compaction 的本质就是将读时合并的开销前置为写时合并的后台任务在读写性能之间取得可控的平衡点。Hudi Compaction 采用计划与执行分离的两阶段模型这是其设计的核心特征设计优势解耦Schedule 可以由 Writer 在每次 commit 后触发Execute 可以由独立进程如独立 Spark 作业异步执行容错若 Execute 失败Plan 仍存在于 Timeline 上下次可直接重试执行无需重新调度灵活性支持 inline同步、async异步同进程、独立作业 三种执行模式Hudi 提供多种内置策略hoodie.compaction.strategy决定哪些 File Group 优先被 Compact策略说明适用场景LogFileSizeBasedCompactionStrategy按 Log 文件总大小降序排列优先 compact Log 最大的 File Group默认策略适合通用场景BoundedIOCompactionStrategy在 LogFileSize 策略基础上限制单次 Compaction 的总 IO 量IO 资源受限的环境UnBoundedIOCompactionStrategy不做 IO 限制compact 所有待合并的 File Group资源充足时快速追赶DayBasedCompactionStrategy按分区日期排序优先 compact 最新分区时间分区表关注最新数据读取性能Compaction核心触发参数# 每隔多少次 commit 触发一次 compaction schedule hoodie.compact.inline.max.delta.commits5 # 异步模式下的触发条件Flink 场景 compaction.delta_commits5 compaction.delta_seconds3600单个 File Group 的 Compaction 执行过程合并过程中读取 Base File 中的所有记录按顺序 replay 每个 Log Block 中的操作insert/update/delete使用 RecordMerger1.x或 HoodieRecordPayload0.x进行记录级合并输出最终结果到新的 Base File三、Hudi 1.x vs 0.xCompaction 的架构演进维度Hudi 0.xHudi 1.x影响记录合并模型HoodieRecordPayloadRecordMerger 接口合并逻辑更灵活、可插拔索引机制文件级 BloomFilter / HBase 索引Record-Level Index默认Compaction 时定位记录更高效并发控制OCC (Optimistic Concurrency Control)Non-Blocking Concurrency Control (NBCC)Compaction 不阻塞 WriterLog Compaction0.14 引入增强与完善减少 Snapshot Query 合并开销Table Services 调度与 Writer 耦合较紧统一 Table Service Manager调度更灵活、可观测存储抽象依赖 Hadoop FileSystem新 HoodieStorage 抽象Compaction 可运行于更多存储后端文件格式固定 Parquet Avro Log可扩展的 Reader/Writer 抽象为未来格式扩展做准备四、最佳实践Compaction 执行模式选择推荐方案生产环境首选独立的 Compaction 作业资源隔离、可独立扩缩容、失败不影响写入链路开发/测试环境Inline Compaction简单、无需额外作业Flink 实时场景异步 Compaction同一 Flink Job 内或独立 Compaction Job关键参数调优# 调度频率 # 每 N 次 delta commit 触发一次 Compaction Schedule hoodie.compact.inline.max.delta.commits5 # 建议值根据写入频率调整过于频繁会增加小文件合并开销 # 过于稀疏则 Log 堆积影响读性能 # IO 控制 # 使用 BoundedIO 策略时单次 Compaction 最大处理数据量(MB) hoodie.compaction.target.io512000 # 建议值根据集群可用资源设定避免 Compaction 占用过多 IO # 并行度 # Compaction 并行度Spark 场景 hoodie.compaction.parallelism200 # 建议值≈ 待 compact 的 File Group 数量避免过小导致长尾 # Compaction 策略 hoodie.compaction.strategyorg.apache.hudi.table.action.compact.strategy.LogFileSizeBasedCompactionStrategy # 异步 Compaction (Flink) compaction.async.enabledtrue compaction.delta_commits5 compaction.max_memory512 # Flink compaction task memory (MB)Compaction排查思路Compaction 积压pending 数持续增长 ├── 原因1Compaction 执行资源不足 → 增加并行度/独立作业资源 ├── 原因2写入速率 Compaction 速率 → 降低触发频率 or 增加资源 ├── 原因3大 File Group 导致单次 Compaction 耗时过长 → 使用 BoundedIO 策略 └── 原因4Compaction 失败重试 → 检查日志排查 OOM/数据问题
与LoRA实战指南)
