企业官网建设流程全解析

开头先讲个我自己的经历。接手过好几个Flink作业，表现非常一致：Kafka source端的Lag在缓慢上涨，sink端看指标一切正常，Hive/Doris/Paimon的写入速率也没跌，但整条链路就是越来越慢，Checkpoint偶尔超时，重启之后好一阵，过几个小时又回到原样。一开始按老经验去调并行度、加内存、调背压阈值，效果都很差。后来无意间翻了Paimon表目录底下的snapshot文件，才反应过来——反压压根不在算子吞吐上，而是被快照管理这一层悄悄卡住了。

Apache Paimon的核心写路径跟普通的消息队列落地完全不同。它把流式数据以快照（Snapshot）形式组织，每次Flink Checkpoint提交都对应一次snapshot生成，快照之间通过Manifest文件索引数据文件，底层又是LSM风格的文件组织。这意味着快照数量、Manifest体积、小文件数量任何一个失控，都会传导到写入端的commit耗时上，最后变成Flink作业里那排“隐形”的背压。很多人把“避免反压”理解成调并行度或者压Sink吞吐，其实在Paimon场景里，先理清快照生命周期，优先级反而更高。

这篇文章就把我在这类问题上的完整排查链路和调优方法写出来。适合用Paimon做流式数仓落地、或者正在为Flink持续写入性能发愁的同学，看完可以直接对着参数改。

1. 先别调并行度：我遇到的反压其实藏在快照里

1.1 症状看起来像数据倾斜，但细看又不是

典型的异常指标组合是这个样子的：Flink UI上source端出现背压提示，而sink端的currentSendTime和numRecordsOutPerSecond都没有明显下降。此时很多人的第一反应是怀疑key分布不均匀，或者某个subtask被大key拖住了。打开subtask级别指标看了一圈，数据速率十分平均，CPU和JVM线程也没有哪个特别高。

这种“上游堵、下游空”的现象，说明瓶颈不在算子本身的处理逻辑上，而在算子之间——准确点说，是sink到外部存储之间的提交协议出了问题。Paimon的SinkFunction在Flink里属于两阶段提交的实现，Checkpoint成功之后需要回调Paimon的commit方法，生成新的Snapshot并提交。如果这个commit动作本身耗时很长，Checkpoint就一直在等，source端自然会出现背压。

有个很直观的类比是：你往仓库运货，叉车速度没问题，货物在门口等着办入库手续，一个人对着Excel表格挨个登记。货越积越多，门口就堵了。Paimon的snapshot和manifest就是那本Excel，文件越多，登记越慢。

1.2 为什么“快照管理”会成为瓶颈

Paimon的设计里，每次写入Commit并不是只写一个数据文件就完事。它要做的事包括：写数据文件、生成/更新Manifest列表、记录新增的Snapshot，然后异步触发文件清理和compaction。这些动作存在很强的放大效应：

• 每个Bucket里小文件越多，Manifest记录的条目就越多，下一次commit扫描时需要解析的Manifest文件数量就越大。
• Snapshot只保留最近N个或最近T小时，过期清理需要扫描文件引用关系，文件条目越多，清理一次就越慢，清理任务堆积又会拖慢后续的commit。
• 同步compaction如果开启，压缩过程会占用写线程资源，commit会等待压缩完成。

这几个因素叠加在一起之后，你会看到Flink作业的反压从偶发变成持续，压缩节奏越来越跟不上写入节奏，最终到达一个临界点：文件生成速度大于清理速度，快照数量和文件数量同时膨胀，形成恶性循环。

所以当我们在说“Paimon快照管理避免反压”的时候，本质上是让快照的生成速度和清理/合并速度恢复平衡，而不是让下游“别写那么快”。

2. 快照膨胀如何一步步卡住Flink写路径

2.1 一次写入背后发生了什么：从Flink任务到Snapshot

先从上到下理一遍整个过程。假设你有一个Flink SQL任务，从Kafka读数据，写入Paimon表，Checkpoint间隔设为5分钟。每次Checkpoint成功，Paimon的Sink会执行一次分布式提交，流程大致是：

