本文在绿泡泡“狗哥琐话”首发于2025.9.26 <-关注不走丢。
大家好，这里是狗哥。前阵子辅导的同学问了我一个Paimon相关的配置问题啊。
这个配置呢，的确能够解决小文件带来的反压问题。但是数据湖这种东西呢，你这样做肯定是有trade off的。接下来我们就来详细看一下这些配置的背后含义。
解析三个参数
'num-sorted-run.stop-trigger' = '2147483647'
这个配置决定了在执行写入或检查点准备时是否需要等待正在进行的compaction完成——如果当前sorted run的数量大于配置数，就要暂停写入，然后等待最新的compaction完成。
那这个时候就有小伙伴要问了。sorted run是啥？
Sorted Runs 是 LSM Tree（Log-Structured Merge-Tree）结构中的一个重要概念，用于组织和管理存储在磁盘上的数据文件。Sorted Run 是一个包含若干主键有序且无重叠的文件集合。
这些文件中的记录是按主键有序排列的。
- 每个 Sorted Run 包含一个或多个 DataFile。
- 同一个 Sorted Run 中的所有文件的主键范围不会重叠。
- 不同 Sorted Run 之间可能存在主键范围的重叠。
Paimon里的LSM 使用多级结构（Level-based）来组织 Sorted Run：
- Level 0：直接写入的新文件，未排序或与其他 Level 0 文件有主键重叠
- Level 1~N：每一层只包含一个 Sorted Run，每层大小逐渐增加
Compaction 策略会将低层级的多个 Sorted Run 合并到更高级别，形成更大的有序文件。
LSM Tree:
└── Level 0: [file1, file2] ← 两个 Sorted Run（可能有重叠）
└── file1: key range [a, c]
└── file2: key range [b, d]
└── Level 1: [file3] ← 一个 Sorted Run（无重叠）
└── file3: key range [e, g]
└── Level 2: [file4] ← 一个 Sorted Run（无重叠）
└── file4: key range [h, j]
'sort-spill-threshold' = '10'
这个参数用于控制触发是否“溢写（Spill）”操作的阈值。它的作用是防止内存使用过多，避免因合并太多输入流（Readers）而导致 OOM（Out Of Memory）异常。
- 当前 Reader 数量超过 spillThreshold 时：启用 “Spill” 操作，将部分数据从内存排序转为磁盘排序。防止内存占用过高，提升稳定性。
- 当前 Reader 数量未超过 spillThreshold 时：使用纯内存进行归并排序（merge sort），性能更高。
那啥是Spill呢？当有大量输入源（如多个 SST 文件）需要合并排序时，每个源都会占用一定的内存缓冲区。为了避免内存爆炸，Paimon 会将一部分数据写入磁盘临时文件（Spill File），从而降低内存压力。
'changelog-producer.lookup-wait' = 'false'
这个参数用于控制在 使用 Lookup Changelog Producer 的场景下，是否让写入操作等待 Compaction（压缩）完成。
在Lookup CDC模式下，会通过 Lookup 表来维护最新的数据状态。由于 Lookup 表的构建需要一定的处理时间，这个选项决定了写入端如何应对这种延迟。
如果wait的话。数据完整可见了，Compaction 会强制让 L0 的所有 DataFile 参与 Compaction， 那Compaction 完成后，CommitKind为 Compact 的 Snapshot 不存在 L0 的 DataFile了，所以这种场景可以用时间旅行读取历史 Snapshot 的完整数据。但会CP就要慢一点了。
反之就是数据完整性不强嘛。但是CP很快。
结论
那了解完这3个参数背后的含义以后呢，我相信大家对这组配置有了更深的了解。提升写入性能，本质上是交换读性能带来的。
那对于网上的一些参数呢，我建议在切实了解它们的实际含义与作用以后，再结合自己的场景来使用，不然很容易掉坑里。这也是高阶工程师和普通工程师的一个常见差距。
那关于Paimon更多的姿势，大家可以来看看我的星球（入口在绿泡泡“狗哥琐话”）。Paimon源码剖析系列文章已经告一段落了，正是学习好时候。最后关注不走丢，我们下期见。
