Paimon 实时湖仓实战 （第5篇）：并行度从 16 拉到 128，查询反而更慢：Paimon Bucket 不是越多越好

大促前团队担心订单入湖扛不住峰值于是把 Flink 写入并行度和 Paimon Bucket 一起从 16 拉到 128。上线后吞吐没有明显提升对象存储请求和文件数却快速上涨原本稳定的批查询开始被大量小 Split 拖慢。问题不在于 128 这个数字天然错误而在于团队把“更多 Bucket”直接等同于“更高吞吐”。Bucket 一边决定并行上限另一边也决定一次提交可能触达多少个文件单元数据量撑不起这些 Bucket 时扩容只是在批量制造空转和小文件。Bucket 既是 Paimon 的最小读写单元也是每次提交制造文件的乘数超过数据规模需要的 Bucket只会把一个大问题切成很多小问题。下文的 Bucket 模式、配置和源码均固定在Apache Paimon 2.0.0源码基线为release-2.0.0/604e6d5e...。先别急着填数字三种 Bucket 模式解决的不是同一个问题模式配置如何决定 Bucket关键边界Fixedbucket 0Key Hash 对固定数量取模扩缩容要离线重写存量布局Dynamic默认或bucket-1维护 Key 到 Bucket 的索引并自动扩展同一分区只支持一个写作业Postponebucket-2批写估算或先落 postpone 再 Compaction 分配postpone 文件在进入真实 Bucket 前不可读Data Distribution 官方文档 建议每个 Bucket 的数据量大致保持在 200MB—1GB。这个范围是设计起点不是对任意压缩率、更新率和查询模式的 SLA。为什么多出的并行度会变成更多文件和 Split假设一个分区有 128 个 BucketCheckpoint 每 30 秒触发一次即使不是每个 Bucket 都有数据频繁写入仍可能形成大量 L0 与 Changelog 文件。Bucket 太少时单 Bucket 吞吐和读取归并成为瓶颈Bucket 太多时文件系统元数据、对象存储请求、调度与小文件合并成为瓶颈。Bucket 太少 → 热 Bucket → 单 LSM 读写长尾 → 并行度上不去 Bucket 太多 → 每次提交文件数上升 → 小文件/Manifest/Split 增多 → 读写放大Dynamic Bucket 会自动扩展但不会自动协调多个 Writer容量估算只能给 POC 起点候选 Bucket 数 ≈ 活跃分区压缩后数据量 ÷ 目标单 Bucket 数据量 有效写并行上限 ≤ 活跃 Bucket 数 单次提交文件面 ≈ 被触达 Bucket 数 × 文件类型平均值会掩盖热点因此验收必须同时计算最大 Bucket 与平均 Bucket 的数据量、文件数和 Compaction 积压比。Dynamic Bucket 通过本地索引维护主键到 Bucket 的映射并按数据增长自动增加 Bucket。官方明确限制同一分区只能由一个写作业写入多个 Writer 可能产生重复数据write-only加独立 Compaction 也不能修复这个语义问题。它适合难以预估规模、更新比例较低的主键表。代价是索引内存与启动时初始化跨分区 Upsert 还要维护 Key 到分区和 Bucket 的全局映射数据很大时会明显增加恢复时间和资源。POC 不能只改 Bucket 数还要固定另外五个变量固定输入速率、Checkpoint 间隔、更新比例与资源分别测试 8、32、128 个 Bucket并记录SELECT*FROMorders$files;SELECT*FROMorders$snapshotsORDERBYsnapshot_idDESC;观察每个 Bucket 的数据量、文件数、层级与倾斜再对同一组查询保存扫描文件数、Split 数、P95/P99。若 128 Bucket 只降低了平均写入时间却让文件数、Checkpoint 尾延迟与批查询成本上升它就不是扩容。证据8 Bucket32 Bucket128 BucketWriter 吞吐与反压实测实测实测Checkpoint P95/P99实测实测实测每 Snapshot 新文件数实测实测实测最大/平均 Bucket 数据量实测实测实测查询扫描文件与 Split实测实测实测Compaction 消化/产生比实测实测实测用户未提供真实数字不能用演示值填表。最终点应同时满足热点不持续积压、文件进入稳态、查询尾延迟达标、对象存储请求在预算内。Fixed Bucket 的修改需要第 11 篇的两阶段 Bucket 扩容流程完成数据重写Dynamic Bucket 要接受单分区单 Writer 和索引恢复成本Postpone Bucket 要接受 Compaction 前不可读。三种模式解决不同的不确定性不能只按是否自动扩容排序。Bucket 的目标不是越多越并行而是让每棵 LSM 都有足够工作、又不至于成为热点。用 Java 读取系统表区分“热点”与“分得太碎”固定版本源码如何决定 Bucket源码固定为release-2.0.0/604e6d5e...。paimon-core/src/main/java/org/apache/paimon/bucket/DefaultBucketFunction.java的bucket(BinaryRow, int)按 Bucket Key 哈希后取模Dynamic Bucket 则由paimon-core/src/main/java/org/apache/paimon/index/DynamicBucketIndexMaintainer.java的notifyNewRecord()更新索引并在prepareCommit()产生索引文件。对应源码DefaultBucketFunction、DynamicBucketIndexMaintainer。Java 对$files的分组结果是上述路由的物理结果少数 Bucket 文件数或字节数远高于中位数支持热点判断全部 Bucket 都很小且文件多更支持 Bucket 过量或提交过密。系统表结果不能单独证明是哪一个配置造成了分布仍要与生效 DDL 对齐。以下只读程序按paimon-flink-1.20:2.0.0API 编写args[0]为 Warehouse本环境未运行全文示例。importorg.apache.flink.table.api.EnvironmentSettings;importorg.apache.flink.table.api.TableEnvironment;publicfinalclassBucketSkewProbe{publicstaticvoidmain(String[]args){if(args.length!1)thrownewIllegalArgumentException(warehouse is required);Stringwarehouseargs[0].replace(,);TableEnvironmenttTableEnvironment.create(EnvironmentSettings.newInstance().inBatchMode().build());t.executeSql(CREATE CATALOG p WITH (typepaimon,warehousewarehouse));t.executeSql(USE CATALOG p);t.executeSql(SELECT bucket,COUNT(*) AS files,SUM(file_size_in_bytes) AS bytes FROM demo.orders$files GROUP BY bucket ORDER BY bytes DESC).print();}}最大 Bucket 文件数、字节数远高于中位数时才支持倾斜判断所有 Bucket 都小且文件多更像 Bucket 过量或 Checkpoint 太密。Fixed Bucket 由 Hash/取模路径选择Dynamic Bucket 还会进入DynamicBucketIndexMaintainerJava 查询只能观察结果不能证明索引恢复成本。官方资料Data DistributionPrimary Key TableRescale Bucket