在 CDC 每日流量高峰期，由于 Flink 写入 Paimon 是持续的高吞吐状态，如果后台的 Compaction 速度（由于 CPU、I/O 资源或合并策略等原因）赶不上新文件的写入速度，LSM-Tree 中的 Sorted Runs 数量就会快速积累。

为防止小文件无节制膨胀造成读取性能急剧退化或 OOM，Paimon 的 Writer 线程在达到设定的阈值时，会暂停写入操作。这就是 “Write Stall（写入停顿）”。由于前台写入线程被阻塞，对应的 Flink Sink 算子就会表现为频繁的反压，并向上游传导。

以下将详细介绍如何定位该问题，以及如何通过核心参数调优 Compaction 吞吐来解决此瓶颈。

一、如何定位是否是由于 Compaction 速度慢导致的 Write Stall？

要确认反压和写入停顿是否因后台 Compaction 积压所致，可以通过以下三种手段进行交叉验证：

1. 监控 Paimon 指标 (Metrics)

Paimon 内部提供了丰富的度量指标（可对接 JMX、Prometheus 等），其中以下几个指标能够直接反映 Compaction 的健康状况：

• maxLevel0FileCount (或 L0NumFilesMax)：
  该指标表示当前 Task 中 Level 0 文件的最大数量。如果在流量高峰期这个值持续爬升、居高不下，说明大量的 L0 文件堆积，异步 Compaction 已经无法及时消化。
• queuedCompactionCount：
  该指标反映了当前处于队列中等待执行或正在运行的 Compaction 任务总数。如果该值持续走高，说明合并任务产生了积压。
• compactionBusinessMax / compactionBusinessAvg：
  用来衡量当前 Compaction 线程的繁忙程度（范围 0 到 100）。如果峰值经常维持在 100，表示后台合并线程处于超负荷全运转状态，已经没有多余的算力来加速合并。
• compactionDuration / lastCompactionDuration：
  反映单词 Compaction 消耗的毫秒数。如果合并耗时太长（例如超过了 Flink Checkpoint 的间隔），说明单次合并的数据量过大或 I/O 存在瓶颈。

2. 查询 Paimon 系统表 (System Tables)

通过 Flink SQL 或是其他查询引擎，直接查询 Paimon 的元数据系统表：

• 查询文件分布表 ($files)：
  sql

  SELECT `partition`, bucket, `level`, COUNT(*) as file_count 
  FROM my_table$files 
  GROUP BY `partition`, bucket, `level`;

  如果在高峰期频繁观察到 level = 0 的文件数量已经达到或超过了限制（默认一般在 5 ~ 8 个以上），说明数据未能及时合并到更高的 Level。
• 查询 Snapshot 表 ($snapshots)：
  sql

  SELECT snapshot_id, commit_kind, commit_time 
  FROM my_table$snapshots 
  ORDER BY snapshot_id DESC LIMIT 50;

  观察 commit_kind。如果出现了大量的连续 APPEND 提交，而在很长一段时间内没有出现 COMPACT 类型的提交，则代表 Compaction 进程存在停滞。

3. 分析 Flink 运行日志与线程栈 (Thread Dump)

• 搜索日志关键信息：
  在 TaskManager 的日志中搜索诸如 Write Stall、pause writing 或触发了 num-sorted-run.stop-trigger 相关的日志。
• 分析线程堆栈：
  在 Flink Web UI 对出现反压的 Sink 算子进行 Thread Dump。如果发现大量的 Writer 线程处于 WAITING 或 BLOCKED 状态，并且调用栈指向 Paimon 的 AbstractFileStoreWrite 中的等待后台 Compaction 完成的逻辑（例如等待获取锁或条件变量），这就证实了前台写入已被 Write Stall 阻塞。

二、核心调优参数：如何提高 Compaction 的吞吐？

定位到瓶颈后，可通过调整 Paimon 的配置参数来缓解或彻底解决这一问题。调优通常可以从以下几个维度展开：

维度一：实现完全异步的 Compaction（最直接的缓解手段）

默认情况下，Compaction 虽然在单独的线程运行，但是当 Sorted Runs 超过限制时仍会阻塞写入。通过以下配置可以将其转为完全异步模式，避免阻塞写入线程：

