课程导入：学习目标、课程结构、Hudi Compaction基本概念与重要性
1.1 为什么需要关注 Compaction 积压
在数据湖技术体系中，Apache Hudi 凭借其 ACID 事务、时间旅行与增量消费能力，成为湖仓一体架构的核心组件。然而，生产环境中 Hudi 表最常见的“隐形杀手”并非写入失败，而是 Compaction 积压（Compaction Backlog）。当 MOR（Merge-On-Read）表的 Compaction 调度速度跟不上文件组（File Group）的增长速度时，Base 文件与 Log 文件的比例持续失衡，查询延迟逐步攀升，最终可能导致整个数据管道阻塞。
本课程面向数据平台工程师、大数据运维人员与 Hudi 深度使用者，系统讲解 Compaction 积压的诊断方法、根因分析与恢复策略。你将学会如何从监控指标中识别积压征兆，如何定位瓶颈是调度策略、资源不足还是写入倾斜，以及如何在不停服的情况下安全清理积压。
1.2 课程学习目标
完成本课程后，你将能够：
- 理解核心机制：准确描述 Hudi Compaction 的触发条件、调度流程与执行原理，区分同步与异步 Compaction 的适用场景。
- 识别积压信号：通过 Hudi 指标（如
numDeltaCommits、compaction.score）、Spark UI 与文件系统元数据，快速判断是否存在 Compaction 积压及其严重程度。 - 定位根因：从写入频率、文件大小策略、集群资源、调度配置四个维度，系统排查导致积压的深层原因。
- 实施恢复方案：掌握手动触发 Compaction、调整并发度、清理小文件、临时关闭写入等恢复手段，并理解每种方案的适用边界与风险。
- 建立预防体系：设计合理的 Compaction 监控告警与定期巡检机制，避免积压问题反复发生。
1.3 Hudi Compaction 基本概念
在 Hudi 的 MOR 表中，新到达的数据首先写入 Avro Log 文件（包含增量记录），而历史数据存储在列式 Parquet Base 文件中。这种设计显著降低了写入延迟（无需重写整个文件组），但代价是读取时需要合并 Base 与 Log 文件，导致查询性能下降。
Compaction（压缩）正是解决这一问题的后台操作：它将同一个文件组（File Group）下的 Base 文件与多个 Log 文件合并，生成一个新的、更紧凑的 Base 文件，并清理旧的 Log 文件。合并后的文件组只保留一个 Base 文件，查询时无需再合并 Log，从而恢复读取性能。
Compaction 操作包含两个阶段：
- 调度（Schedule）：根据表的分区布局、Log 文件大小与数量，决定哪些文件组需要压缩，并生成 Compaction 计划（Plan）。
- 执行（Execute）：按照计划读取 Log 文件与 Base 文件，执行合并并写入新的 Base 文件，最后更新表的元数据。
当调度速度远快于执行速度，或执行任务因资源不足而长时间排队时，未完成的 Compaction 计划不断累积，就形成了积压。积压的直接后果是：
- 查询延迟持续上升，尤其是点查与增量查询。
- Log 文件占用大量存储空间，且小文件数量激增。
- 后续 Compaction 任务需要合并更多数据，执行时间进一步拉长，形成恶性循环。
1.4 课程结构总览
本课程共分为五个模块，从基础概念到实战恢复，层层递进：
| 模块 | 章节范围 | 核心内容 |
|---|---|---|
| 基础与原理 | 第 1-5 章 | Compaction 机制、调度策略、积压形成模型 |
| 监控与诊断 | 第 6-12 章 | 关键指标、日志分析、诊断工具与脚本 |
| 根因分析 | 第 13-18 章 | 写入模式、资源瓶颈、配置缺陷、小文件问题 |
| 恢复与优化 | 第 19-25 章 | 手动触发、并发调优、清理策略、参数调整 |
| 实战与预防 | 第 26-30 章 | 真实案例复盘、监控告警体系、长期治理方案 |
每个章节均配有真实生产场景的案例或模拟数据，帮助你建立从“看到指标异常”到“完成恢复操作”的完整闭环思维。
1.5 Compaction 积压的典型场景
为了让你对后续内容有直观感知，这里列举两个最常见的积压触发场景：
场景一：突发写入高峰。某电商平台在大促期间，订单表每分钟写入量激增至平时的 20 倍。默认的异步 Compaction 调度每 5 分钟触发一次，但执行 Compaction 的 Spark 作业资源池较小，单次执行需要 15 分钟。短短 1 小时内，未完成的 Compaction 计划就从 3 个累积到 20 个以上。
场景二：小文件策略不当。某日志分析表使用了过小的 targetFileSize（如 64MB），导致每个分区产生大量文件组。Compaction 调度器需要处理的文件组数量远超预期，而每个文件组的合并操作又需要独立的 Task 执行，最终造成任务队列拥堵。
这两个场景分别代表了资源型积压与结构型积压，它们的诊断路径与恢复手段截然不同，后续章节将分别深入剖析。
1.6 Compaction 积压的影响链路
理解积压如何影响整个数据管道，有助于你评估问题的优先级。下图展示了 Compaction 积压从产生到影响业务查询的完整链路：
从上图可以看出，积压的诊断切入点主要有两个：一是调度器生成的计划数量与执行完成数量的差值，二是执行队列中任务的排队时长。后续章节将围绕这两个切入点，展开具体的监控命令与诊断方法。
1.7 常见误区与学习建议
logFileMaxSize 限制时，写入端也会开始阻塞。
误区二：盲目调大 Compaction 并发度。并发度过高可能导致小文件合并时产生大量随机 IO，反而拖慢整体进度。合理的并发度需要结合文件组数量与集群核数综合计算。
误区三：只在积压严重时才关注 Compaction。最佳实践是建立日常监控，将积压消除在萌芽阶段。
建议你在学习本课程时，准备一个测试用的 Hudi MOR 表，并模拟不同写入频率与资源限制，亲身体验积压的形成过程。理论与实践结合，才能真正掌握积压诊断与恢复的精髓。