Paimon 流式写入调优：changelog-producer 取舍与配置

先给结论：主键表要向下游交付完整 changelog 时，默认的 none 和省资源的 input 都不够用；链路新鲜度优先选 lookup，成本优先、能接受分钟级延迟选 full-compaction。三种 changelog-producer 的差别可以归结为一句话：谁、在什么时候，替你把合并后的结果算出来——input 不算，lookup 写入时就算，full-compaction 攒到全量 compaction 再算。这个选择直接决定下游看到的 changelog 是否完整，以及写入和 compaction 的资源开销。

changelog-producer 在解决什么问题

Paimon 主键表的写入不是覆盖而是合并：数据先进 LSM 结构，由 compaction 按 merge-engine（deduplicate、partial-update、aggregation 等）把同一个 key 的多条记录合成结果。流式下游如果直接消费写入端的原始记录，看到的只是"输入"，不是"结果"——partial-update 表里一行的最终形态可能是几十条输入拼出来的，聚合表的一个结果值背后可能有一批输入被合并掉。changelog-producer 就是决定"完整结果变更流"如何生成的开关，它作用于主键表，四个取值：

• none（默认）：不生成独立 changelog，下游只能看到合并后的净变更，拿不到更新前镜像（update_before）。
• input：直接把输入流当 changelog 产出，几乎不加开销。
• lookup：写入时通过查已合并数据生成完整 changelog。
• full-compaction：只在全量 compaction 完成时产出一轮完整 changelog。

官方语义可对照 Paimon changelog-producer 文档。

三种模式的机制与取舍

input：最低开销，代价是 changelog 可能缺斤短两

input 模式把上游写进来的记录原样标注为 changelog 产出，不额外读状态、不额外触发 compaction，吞吐几乎不受影响。问题出在合并语义上：deduplicate 表连续两次更新同一 key，下游会看到两条 +I，但合并后其实只剩一条；partial-update 和 aggregation 表更糟，下游把半成品行当完整行使用就是脏数据源头。另外它产出的变更顺序不保证与合并结果一致，依赖 update_before 做维表同步或双写的下游会直接算错。

lookup：新鲜度优先，代价是读放大

lookup 模式在写入路径上对同 key 的已有数据做一次查（lookup），把合并后的结果补全成完整的 changelog，下游能拿到正确的 -U/+U/+I 流，且随 checkpoint 持续产出，延迟通常在秒到分钟级。代价是每条输入都要对状态和数据文件做查，写入吞吐越高，查的开销越大，状态后端与本地盘 IO 会成为瓶颈。选择它的信号：下游要实时维表同步、双写，或按 changelog 驱动下游索引与宽表更新，且 SLA 要求在分钟级以内。

full-compaction：最完整，延迟跟着 compaction 周期走

full-compaction 模式只在全量 compaction 发生时生成 changelog，此时所有数据已合并完毕，changelog 天然完整、回放语义最干净且天然含完整前后镜像。官方语义上，中间更新会被合并折叠，changelog 是表状态的变更序列而非源事件的逐条副本，下游不要按"每个源事件都可见"来设计。代价有二：一是全量 compaction 本身就是最贵的操作，写放大和资源峰值都最高；二是 changelog 的新鲜度完全取决于全量 compaction 的频率——它不是实时流，而是"一批一发"。用 full-compaction.delta-commits 控制每隔多少次提交触发一次全量 compaction，等于同时在拧成本和延迟两个旋钮。基于 Flink 与 Paimon 搭实时数仓的公开实践（如 Flink 与 Paimon 构建流式数仓的示例）也遵循同样的取舍逻辑。

决策清单

按顺序回答四个问题，答案基本指向唯一选项：

• 表的 merge-engine 是否会产生合并（partial-update、aggregation、去重覆盖）？否 → input 基本够用。
• 下游是否需要 update_before 或完整的合并结果？是 → 排除 input。
• 下游能接受的 changelog 延迟是秒级还是分钟级以上？分钟级以上 → full-compaction。
• 写入吞吐是否大到 lookup 会成为瓶颈（大状态、高 QPS、查落盘）？是且延迟要求又高 → 先拆 bucket、扩并发，或把 lookup 链路与冷数据链路分开，再谈换模式。

配置示例与配套调优

成本优先的离线入湖表，用 SQL 建表时直接落表选项：

CREATE TABLE ods_order (
    order_id BIGINT,
    -- 其余字段
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'merge-engine' = 'deduplicate',
    'changelog-producer' = 'full-compaction',
    'full-compaction.delta-commits' = '20'
);

新鲜度优先的实时维表则只需把 changelog-producer 换成：

'changelog-producer' = 'lookup'

写入侧还有几个与 changelog-producer 强相关的旋钮：num-sorted-run.compaction-trigger 决定多少个 sorted run 触发普通 compaction，调小会让写放大提前、读性能变好；write-buffer-size 决定写入内存缓冲，lookup 模式下配合更紧凑的 compaction 节奏可以减少查到未合并数据的概率；固定 bucket 数在 lookup 模式下尤其重要，bucket 动态扩缩会让查的目标漂移，排查成本很高。真实链路的调优顺序和踩坑点可参考这类流式写入实践记录。

失败模式

• 给 partial-update 表配 input 还指望下游拿到完整行：下游必然出现半行脏数据，且任务状态显示成功，属于静默错误。
• `full-compaction.delta-commits` 设成 1 或 2：等于每次提交都全量 compaction，成本比 lookup 还高，写入吞吐断崖式下跌。
• delta-commits 设得过大又没配延迟告警：changelog 长时间不产出，下游以为链路挂了，其实是设计如此。
• 把 changelog-producer 当成端到端 exactly-once 的保证：它只管 changelog 完整性，消费侧幂等和两阶段提交仍要下游自己负责。
• 大吞吐链路上开 lookup 却不看状态体积：先把写入延迟、compaction 耗时、checkpoint 时长三组指标盯住，再决定加资源还是换模式。