news 2026/6/25 1:05:41

paimon 主键表 vs 非主键表配置速查

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
paimon 主键表 vs 非主键表配置速查

快速参考:主键表 vs 非主键表配置速查

快速决策工具:一页纸搞定主键表和非主键表的选择和配置


🎯 30 秒快速决策

需要 UPDATE/DELETE?

主键表

数据可能重复?

非主键表


📊 核心差异速查表

维度主键表 ✋非主键表 📄
定义PRIMARY KEY (id) NOT ENFORCED不定义主键
操作INSERT, UPDATE, DELETE仅 INSERT
Split 策略1 Bucket ≈ 1 Split1 Bucket = 多 Splits
批处理并行度≈ Bucket 数(10-100)>> Bucket 数(100-1000+)
读取方式Merge(慢)Concat(快)
吞吐量150-250 MB/s400-600 MB/s
适用场景CDC、维度表日志、指标

⚡ 配置速查

主键表快速配置

-- 建表CREATETABLEmy_pk_table(idBIGINT,dataSTRING,PRIMARYKEY(id)NOTENFORCED-- 🔑 定义主键)PARTITIONEDBY(dt STRING)WITH('bucket'='64',-- 🔑 并行度关键:Bucket 数要足够'compaction.max-file-num'='50'-- 🔑 频繁 Compaction);-- 批处理查询配置SET'execution.runtime-mode'='batch';SET'scan.infer-parallelism'='true';SET'scan.infer-parallelism.max'='128';-- 略大于 Bucket 数SET'scan.split-assign-mode'='fair';-- 🔑 推荐 FAIRSET'split.target-size'='128mb';-- 默认即可-- 预期:并行度 ≈ 64

非主键表快速配置

-- 建表CREATETABLEmy_append_table(log_id STRING,dataSTRING-- 🔑 不定义主键)PARTITIONEDBY(dt STRING)WITH('bucket'='16',-- 🔑 Bucket 可以少一些'compaction.max-file-num'='100');-- 批处理查询配置SET'execution.runtime-mode'='batch';SET'scan.infer-parallelism'='true';SET'scan.infer-parallelism.max'='500';-- 🔑 可以很高SET'scan.split-assign-mode'='preemptive';-- 两种都可以SET'split.target-size'='64mb';-- 🔑 可以更小,增加并行度-- 预期:并行度 >> 16,取决于数据量

🔢 并行度速算公式

主键表

批处理并行度 ≈ Bucket 数量 流处理并行度 = Bucket 数量(固定)

示例

  • Bucket = 32
  • 批处理并行度 ≈ 32
  • 流处理并行度 = 32

非主键表

批处理并行度 ≈ 总数据量 / split.target-size 流处理并行度 = Bucket 数量(Fixed Bucket) 流处理并行度 >> Bucket(Unaware Bucket)

示例

  • Bucket = 16
  • 每个 Bucket = 500MB
  • split.target-size = 128MB
  • 批处理并行度 ≈ (16 × 500MB) / 128MB ≈ 63

🎛️ 参数速查

核心参数对比

参数主键表推荐非主键表推荐
bucket64-2568-64
split.target-size128mb-256mb64mb-128mb
scan.infer-parallelism.maxBucket × 2500-1000
scan.split-assign-modefairpreemptive
compaction频率每天每周

🏃 性能速查

读取速度对比(100GB 数据)

指标主键表非主键表倍数
执行时间8 分钟3 分钟2.7x
吞吐量200 MB/s550 MB/s2.8x
CPU 利用率80%50%0.6x
内存占用16GB8GB0.5x

结论:非主键表读取性能约为主键表的2.5-3 倍


🛠️ 常见问题速查

Q1: 为什么主键表读取这么慢?

A:

  • 并行度低(受 Bucket 数限制)
  • 需要 Merge 操作(CPU 密集)
  • 多层级文件(IO 开销大)

解决方案

  1. 增加 Bucket 数量(提高并行度)
  2. 定期 Compaction(减少 Merge 开销)
  3. 考虑改用非主键表(如果不需要更新)

Q2: 我的主键表只有 10 个 Buckets,批处理很慢怎么办?

A:

-- 方案 1:增加 Bucket 数(需要重建表)ALTERTABLEmy_tableSET('bucket'='64');-- 方案 2:等待 Compaction 完成(临时方案)CALLsys.compact('database.my_table');-- Compaction 后,如果都是高 Level 文件,可以切分-- 方案 3:改为非主键表(如果不需要更新)CREATETABLEmy_new_tableASSELECT*FROMmy_table;

Q3: 非主键表如何去重?

A:

-- 方案 1:在查询时去重SELECTDISTINCT*FROMmy_append_tableWHEREdt='2026-01-25';-- 方案 2:在 INSERT 时去重INSERTINTOtarget_tableSELECTDISTINCT*FROMsource_table;-- 方案 3:改为主键表(自动去重)CREATETABLEmy_pk_table(idBIGINT,dataSTRING,PRIMARYKEY(id)NOTENFORCED)ASSELECT*FROMmy_append_table;