• num-sorted-run.stop-trigger
  • 默认值：num-sorted-run.compaction-trigger + 3（通常为 8 左右）
  • 调优建议：在高峰期可以将其设置为一个极大的值（如 2147483647）。这样设置后，即使后台小文件堆积，也绝对不会强制停顿前台的写入。它能保证流量高峰期的写入高吞吐，待高峰期过去后，后台再慢慢合并。
• sort-spill-threshold
  • 默认值：无 (None)
  • 调优建议：如果调大了 stop-trigger，在进行 Compaction 时可能需要同时读取并合并非常多的 Sorted Runs，极易导致 JVM 堆内存耗尽发生 OOM。配置该参数（建议设置为 10 左右），当合并的文件读取器数量超过此值时，会将部分排序数据溢写到磁盘，从而保证内存安全。
• changelog-producer.lookup-wait
  • 默认值：true
  • 调优建议：如果使用了 changelog-producer = lookup，为了生成 changelog 往往需要在 Checkpoint 阶段等待 Lookup 或者是对应的 Compaction 完成，导致 Checkpoint 耗时长甚至超时。将其设置为 false，允许异步 Lookup，可以大幅解耦 Checkpoint 与合并流程。

维度二：架构解耦 —— 使用旁路专用 Compaction 作业（最推荐的生产方案）

在超大吞吐的 CDC 场景下，让 Flink 的 Writer 算子既负责写入又负责 Compaction，极易互相争抢 CPU 和磁盘 I/O 资源。最佳实践是将两者进行物理隔离：

1. 在写入作业中禁用自动 Compaction：
   在 Flink 写入任务中设置以下参数，使作业只写数据，不作合并：
   sql

   'write-only' = 'true'

2. 提交独立的 Compaction 任务：
   利用 Paimon 提供的 Flink action，在集群中单独起一个 Flink 作业专门负责该表的 Compaction：
   bash

   <FLINK_HOME>/bin/flink run \
     /path/to/paimon-flink-action.jar \
     compact \
     --warehouse <warehouse-path> \
     --database <db-name> \
     --table <table-name>

   优势：由于写入和合并跑在不同的 JVM 甚至不同的机器节点上，写入作业的资源（如 TaskManager 内存与 CPU）可以百分之百服务于写入，从根本上杜绝了因合并争抢资源导致的 Write Stall。

维度三：减少小文件的产生（从源头上减轻合并压力）

如果每次刷写（Flush）产生的数据量太小，会导致 Level 0 充斥着海量极小的文件，成倍加重后台 Compaction 的负担。

• write-buffer-size
  • 默认值：256 mb
  • 调优建议：在内存富余的情况下，可以适当增大该缓冲区（如设置到 512 mb 或更高），并配合开启 write-buffer-spillable = true。更大的缓冲区能积攒更多的数据再一次性溢写，从而减少 Level 0 的文件总数。
• sink.parallelism（Paimon 写入算子并行度）
  • 调优建议：如果 Bucket 数量较大，而写入并行度（Sink 并行度）设置得过小，可能导致单个 TaskManager 内需要同时处理过多的 Bucket，内存被稀释，每个 Bucket 只能分到极小的 Buffer。合理的做法是：让 sink.parallelism 尽量接近甚至等于你的 Table Bucket 总数，使每个并发能够分得充足的写入内存。

维度四：微调 LSM-Tree 的合并机制参数

针对采用 Universal Compaction 的主键表，可以通过调整合并敏感度参数，避免高峰期频繁地进行大范围的文件重写：

• compaction.max-size-amplification-percent
  • 默认值：200
  • 调优建议：该参数控制 LSM-Tree 的空间放大比例。在高峰期，如果不想频繁地因为空间放大触发 Full Compaction（全量重写非常消耗 CPU 和磁盘 I/O），可以适当调大该值（如 300 或 400），用临时的空间冗余换取更高的写入性能。
• compaction.size-ratio
  • 默认值：1
  • 调优建议：该值定义了合并排序运行大小时的百分比灵活性。如果候选 Sorted Runs 之间的数据大小差异较大，可以适当调整此值以微调合并的精细度，减少高峰期单次合并涉及的文件范围。