📚 课程目录第4章 Compaction积压定义

Compaction 积压定义：什么是积压、积压的度量指标

在 Hudi 表运维中，“Compaction 积压”是一个高频出现但又容易被模糊理解的概念。很多工程师在遇到写入延迟升高、查询返回快照过旧、或 MOR 表文件数量激增时，第一反应是“是不是 Compaction 出问题了”，但若要追问一句“积压到底指什么？积压了多少？积压了多久？”，往往难以给出精确回答。本节将围绕积压的定义与度量指标展开，帮助你在诊断问题前先建立一套可量化、可对比的“标尺”。

4.1 什么是 Compaction 积压

Compaction 积压，本质上是指 已经产生但尚未被 Compaction 服务处理的 delta 文件（日志文件）及其对应的数据变更量。在 Hudi 的 MOR（Merge-On-Read）表中，每次写入都会先落盘为 avro 格式的 delta 文件，而读取时需要将这些 delta 文件与 base 文件（列式文件，如 parquet）动态合并。Compaction 服务的职责，就是将这些 delta 文件与 base 文件合并成新的 base 文件，从而减少读取时的合并开销。

当 Compaction 的生成速度（即新写入产生的 delta 文件速度）持续大于 Compaction 的执行速度时，未处理的 delta 文件就会像队列一样不断累积，形成积压。需要特别强调的是：积压不是“有没有”的问题，而是“多少”和“多久”的问题。任何 MOR 表在任意时刻都可能存在少量 pending 的 compaction 计划，这是正常状态；只有当积压量超过系统可承受阈值，或积压时间超过业务可接受延迟时，才构成需要干预的“故障”。

关键区分：“Compaction 积压”与“Compaction 失败”是两个不同概念。失败是指某个 compaction 计划执行出错、被反复重试或最终放弃；而积压是指大量 compaction 计划处于 pending（排队中）状态，即使每个计划最终都能成功，但整体处理速度跟不上生产速度，同样会造成积压。诊断时需先分清是“执行质量”问题还是“吞吐能力”问题。

4.2 积压的度量指标：从“数量”到“延迟”

要准确描述积压，不能只凭感觉说“积压挺多的”，而应使用一组可量化的指标。实践中，最核心的度量指标分为两类：存量指标（描述当前积压的规模）和 速率指标（描述积压的变化趋势）。以下表格列出了最常用的度量维度：

指标类别	指标名称	含义与计算方式	典型告警阈值参考
存量指标	Pending Compactions 数量	当前处于 pending 状态的 compaction 计划总数（包含 queued 和 in-flight）	持续 > 50 或 > 分区数×2
	Pending Delta 文件数	所有 pending compaction 计划涉及的 delta 文件总个数	持续 > 1000
	Pending 数据量（MB/GB）	所有 pending compaction 计划涉及的日志文件总字节数	持续 > 表总数据量的 10%
延迟指标	Compaction Lag（延迟）	最早一个 pending compaction 计划生成时刻到当前时间的差值	> 30 分钟（近实时场景）或 > 2 小时（批场景）
延迟指标	Delta 文件最大年龄	当前未合并的 delta 文件中，最早写入文件的时间戳到当前时间的差值	> 1 小时
速率指标	Compaction 生成速率	单位时间内新产生的 compaction 计划数（通常按小时统计）	用于计算趋势，不单独设阈值
速率指标	Compaction 完成速率	单位时间内成功完成的 compaction 计划数	若持续低于生成速率，则积压必然增长

在上述指标中，“Pending Compactions 数量”是最直观的入口指标，它回答“积压了多少个任务”；而 “Compaction Lag”则回答“积压了多久”，它更能反映业务实际感受到的延迟。例如：pending 数量只有 10 个，但最早一个计划已等待 3 小时，说明 Compaction 服务可能已长时间停止调度；反之，pending 数量有 200 个，但最早计划仅等待 5 分钟，说明系统正在快速消化积压，只是瞬时写入洪峰导致队列变长。

4.3 积压的形成过程与观测方法