1. 所有写入子任务把已经缓冲的数据flush成avro或parquet格式的数据文件。
2. 协调器将新产生文件的元数据写入一个新建的Manifest文件。
3. 生成一个新的Snapshot，指向最新的Manifest列表。
4. 旧Snapshot及其引用的、已经不在有效范围内的文件进入清理队列。
5. 后台线程或同步线程执行compaction（根据触发条件决定）。

这里面任何一步慢了，Flink的Checkpoint都会受到影响。特别是第三步，如果Manifest很大，生成Snapshot的过程就容易飙到几百毫秒甚至几秒。从Flink UI上看，Sink的checkpointStartDelay会明显变长，网络繁忙时间（busyTimeMsPerSecond）倒是正常。

很多人在这里有个误区，以为Paimon和普通文件系统一样，写完文件就完事。实际上Paimon的元数据设计是“追加式”的，每次commit都会产生新的Snapshot和Manifest文件，历史文件只有在Snapshot过期后才会被逐步清除。所以它天生就依赖“定期压缩”和“快照清理”来维持健康度，这两个动作跟不上，写入性能必然退化。

2.2 一个具体的膨胀模型：小文件与sorted run怎么联手反噬

用一个真实调过的无主键表来算笔账。表定义时Bucket数设成了20，Kafka有12个分区，Flink Sink并行度12。每次Checkpoint，每个并行度至少往一个Bucket写文件，极端情况下每个Checkpoint生成12个小文件。一天120次Checkpoint（5分钟一次，按12小时高峰算），小文件数量就是1440个左右。每个文件在Manifest里至少有一条记录，Manifest会先膨胀到一定大小然后被分裂合并，这个过程中scan和commit的开销直线上升。

同时，无主键表在Paimon里的写模型是纯追加，compaction的触发条件是sorted run数量达到阈值。当每个Bucket被多个并发写任务写入时，sorted run会快速堆积。而compaction本身要读取旧文件内容、重新写出新文件，IO压力增大，如果在提交路径上等待compaction，写作业就真的“卡”了。

这个阶段的典型特征是：Flink作业速率看起来稳定，但端到端延迟在持续变大，checkpoint完成时间从十几秒涨到几十秒。很多人的第一反应是降低Checkpoint间隔，结果反而加剧问题——Checkpoint越频繁，Snapshot生成次数越多，文件越多，更堵。

2.3 慢的还有快照过期和清理阶段

快照过期（snapshot expire）不是一瞬间完成的动作。Paimon的清理逻辑会根据Manifest文件中的引用关系，决定哪些数据文件可以删、哪些需要保留。文件数量大、分桶多的情况下，一次清理要扫描成千上万个文件引用，这个扫描过程会让CPU I/O产生明显毛刺。再赶上多个写作业同时提交同一个表，清理任务和提交任务的锁竞争会让Commit等待更久。

这一段的结论是：**Paimon的反压问题，大多数情况下不是你Sink代码写得有问题，而是表的结构参数和管理策略没有跟上写入模式。**调并行度之前，先把snapshot文件层的“库存”看清楚。

3. 三分钟判断反压是否来自快照/文件层

3.1 第一看Flink UI，第二看Paimon Metrics

不要上来就开Flink页面盯背压颜色，先把这几个指标按顺序排一遍：

• Checkpoint完成时间。如果完成时间有明显上升趋势，而Sink算子吞吐没变化，基本可以确定瓶颈在提交/提交前阶段。
• Sink的checkpointStartDelay。这个值如果一直在增长，说明Sink在接受上游数据时就在等待Checkpoint对齐，很多情况下是写Paimon的commit太慢。
• Paimon自带Metrics。0.7及以上版本在Flink作业里记录了paimon.writer.*相关指标，重点看lastCommitDuration和commitCount，如果lastCommitDuration从几十毫秒涨到几百毫秒甚至数秒，说明写路径已经在等元数据操作。

还有一个辅助判断：把Flink作业的Checkpoint间隔临时调大一倍（比如从5分钟改成10分钟），如果反压程度明显减轻，那几乎可以断定是快照提交频率太高，导致文件层处理不过来。这个实验代价极低，效果却很直接。

