播面 正常情况下，Paimon 为什么会产生两个 Snapshot ？
在 Apache Paimon 中，一次 Flink Checkpoint 可能会产生两个快照（Snapshot）。这主要是由于 “新数据追加（Append）”与“异步文件合并（Compaction）”在设计上的解耦与异步化协同机制。
为了保证高吞吐，Paimon 将这两者的提交过程分离开来，具体原因和工作原理如下：
1. 数据的追加写入（产生 Append 类型的快照）
- 写入与刷盘：在 Flink 运行过程中，新流入的数据会先缓存在 Paimon Sink 算子的堆内存中（LSM-Tree 的 MemTable）。当内存满或 Flink 准备进行 Checkpoint 时，Sink 算子会将缓存的数据全部刷写（Flush）到磁盘，生成新的 L0 层数据文件。
- 提交请求：在 Checkpoint 触发前，Sink 会向游的
Committer算子发送带有新文件元数据的提交信息（committable）。 - 快照创建：在 Checkpoint 期间，
Committer优先提交这些新写入的数据，将其转化为一个Append类型的快照（此时新数据正式对外可见）。
2. 异步的文件合并（产生 Compact 类型的快照）
- 异步合并：与此同时，Paimon 内部的
CompactManager在后台独立的线程中异步地进行文件合并操作（例如将多个 L0 层的零散小文件合并为 L1 层更有序的大文件）。 - 合并提交：当后台的异步合并任务完成时，它也会产生一个提交信息（包含哪些旧文件被逻辑删除，哪些新合并的文件被加入）并发送给
Committer。 - 快照创建：
Committer同样会在 Checkpoint 期间提交这一合并结果，从而产生一个Compact类型的快照（该快照更新了文件索引，但由于不包含新数据，其数据总量一般保持不变）。
3. 不同场景下的快照生成情况
根据在 Flink 的一个 Checkpoint 间隔内发生的事件，Paimon 会生成不同数量的快照：
| 场景 | 产生的快照数量及类型 | 备注 |
|---|---|---|
| 既有新数据写入，又有异步合并完成 | 2 个快照（1个 Append + 1个 Compact） |
Committer 会顺次提交这两项操作，从而在同一个 Checkpoint 周期内产生两个快照。 |
| 有新数据写入，但没有触发或完成合并 | 1 个快照（仅 Append） |
仅将新写入的数据变为可见。 |
| 没有新数据写入，但异步合并完成 | 1 个快照（仅 Compact） |
比如在数据源暂时无数据、但后台仍在消化合并之前的小文件时发生。 |
| 既无数据写入，也无合并完成 | 0 个快照 | 若在 Checkpoint 间隔内没有任何变更，则不会创建新的快照。 |
总结
这种“双快照”机制是 Paimon 能够实现低延迟写入和高读取性能平衡的关键。通过将追加数据（Append）和文件重组（Compact）作为两个独立的原子事务分别提交，Paimon 避免了让繁重的文件合并操作去阻塞新数据的实时写入，从而保障了流式湖仓的高效运行。