理解积压的形成过程，有助于选择合适的观测点。下图展示了 MOR 表中从写入到 Compaction 完成的完整数据流，以及积压产生的关键位置：

上图展示了积压监控的核心逻辑：写入端持续产生 delta 文件进入 Delta 文件池，Compaction 服务从池中取出文件执行合并，生成新的 base 文件。当 Delta 文件池的“流入速度”大于“流出速度”时，池中的文件数量就会增长，表现为 pending 数量上升、lag 增大。监控面板中的四个指标（Pending 数量、Compaction Lag、Delta 文件最大年龄、速率对比）共同构成了积压的完整画像。

4.4 实际案例：一个典型的积压形成过程

假设某电商平台使用 Hudi MOR 表存储订单实时数据，分区策略为小时分区。业务高峰期（如 10:00-11:00）写入量激增，达到平时的 5 倍。以下是该时段内积压的形成与观测记录：

10:00：写入速率突增，每秒产生约 200 个 delta 文件。Compaction 服务按固定间隔（每 5 分钟）调度一次，每次处理约 500 个文件。此时 pending 数量从平时的 20 个迅速攀升至 80 个。
10:15：调度器检测到 pending 数量超过阈值（50），触发“紧急调度”模式，将调度间隔缩短至 2 分钟。但由于执行 Compaction 的 Executor 资源固定，单次处理能力并未提升，完成速率仍约为 400 个/5 分钟。
10:30：pending 数量达到 200 个，最早一个 compaction 计划生成于 10:02，Compaction Lag 已达 28 分钟。此时查询延迟开始显现——部分查询需要合并大量 delta 文件，响应时间从平均 200ms 上升至 1.2s。
11:00：写入高峰结束，但积压并未立即缓解。由于 Compaction 完成速率仍低于高峰期的生成速率，pending 数量维持在 150 个左右，Lag 持续增长至 55 分钟。

通过这个案例可以看到，积压的峰值并不出现在写入高峰的顶点，而是出现在写入速率回落后的一段时间——因为 Compaction 是异步的，它需要时间“消化”高峰期间积累的文件。这也是为什么仅凭“当前写入速率”无法判断积压，必须同时监控 pending 数量和 lag 的原因。

4.5 常见误区与诊断要点

误区一：只关注 pending 数量，忽略 lag。两个表可能都有 100 个 pending compaction，但表 A 的 lag 为 5 分钟（说明系统健康，正在快速消化），表 B 的 lag 为 2 小时（说明 Compaction 服务可能已卡死或资源严重不足）。只看数量会得出完全错误的结论。

误区二：认为 pending 数量为 0 才是正常。实际上，由于 Compaction 是周期调度的，在两次调度之间必然存在少量 pending 计划。只要 pending 数量稳定、lag 保持在合理范围内（如小于调度间隔的 2-3 倍），就属于健康状态。盲目追求“零 pending”可能导致过度频繁调度，反而浪费资源。

  诊断要点总结：
  先看 Compaction Lag：若 lag 持续增长且超过业务可接受延迟，则无论 pending 数量多少，都需要干预。
再看 速率对比：比较近 1 小时生成速率与完成速率。若完成速率 ≥ 生成速率，积压会自然缓解；若持续小于，则需扩容或优化。
最后看 Delta 文件最大年龄：该指标反映最老数据被合并的等待时间，直接关联数据新鲜度（如近实时场景要求 < 15 分钟）。

在实际运维中，建议将上述指标接入监控系统（如 Prometheus + Grafana），并设置分级告警：当 lag 超过 15 分钟时触发 Warning，超过 30 分钟时触发 Critical。同时记录历史趋势，以便在积压发生时快速判断是“突发洪峰”还是“慢性吞吐不足”——前者通常可通过临时扩容解决，后者则需要调整 Compaction 策略或资源配比。

理解积压的定义和度量指标，是后续进行积压诊断与恢复的基础。只有建立了统一的度量口径，团队在讨论“积压是否严重”“恢复是否完成”时才能达成共识，避免凭感觉决策。