paimon的四种changelog模式（4）-full-compaction模式

原创 已于 2025-10-30 11:39:22 修改 · 1.2k 阅读 · 19 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库 #大数据

于 2024-11-28 10:47:16 首次发布

请先了解lookup模式，然后再看full-compaction模式

环境创建

CREATE CATALOG fs_catalog WITH (
    'type'='paimon',
    'warehouse'='file:/data/soft/paimon/catalog'
);

USE CATALOG fs_catalog;

drop table if exists t_changelog_fullcompaction;
 
CREATE TABLE t_changelog_fullcompaction(
      age BIGINT,
      money BIGINT,
      hh STRING,
      PRIMARY KEY (hh) NOT ENFORCED
)WITH (
    'merge-engine' = 'deduplicate',
    'changelog-producer' = 'full-compaction'
);

paimon的snapshot和checkpoint之间的关系

  • 一次snapshot会产生一个data文件
  • 一次checkpoint会产生1-2个snapshot文件，要看这次checkpoint是否触发compaction，触发了就是2个data文件（一个是合并后的数据，一个本次checkpoint写入数据）,否则只有一个（本次checkpoint写入数据）
  • paimon 流式写入根据checkpoint间隔，定期生成snapshot
  • 批写（手动执行sql脚本）每一个sql会立即生成snapshot，不管checkpoint间隔配置

lookup模式，一次checkpoint会产生一个chagelog，而full-compaction会等待若干次checkpoint后才产生一个chagelog，这取决于参数
在这里插入图片描述
如果配置 full-compaction.delta-commits = 2 ，意思就是说，在流式处理场景中checkpoint2次，产生2个snapshot后才会生成一个changelog

在批处理场景下，一次sql就会产生一个check

流式写入验证（1）

CREATE TEMPORARY TABLE t_auto_generated_data (
      age BIGINT,
      money BIGINT,
      hh STRING,
      PRIMARY KEY (hh) NOT ENFORCED
) WITH (
    'connector' = 'datagen', -- 使用datagen连接器自动生成数据
    'fields.age.kind' = 'random', -- age字段生成随机数
    'fields.age.min' = '1', -- age字段最小值
    'fields.age.max' = '100', -- age字段最大值
    'fields.money.kind' = 'random', -- money字段生成随机数
    'fields.money.min' = '0', -- money字段最小值
    'fields.money.max' = '10000', -- money字段最大值
    'fields.hh.kind' = 'random', -- hh字段生成随机字符串
    'fields.hh.length' = '10' -- hh字段长度
);
-- 设置checkpoint的间隔60s
SET 'execution.checkpointing.interval'='60 s';
-- 流式写入
insert into t_changelog_fullcompaction select * from t_auto_generated_data;

过一段时间后，我们查看catalog目录，观察changelog产生的时间，1分钟一个和checkpoint的间隔是一样的，现在的现象和lookup是一样的，一次checkpoint产生一个changelog
root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_fullcompaction/bucket-0# ll
total 66904
-rw-r–r-- 1 root root 335296 Nov 28 10:04 changelog-3b6403dd-f6a3-4492-b376-9d6ecadc97e1-0.parquet
-rw-r–r-- 1 root root 9580478 Nov 28 10:05 changelog-3b6403dd-f6a3-4492-b376-9d6ecadc97e1-2.parquet
-rw-r–r-- 1 root root 9581448 Nov 28 10:06 changelog-3b6403dd-f6a3-4492-b376-9d6ecadc97e1-4.parquet
-rw-r–r-- 1 root root 335296 Nov 28 10:04 data-3a8b0d35-34db-4aca-81de-68dea000a669-0.parquet
-rw-r–r-- 1 root root 9580478 Nov 28 10:05 data-3a8b0d35-34db-4aca-81de-68dea000a669-1.parquet
-rw-r–r-- 1 root root 9581448 Nov 28 10:06 data-3a8b0d35-34db-4aca-81de-68dea000a669-2.parquet
-rw-r–r-- 1 root root 10026806 Nov 28 10:05 data-3b6403dd-f6a3-4492-b376-9d6ecadc97e1-1.parquet
-rw-r–r-- 1 root root 19477692 Nov 28 10:06 data-3b6403dd-f6a3-4492-b376-9d6ecadc97e1-3.parquet