3.2 第三看文件系统：snapshot和manifest数量不再玄学

文件系统层面的观察是终极大招。无论你的Paimon表在HDFS、S3还是本地OSS，表目录下的结构都类似：

warehouse/ my_db.db/ my_table/ snapshot/ manifest/ bucket-0/ bucket-1/ schema/

进到snapshot目录，数一下snapshot文件数量，正常情况下应该维持在几十个以内，并且与配置的snapshot.num-retained.*、snapshot.time-retained参数大致吻合。如果这个目录下的文件数量持续增长到几百上千，说明快照过期逻辑没有及时生效，或者被读端/写入端消费拖住了。

接着看manifest目录，里面是manifest-*.parquet和包含索引信息的文件。这个目录的大小直接反映表的小文件健康度。文件数量大、且单个manifest文件超过几十MB，意味着compaction没跟上。

最后看底层数据文件，比如bucket-0目录下，如果某个bucket的小文件数量到了几百，不需要再看别的指标，这就是写入速度远大于compaction速度的直观证据。

# 快速统计某个bucket下的小文件数量 hdfs dfs -ls /warehouse/my_db.db/my_table/bucket-0 | wc -l

我平时写排查脚本的第一行就是这条命令。可能不准，但能一瞬间告诉你问题严重程度。

4. 参数这么调：既保读取数据，又能缓解写端压力

4.1 快照过期参数的安全调法

Paimon快照参数主要在表参数里配置，常见组合如下：

我的调参经验是：先确定“读端最长可能落后多少数据”。比如你有Flink全量增量同步、或者有即席查询要从Paimon读历史时间点数据，那snapshot.time-retained要把那段窗口覆盖住。如果纯流式消费，落后最多几分钟，那snapshot.time-retained完全可以从默认的1小时缩到30分钟，减少过期阶段扫描开销。

-- Flink SQL里修改表参数示例 ALTER TABLE my_table SET ( 'snapshot.time-retained' = '30 m', 'snapshot.num-retained.min' = '10', 'snapshot.num-retained.max' = '100' );

注意一点：不要为了“尽快释放空间”把snapshot.time-retained调到非常离谱的短（比如1分钟），这会带来连锁问题。具体踩坑经历我会在第五部分单独讲。

4.2 consumer-id：给读端加一道保险，再放心去清快照

很多不敢开快照清理的团队，原因是“下游还在消费老数据，万一被清掉了，任务直接失败”。Paimon的consumer-id机制就是解决这个问题的。读端在消费Paimon表时指定一个consumer-id，Paimon会记住这个消费者读到的快照位置，清理逻辑会主动跳过仍被消费者引用的快照。

-- 消费端设置consumer-id示例 CREATE TABLE my_table_consume ( ... ) WITH ( 'connector' = 'paimon', 'path' = '...', 'consumer-id' = 'my_consumer' );

这样做的价值是，上游写作业可以放心地把snapshot.time-retained调小，不影响下游读取。我见过不少团队因为不敢动快照过期，让快照数量从几十涨到几百，最终把写作业拖垮。加了consumer-id之后，清理压力瞬间小很多。

但要注意，consumer-id主要用于流式读场景。批式查询或者临时Ad-Hoc查询不会持续注册为一个消费者，还是要靠snapshot.time-retained来兜底。

4.3 压缩拆分：write-only加外部Compaction的正确姿势

如果你发现即使调了快照过期，小文件增长依然压不住，那么核心问题多半是compaction跟不上，而非快照清理太慢。Paimon的表参数里有一组专门用于“将压缩责任剥离”的设置：

最重要的一步是给Paimon表单独挂一个Compaction作业，而不是让Flink写入作业在提交路径上顺便做压缩。Paimon官方推荐的Flink托管压缩Job，本质是一个流式作业，持续监听表的新增快照并触发合并，写作业本身不需要等压缩完成。

-- 核心思路：写作业打开write-only ALTER TABLE my_table SET ( 'write-only' = 'true' ); -- 单独启动一个compaction任务，监听并压缩 -- 一般通过paigon自带的Flink action实现