Q4: 应该选择多少个 Buckets?

A:

主键表

Bucket 数 = 期望的并行度 推荐: - 小规模(< 100GB):32-64 - 中规模(100GB - 1TB):64-128 - 大规模(> 1TB):128-256

非主键表

Bucket 数 = 期望的流式并行度(批处理不受限) 推荐: - 小规模:8-16 - 中规模:16-32 - 大规模:32-64 原因:非主键表批处理并行度不依赖 Bucket 数

Q5: 如何判断我的表是主键表还是非主键表?

A:

-- 查看表定义SHOWCREATETABLEmy_table;-- 输出示例 1(主键表):-- PRIMARY KEY (id) NOT ENFORCED---- 输出示例 2(非主键表):-- (没有 PRIMARY KEY)-- 或者查看元数据SELECT*FROMmy_table$schemas;

📋 配置模板

主键表 - 批处理作业

-- ============ 主键表批处理模板 ============-- 1. 建表CREATETABLEmy_pk_table(idBIGINT,dataSTRING,update_timeTIMESTAMP,PRIMARYKEY(id)NOTENFORCED)PARTITIONEDBY(dt STRING)WITH('bucket'='64','compaction.max-file-num'='50','compaction.min-file-num'='10');-- 2. 配置SET'execution.runtime-mode'='batch';SET'scan.infer-parallelism'='true';SET'scan.infer-parallelism.max'='128';SET'scan.split-assign-mode'='fair';-- 3. 查询SELECT*FROMmy_pk_tableWHEREdt='2026-01-25';-- 4. 优化建议-- - 增加 Bucket 数到 128(如果并行度不够)-- - 定期执行:CALL sys.compact('db.my_pk_table');

非主键表 - 批处理作业

-- ============ 非主键表批处理模板 ============-- 1. 建表CREATETABLEmy_append_table(log_id STRING,dataSTRING,timestampBIGINT)PARTITIONEDBY(dt STRING)WITH('bucket'='16','compaction.max-file-num'='100');-- 2. 配置SET'execution.runtime-mode'='batch';SET'scan.infer-parallelism'='true';SET'scan.infer-parallelism.max'='500';SET'split.target-size'='64mb';SET'scan.split-assign-mode'='preemptive';-- 3. 查询SELECT*FROMmy_append_tableWHEREdt='2026-01-25';-- 4. 优化建议-- - 减小 split.target-size 到 32mb(如果需要更高并行度)-- - 定期合并小文件:CALL sys.compact('db.my_append_table');

主键表 - 流处理作业

-- ============ 主键表流处理模板 ============-- 1. 建表CREATETABLEmy_pk_stream_table(idBIGINT,dataSTRING,PRIMARYKEY(id)NOTENFORCED)WITH('bucket'='128',-- 流处理并行度 = Bucket 数'changelog-producer'='input','scan.mode'='latest');-- 2. 配置SET'execution.runtime-mode'='streaming';SET'scan.parallelism'='128';SET'scan.snapshot-time-interval'='10s';SET'execution.checkpointing.interval'='60s';SET'state.backend'='rocksdb';-- 3. 查询SELECTCOUNT(DISTINCTid)asuser_cntFROMmy_pk_stream_table;

非主键表 - 流处理作业

-- ============ 非主键表流处理模板 ============-- 1. 建表CREATETABLEmy_append_stream_table(log_id STRING,dataSTRING)WITH('bucket'='64',-- 可以比主键表少'scan.mode'='latest');-- 2. 配置SET'execution.runtime-mode'='streaming';SET'scan.parallelism'='64';SET'scan.snapshot-time-interval'='10s';SET'execution.checkpointing.interval'='60s';-- 3. 查询SELECTCOUNT(*)aslog_cntFROMmy_append_stream_table;

🎨 可视化速查

Split 数量对比

场景:1 个分区,10 个 Buckets,每个 1GB 主键表(有 Level 0): ├─ Split 数量:10 个(= Bucket 数) ├─ 并行度:10 └─ 原因:Key Range 重叠,不能切分 非主键表: ├─ Split 数量:80 个(10GB / 128MB) ├─ 并行度:80 └─ 原因:可以自由切分

性能对比

读取 100GB 数据: 主键表(需要 Merge): [████████░░] 8 分钟 非主键表(顺序拼接): [███░░░░░░░] 3 分钟 性能提升:2.7x

🚨 常见错误

❌ 错误 1:主键表 Bucket 太少

-- 错误配置CREATETABLEmy_table(idBIGINT,PRIMARYKEY(id)NOTENFORCED)WITH('bucket'='4'-- ❌ 太少!批处理并行度只有 4);-- 正确配置CREATETABLEmy_table(idBIGINT,PRIMARYKEY(id)NOTENFORCED)WITH('bucket'='64'-- ✅ 并行度可以达到 64);

❌ 错误 2:非主键表 Bucket 太多