流式写入验证（2）

加上full-compaction.delta-commits = 2参数，看看changelog产生的变化情况

drop table if exists t_changelog_fullcompaction2;
 
CREATE TABLE t_changelog_fullcompaction2(
      age BIGINT,
      money BIGINT,
      hh STRING,
      PRIMARY KEY (hh) NOT ENFORCED
)WITH (
    'merge-engine' = 'deduplicate',
    'changelog-producer' = 'full-compaction',
    'full-compaction.delta-commits' = '2'
);

-- 设置checkpoint的间隔60s
SET 'execution.checkpointing.interval'='60 s';
-- 流式写入
insert into t_changelog_fullcompaction2 select * from t_auto_generated_data;

过一段时间后，我们查看catalog目录，观察changelog产生的时间，2分钟一个，就是根据我们的full-compaction.delta-commits参数*checkpoint间隔，也就是n次checkpoint产生一个changelog
不是根据时间间隔，而是根据checkpoint触发次数，这点在批写的时候会有体现

root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_fullcompaction2/bucket-0# ll
total 131168
-rw-r–r-- 1 root root 10024339 Nov 28 10:16 changelog-99b10288-0cd7-471e-8afd-075620279701-1.parquet
-rw-r–r-- 1 root root 18879457 Nov 28 10:18 changelog-99b10288-0cd7-471e-8afd-075620279701-3.parquet
-rw-r–r-- 1 root root 2945606 Nov 28 10:20 changelog-99b10288-0cd7-471e-8afd-075620279701-5.parquet
-rw-r–r-- 1 root root 10024339 Nov 28 10:16 data-99b10288-0cd7-471e-8afd-075620279701-0.parquet
-rw-r–r-- 1 root root 28811744 Nov 28 10:18 data-99b10288-0cd7-471e-8afd-075620279701-2.parquet
-rw-r–r-- 1 root root 31599979 Nov 28 10:20 data-99b10288-0cd7-471e-8afd-075620279701-4.parquet
-rw-r–r-- 1 root root 335703 Nov 28 10:15 data-d3f11150-7e72-4cb6-addf-7079367bea42-0.parquet
-rw-r–r-- 1 root root 9575206 Nov 28 10:16 data-d3f11150-7e72-4cb6-addf-7079367bea42-1.parquet
-rw-r–r-- 1 root root 9568870 Nov 28 10:17 data-d3f11150-7e72-4cb6-addf-7079367bea42-2.parquet
-rw-r–r-- 1 root root 9575911 Nov 28 10:18 data-d3f11150-7e72-4cb6-addf-7079367bea42-3.parquet
-rw-r–r-- 1 root root 2941759 Nov 28 10:19 data-d3f11150-7e72-4cb6-addf-7079367bea42-4.parquet
-rw-r–r-- 1 root root 5890 Nov 28 10:20 data-d3f11150-7e72-4cb6-addf-7079367bea42-5.parquet

当不设置delta-commits参数时，样子好像和lookup没有什么差别，因此如果要用full-compaction时，必须要加上delta-commits参数，来控制compaction的触发间隔。

lookup模式每次checkpoint都会进行一次compaction，数据延迟较小，但是资源消耗大，如果你不在乎数据延迟，那么你可以使用full-compaction模式，将若干次的checkpoint攒到一起，然后统一执行一次compaction，这样能减少资源消耗，但是会增大数据延迟

批处理写入验证

批处理每次写入都会触发一次checkpoint，那么在full-compaction下，如果配置了 ‘full-compaction.delta-commits’ = ‘2’，会有什么效果？