但是这里有一个极其常见的坑：只打开了write-only，却没有启动任何外部compaction任务。结果写入速度确实上去了，但小文件疯狂累积，几天之后表的Read性能和后续Compaction性能一起崩掉。我后面案例里会细说这个翻车现场。所以write-only不是“让压缩消失”，而是“让压缩让位”，必须有另一个人接手。

启动外部compaction任务的方式通常是提交一个常驻Flink Job，核心逻辑是调用Paimon的compactaction，也可以通过Flink SQLINSERT INTO ...配合compactionhint来做。日常运维我会在任务管理里单独划分一个作业资源池，避免压缩作业和写作业抢资源。

4.4 别忽略的写入端配置：Bucket、Checkpoint间隔和Sink并行度

参数调了半天，如果表结构设计本身不合理，优化空间非常有限。

Bucket数量是Paimon表最重要的设计参数之一。流式写入场景，每个Bucket在同一个时间点会接受一个或多个并行子任务写入。Bucket数越大，并行写能力越强，但也意味着小文件数量可能更多、Manifest条目膨胀更快、Compaction范围更大。我在实践中通常是先按数据量中值估算，比如单Bucket写入达到10MB/s以上再考虑加Bucket，而不是一开始就设32甚至64。

Checkpoint间隔记得同步审查。每次Checkpoint至少对应一次snapshot生成。Checkpoint太频繁，snapshot生成速度快于compaction清理速度，文件层会持续失血。把Checkpoint间隔从1分钟调到5分钟，甚至10分钟，对吞吐敏感的场景收益非常显著。愿意接受秒级延迟的实时链路，不建议直接把Paimon当消息队列用，它毕竟是湖存储，而是要用“延迟换吞吐”的思路。

Sink并行度与Bucket数量的关系也需要注意。Sink并行度显著大于Bucket数量时，多个子任务会往同一个bucket写，每个子任务都生成独立的小文件，容易形成“并行度越高文件越碎”的反效果。我的一般建议是Sink并行度接近或略大于Bucket数，具体根据单文件写入大小微调。

-- 一个从Kafka到Paimon的简易表参数示例 CREATE TABLE my_table ( k STRING, v STRING, dt STRING, PRIMARY KEY (k, dt) NOT ENFORCED ) PARTITIONED BY (dt) WITH ( 'connector' = 'paimon', 'path' = 'hdfs:///warehouse/my_db.db/my_table', 'bucket' = '8', 'write-only' = 'false', 'snapshot.time-retained' = '30 m', 'snapshot.num-retained.min' = '10', 'snapshot.num-retained.max' = '100' );

5. 复盘：我踩过的三个真实案例和教训

5.1 案例一：快照清理被误杀，读端集体拉不到数据

有一回我为了压反压，把一张核心表的snapshot.time-retained从默认1小时直接改成了1分钟，当天晚上Flink CDC整库同步任务直接报错，错误信息大概是“snapshot not found”或者“state过期”。排查过程花了一个多小时，打开snapshot目录一看，历史快照被清理得只剩一两个，而CDC任务刚好要基于某个较早的snapshot位置读取增量。

原因很清楚：虽然有CDC任务在消费，但它的消费端没有配置consumer-id，Paimon的清理逻辑认为“没有活着的消费端”，加上时间策略又太激进，老快照就被直接扫掉了。从那以后我的调参原则改成了：先确认读端，再动保留时间。凡是下游有持续消费任务的表，要么配置consumer-id，要么snapshot.time-retained不要低于消费端最大落后时间的1.5倍。

5.2 案例二：write-only开了没安排人接手，小文件爆发

另一次是优化一个数据量较大的接入任务，为了提升写入性能我在表参数里加了'write-only'='true'。效果立竿见影，Sink写入速度提升明显，反压消失。但是大概两天之后，下游分析师反馈说查询这张表越来越慢，有时候一条简单的SELECT COUNT(*)要跑十几分钟。