-- 低效配置CREATETABLEmy_append_table(log_id STRING)WITH('bucket'='256'-- ❌ 太多!会产生大量小文件);-- 推荐配置CREATETABLEmy_append_table(log_id STRING)WITH('bucket'='16'-- ✅ 适中,批处理并行度通过 Split 切分实现);

❌ 错误 3:主键表使用小 Split

-- 错误配置SET'split.target-size'='32mb';-- ❌ 对主键表无效(无法切分)-- 正确做法-- 主键表:增加 Bucket 数量而不是减小 SplitALTERTABLEmy_pk_tableSET('bucket'='128');

💡 优化技巧速查

主键表优化

1. 🔧 提高并行度 └─ 增加 Bucket 数量(核心手段) 2. 🔧 减少 Merge 开销 └─ 定期 Compaction └─ 减少 Level 0 文件 3. 🔧 批处理优化 └─ 选择 Compaction 完成后的快照 └─ 使用 FAIR 分配模式 4. 🔧 流处理优化 └─ Bucket 数 = 期望并行度

非主键表优化

1. 🔧 提高并行度 └─ 减小 split.target-size(核心手段) └─ 提高 scan.infer-parallelism.max 2. 🔧 减少小文件 └─ 定期 Compaction └─ 适当减少 Bucket 数 3. 🔧 批处理优化 └─ 充分利用高并行度 └─ 使用 PREEMPTIVE 分配模式 4. 🔧 流处理优化 └─ 考虑使用 Unaware Bucket(如果允许)

📞 决策热线

我应该用哪种表?

问自己 3 个问题: 1. 是否需要 UPDATE 或 DELETE? └─ 是 → 主键表 └─ 否 → 继续 2. 数据是否可能重复(需要去重)? └─ 是 → 主键表 └─ 否 → 继续 3. 读取性能是否非常关键? └─ 是 → 非主键表 └─ 否 → 都可以,推荐非主键表(性能更好)

我的配置合理吗?

检查清单: 主键表: ☐ Bucket 数 >= 32? ☐ scan.split-assign-mode = 'fair'? ☐ 定期执行 Compaction? ☐ scan.infer-parallelism.max >= Bucket × 2? 非主键表: ☐ split.target-size <= 128mb? ☐ scan.infer-parallelism.max >= 200? ☐ Bucket 数不要太多(<= 64)? ☐ 定期合并小文件?

🔗 相关文档链接

  • 详细对比:《Paimon 主键表 vs 非主键表核心差异》
  • Split 机制:《Paimon Split 机制深度解析》
  • 配置指南:《Paimon Flink 配置实战指南》
  • 读取流程:《Paimon 分布式读取数据完整流程》

如果你喜欢这篇文章,请转发、点赞。扫描下方二维码关注我们,您会收到更多优质文章推送
在这里插入图片描述

关注「Java源码进阶」,获取海量java,大数据,机器学习资料!
版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/21 9:44:40

汽车制造业可观测性平台选型指南

行业现状与痛点分析随着汽车行业向智能化、网联化、电动化转型&#xff0c;传统汽车制造企业正面临数字化转型的深刻挑战。现代汽车制造生态系统日益复杂&#xff0c;涵盖了生产线设备、供应链管理系统、车联网平台、移动应用程序和经销商网络等多个层面。主要痛点包括&#xf…

作者头像 李华
网站建设 2026/6/16 5:48:08

面试-RMSNorm和LayerNorm的区别

1 LayerNorm 背景: 在神经网络中,每一层输出都将作为下一层的输入。 问题: 在训练过程中,前一层参数的微小更新,所带来的输出会导致后一层输入的分布发生剧烈变化。这就是层与层之间的动态失调。俗称 内部协变量偏移(Internal Covariate Shift)。 现象: 比如,第一层…

作者头像 李华
网站建设 2026/6/14 14:10:43

GPU 和 CPU 渲染谁更顶?新手必看的选型指南

在3D渲染、影视后期、游戏开发领域&#xff0c;“GPU与CPU渲染选哪个”是高频争议题。新手纠结硬件选型&#xff0c;老手权衡效率与质量&#xff0c;实则二者无绝对优劣&#xff0c;核心是适配场景——如同搬东西&#xff0c;CPU像法拉利&#xff08;快但装载量小&#xff09;&…

作者头像 李华
网站建设 2026/6/14 14:02:31

【六杆】六杆快速回归机制运动学和动力学分析附Matlab代码

✅作者简介&#xff1a;热爱科研的Matlab仿真开发者&#xff0c;擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。 &#x1f34e; 往期回顾关注个人主页&#xff1a;Matlab科研工作室 &#x1f447; 关注我领取海量matlab电子书和数学建模资料 &#…

作者头像 李华
网站建设 2026/6/14 14:08:41

java: 找不到符号方法 getCode()

运行Spring Boot工程代码出现以下报错&#xff1a; 位置: 类型为com.xx.xx.exception.ErrorCode的变量 errorCode解决方法看截图中间那个路径框&#xff1a; ...lombok\unknown\lombok-unknown.jar这里的 unknown 说明 IDEA 根本没找到 Lombok 的 jar 包。 接下来&#xff0c; …

作者头像 李华