三次写入后，产生了4个changelog，原因就是我们配置了2次checkpoint产生一次compaction，在第三次时，发现前边已经完成了两次checkpoint，因此要进行一次compaction，然后还有第三次本身的数据，一共4个changelog，这个简单理解就行，没有人用full-compaction模式的表进行批写
root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_fullcompaction2/bucket-0# ll
total 40
-rw-r–r-- 1 root root 1217 Nov 28 10:39 changelog-01040eb2-9c68-45b7-b04c-00bd3f4b8c45-0.parquet
-rw-r–r-- 1 root root 1362 Nov 28 10:40 changelog-2ed968c6-d7c3-47c7-9416-00ad010ef7d0-1.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:39 changelog-30c7d2fe-942b-42bd-884f-c2ccf4c6005d-0.parquet
-rw-r–r-- 1 root root 1362 Nov 28 10:39 changelog-4a1f24c6-8b9c-455b-b153-cd5688b3e9f4-1.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:39 data-243a924d-b38f-4a8c-9704-bccbbc63a3dd-0.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:40 data-2ed968c6-d7c3-47c7-9416-00ad010ef7d0-0.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:39 data-2facc877-fd84-4717-b10f-28187bcca435-0.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:39 data-4a1f24c6-8b9c-455b-b153-cd5688b3e9f4-0.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:40 data-82c7c2f9-03b2-4aea-83ae-b0dc28a7427e-0.parquet
-rw-r–r-- 1 root root 1217 Nov 28 10:39 data-fa4c9a01-13e0-46f3-be45-c15f34577282-0.parquet

结论

  • changelog=full-compaction模式相比于lookup模式区别在于changelog的生成时间
    • lookup模式：一次checkpoint产生一次changelog，数据延迟小，资源消耗大
    • full-compaction模式：n次checkpoint产生一次changelog，数据延迟大，资源消耗小

应用场景

  • 非cdc采集的表（不能完整的提供数据变化流）
  • and
  • 后期要进行流式处理的表
  • and
  • 不在乎数据延迟的场景