进文件系统一查，某个分区下小文件数量膨胀到了几千个。因为这个作业是纯写入，没有任何compaction任务在跑，Paimon的write-only确实不再在写路径上触发压缩，但也等于“完全没人做卫生”。最后解决办法是：关闭write-only，立刻补跑了全量compaction，顺带把分区数做了裁剪，之后才恢复正常。

教训是：write-only只适合作为临时手段，或者在确定有独立compaction任务常驻的情况下长期使用。如果你没有专门的Paimon compaction作业管理，千万别打开它。

5.3 案例三：多作业并发写同一张表，Commit锁等待周期性反压

还有一个比较隐蔽的场景：同一张Paimon表被多个Flink作业同时写入，其中一个作业是从Kafka实时接入，另一个是离线批式回刷。批式作业每次启动都会触发大量的文件合并和快照提交，表面上看只是忽高忽低的IO，实际上两个作业在提交阶段存在资源竞争，实时作业的commit经常要等待文件锁。

表现为实时作业的反压呈现周期性：每两三个小时来一波，每次持续十几分钟，Checkpoint在此窗口内必然超时。后来把批式回刷改为只写临时分区、完成后再通过分区原子替换的方式切换数据，避免和实时流式写入直接冲突。同时把实时作业的snapshot.num-retained.min适当调高，降低批作业提交大事务对实时链路的扰动。

5.4 实战经验：把文件层监控做成自动化告警

经过几次翻车之后，我现在会在每个Paimon表的数据目录上做一个轻量级监控，定时统计三个数：snapshot文件数量、manifest文件数量、各bucket下小文件总数。不需要很复杂的框架，一个简单脚本配合可观测平台就够：

#!/bin/bash HDFS_PATH=$1 SNAPSHOT_COUNT=$(hdfs dfs -ls ${HDFS_PATH}/snapshot | wc -l) MANIFEST_COUNT=$(hdfs dfs -ls ${HDFS_PATH}/manifest | wc -l) BUCKET_FILE_COUNT=$(hdfs dfs -ls ${HDFS_PATH}/bucket-* | wc -l) echo "snapshot_count=$SNAPSHOT_COUNT manifest_count=$MANIFEST_COUNT bucket_file_count=$BUCKET_FILE_COUNT"

阈值的设定，根据你的Checkpoint频率和表规模来定。比如5分钟一个Snapshot，那snapshot数量通常在几十左右，超过100就要留意；bucket文件总数如果持续增长，且compaction执行频率也在上升，说明压缩能力已经跟不上写入速度。

这个监控看起来原始，但真的能在Flink背压指标变红之前提前暴露问题。多数情况下，文件层数字出现异常增长，早于Flink页面出现反压提示几个小时甚至更久。

6. 最后再补一刀：别让快照管理成为你的隐性瓶颈

如果让我把这篇内容浓缩成一句操作建议，那就是：排查Paimon写入反压的顺序，永远是先看快照和文件，再看并行度和内存，而不是反过来。

我个人现在处理新接入任务时，都会在表创建阶段就把快照保留策略和compaction策略想清楚。生产表的参数不是上线后才发现“哦这里慢”再回去补，而是提前留给文件层足够缓冲。像snapshot.time-retained、write-only、bucket这些参数，看起来只是几个表属性，实际决定了未来Flink作业能不能长期稳定运行。反压只是一个结果，根子通常埋在源端表设计和快照生命周期管理那里。

前面提到的调参数值，主要基于Paimon 0.7/0.8版本的默认行为。Paimon版本迭代很快，不同版本对compaction调度、快照清理的具体实现都有改动，建议上线前先看一遍对应版本的官方参数文档，再按你实际的读写模型微调。比“照着别人的参数抄一遍”更靠谱的做法是，每次改动参数后，同时记录Checkpoint耗时和snapshot文件数量曲线，用数据说话。

流式写入的稳定性，很多时候不是靠加资源砸出来的，而是靠减少不必要的工作量换来的。快照管理的作用就是在“保证读端需要的数据可用”和“别让文件无限堆积拖死写端”之间找到平衡。把握住这个平衡，Flink作业里的反压问题基本就解决了一大半。