paimon0.9 主键表的之 changelog producer 笔记
yy的博客
09-27 509
paimon解决-U的的方式是增加normalize算子,存储老数据再state中,比对后可补齐-U,所以成本高 可配置 scan.remove-normalize 取消,同时导致没-U。如果没关闭normalize算子,先发-U(小王,18,100) 再发+U(小王,18,300) 那么结果就是 18,(103-100+300)=303 这才是正确值.normalize算子开启(flink state存老数据 注意ttl要永久,否则部分-U也会丢): sink: +I -U +U -D。
paimon实战 -- Changelog Producer到底有什么用？
阿华田的博客
10-31 1603
其实是不适用的, 上面我们提到 None 模式的流读其实就是读取 L0的文件, 那么我们只要看 L0的文件是否包含 Key 的变更记录. 因为 write buffer 会有合并的逻辑, 所以, 对于 CDC 的数据, L0中可能会是已经在内存合并后的数据. 比如同一个 key 的-U 和+U 消息, 同时写入, 那么在 writer buffer 写入的时候就已经只保留+U 消息了, 所以 None 模式中 L0文件中的数据, 可能已经是合并后的数据, 对于 CDC 的数据也不适用.
paimon的四种changelog模式（3）-lookup模式
javaMylife的博客
11-27 1472
# 结论 - changelog=lookup的情况下，一次操作产生两个个data文件的同时（第一次只会产生一个），也会产生一个changelog文件 - changelog文件内容，会查询变化前的数据，并对比变化后数据，自动生成一份chagelog。`相比input模式，这就是lookup的最大区别，他会自己产生正确的changelog，而不管你的输入数据是否符合规范` - lookup模式针对于不是cdc采集的表，而且要用于流式处理的表 # 应用场景 - 非cdc采集的表 - and - 后期要进行流式
3 Paimon数据湖中的表类型详解_paimon表和hive区别
2401_84164672的博客
04-26 960
-- /*+ OPTIONS(‘scan.mode’=‘from-snapshot’,‘scan.snapshot-id’ = ‘1’) */ – 通过动态表选项来指定数据读取(扫描)模式，以及从哪里开始读取。|-- /*+ OPTIONS(‘scan.mode’=‘from-snapshot’,‘scan.snapshot-id’ = ‘1’) */ – 通过动态表选项来指定数据读取(扫描)模式，以及从哪里开始读取。
Paimon Changelog 深度解析：一本永不丢失的“交易流水账”
最新发布
HANG.NIAN
09-24 1188
想象一下你的银行账户。你关心的不仅仅是当前还剩多少钱（最新状态），更关心每一笔交易记录：什么时间存了多少钱，又在什么时间取了多少钱。当前余额：就像数据表的最新状态交易流水：就是数据表的变更日志在 Paimon 中，Changelog 就是这样一本“交易流水账”，它精确地记录了表中的数据是如何变化的：哪些行是新插入的 (+I)，哪些行被删除了 (-D)，哪些行被更新了（体现为先删除旧值-U，再插入新值+U为什么重要？流式读取 (CDC)
flink+paimon的changelog-producer none、input、lookup、full compaction 区别
sinat_35197112的博客
09-03 388
flink+paimon 的changlog产生机制
理解 Paimon changelog producer
dsgdauigfs的博客
12-18 1721
Chaneglog producer 的主要目的是为了在 Paimon 表上产生流读的 changelog, 所以如果只是批读的表是可以不用设置 Chaneglog producer 的.一般对于数据库如 MySQL 来说, 当执行的语句涉及数据的修改例如插入、更新、删除时，MySQL 会将这些数据变动记录在 binlog 中。相当于额外记录一份操作日志, 类似于 Paimon 中的 input changelog producer 的模式。
Paimon教程
Cool_Pepsi的博客
01-21 2577
Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，推出新一代的 Streaming Lakehouse 技术，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。Flink 社区内部孵化了Flink Table Store (简称 FTS)子项目，一个真正面向 Streaming 以及 Realtime的数据湖存储项目。
对Paimon的理解
hbuzhuhaoju的博客
11-18 1233
机制实现数据版本管理和并行处理，同时避免了因版本控制而引入过多的存储开销。这些机制并不复制数据，而是通过。是Paimon的重要特性，Paimon通过。离线数仓数据备份的成本就大大减少了。，并不会导致显著的存储开销增长。，有效地优化了存储使用。来管理数据版本，配合后台的。
Flink + Paimon 数据 CDC 入湖最佳实践
微信搜：import_bigdata，大数据领域硬核原创作者
11-28 2436
前言Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture)数据的入湖，看完这篇文章，你可以了解到：为什么从 CDC 入 Hive 迁移到 Paimon？CDC 入 Paimon 怎么样做到成本最低？Paimon 对比 Hudi 有什么性能优势？Paimon 从 CDC 入湖场景出发，希望提供给你简单、低成本、低延时的一键入湖。本文基于 Paimo...
paimon实战-- paimon表类型和数据合并方式
阿华田的博客
08-22 2151
Paimon仅支持主键表和Append Only表。由于主键表需要按照主键更新，且要满足各种场景的数据更新，因此针对主键表piamon又提供的表的数据合并引擎。Paimon主键表创建Paimon表时指定了主键（primary key），则该表即为Paimon主键表。语法结构例如，创建一张分区键为dt，主键为dt、shop_id和user_id，分桶数固定为4的Paimon主键表。dt STRING,Paimon主键表中每行数据的主键值各不相同，如果将多条具有相同主键的数据写入Paimon主键表，将根据。
【Apache Paimon】-- 2 -- 核心特性 （0.9.0）
欢迎来到我的博客，一起探索代码里的世界！
11-18 1053
用户可以随心所欲地更新记录。复制以保留最后一行，或部分更新，或汇总记录，或第一行，提供了很灵活的处理方式，总之可以用户自己决定。主键表合并机制详情（1）去重（Deduplicate）去重机制（deduplicate）是默认的数据合并机制。对于多条具有相同primary key的数据，Paimon结果表仅会保留最新一条数据，并丢弃其它具有primary key的数据。说明如果最新一条数据是一条delete消息，所有具有该primary key的数据都将被丢弃。
paimon实战 -- 数据写入和更新底层数据流转解读
阿华田的博客
12-11 1538
manifest-list-4ccc-c07f-4090-958c-cfe3ce3889e5-1 是增量清单列表（上图中的 manifest-list-1-delta），它包含一组对数据文件进行操作的清单条目，在此情形下指的是 manifest-1-0。manifest-list-4ccc-c07f-4090-958c-cfe3ce3889e5-0 是基础清单列表（上图中的 manifest-list-1-base），实际上是空的。小文件的数量会随着快照的增加而增多，这可能会导致读取性能下降。
3 Paimon数据湖中的表类型详解
大数据技术博客
11-08 7228
Paimon中支持多种表类型，从全局维度来看，Paimon中的表类型可以大致划分为4种： 内部表、外部表、分区表和临时表。从存储维度来看，Paimon中的表可以分为两种：Primary Key表，也可以称之为主键表。Append Only表，也可以称之为仅追加表。
Flink CDC 2.2.0同步Mysql数据到Hudi数据湖表实践
微信搜：import_bigdata，大数据领域硬核原创作者
10-08 1965
全网最全大数据面试提升手册！目录介绍Deserialization序列化和反序列化添加Flink CDC依赖3.1 sql-client3.2 Java/Scala API使用SQL方式同步Mysql数据到Hudi数据湖4.1 Mysql表结构和数据4.2 Flink开启checkpoint4.3 在Flink中创建Mysql的映射表4.4 在Flink中创建Hudi Sink的映射表4.5 流式...
Apache Paimon生产环境表模式最佳实践
微信搜：import_bigdata，大数据领域硬核原创作者
02-18 1584
01前言Apache Paimon 作为数据湖对各种场景有着完整的功能支持，看完这篇文章，你可以了解到 Paimon 有哪几种表模式。对应哪些场景。此文部分内容来自 Paimon 官网：https://paimon.apache.org/docs/master/02概览上图描述了大致所有表模式的配置及能力，在下文中，会逐个简单介绍下。以上的所有表模式在最新版本中已得到生产验证。03主键表主键表是 ...
Paimon实战 -- paimon原理解析
阿华田的博客
08-16 3741
Apache Paimon 原名 Flink Table Store，2022年1月在 Apache Flink 社区从零开始研发，Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。
paimon的四种changelog模式（1）-input模式
javaMylife的博客
11-27 1122
# 结论 - changelog=input的情况下，一次操作产生一个data文件的同时，也会产生一个changelog文件 - changelog文件内容和data文件内容完全一致 - input 情况下，如果你的操作不完整，那么流式读取的结果也是不对的 - 上述操作insert2次相同主键，按照主键表的逻辑，应该是会出现-D +I 或者 -U +U 的场景，但是由于input模式，不会额外的处理changelog，你insert两次，我的changelog就写两次insert，你流式读取，那我就重
Apache Paimon系列之：认识Paimon
zhengzaifeidelushang的博客
03-13 2268
对于任意两个同时修改表的写入者，只要他们不修改同一分区，他们的提交就可以并行发生。一张表的所有文件都存储在一个基本目录下。从快照文件开始，Paimon 读者可以递归地访问表中的所有记录。生态系统：除了Apache Flink之外，Paimon还支持Apache Hive、Apache Spark、Trino等其他计算引擎的读取。用户可以通过最新的快照来访问表的最新数据。通过时间旅行，用户还可以通过较早的快照访问表的先前状态。清单文件是包含有关 LSM 数据文件和更改日志文件的更改的文件。
flink源表如下：with('connector'='paimon', 'changelog-producer' = 'lookup' )如何设计物化表才能避免出现2025-07-31 09:33:14 java.io.IOException: java.lang.IllegalStateException: Append only writer can not accept row with RowKind DELETE
08-01
4. Paimon 的 `changelog-producer` 参数不同取值（`none`, `input`, `lookup`, `full-compaction`）有何区别？</think>### 解决 Flink 物化表写入 Paimon 时出现 "Append only writer" 错误 #### 问题根源分析 当...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值