paimon的四种changelog模式(3)-lookup模式

请先了解input模式和none模式,然后再看lookup模式

环境创建

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

USE CATALOG fs_catalog;

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

paimon的snapshot和checkpoint之间的关系

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

执行一次插入操作

insert into t_changelog_lookup values(10,1000,'1');

root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_lookup/bucket-0# ll
total 8
-rw-r–r-- 1 root root 1217 Nov 27 16:26 changelog-81638785-5ddb-41ba-893d-466b4166374a-0.parquet
-rw-r–r-- 1 root root 1217 Nov 27 16:26 data-f8c4281c-3453-46b2-a881-b893bb4ef0e4-0.parquet

changelog文件
在这里插入图片描述

data文件
在这里插入图片描述

相同主键,再执行一次插入操作

insert into t_changelog_lookup values(10,2000,'1');

root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_lookup/bucket-0# ll
total 20
-rw-r–r-- 1 root root 1362 Nov 27 16:30 changelog-66b5f009-9fed-4221-bf9d-253a5e324ffe-1.parquet
-rw-r–r-- 1 root root 1217 Nov 27 16:26 changelog-81638785-5ddb-41ba-893d-466b4166374a-0.parquet
-rw-r–r-- 1 root root 1217 Nov 27 16:30 data-4ec9395b-0856-4dc6-aac0-d5f3d597c481-0.parquet
-rw-r–r-- 1 root root 1217 Nov 27 16:30 data-66b5f009-9fed-4221-bf9d-253a5e324ffe-0.parquet
-rw-r–r-- 1 root root 1217 Nov 27 16:26 data-f8c4281c-3453-46b2-a881-b893bb4ef0e4-0.parque

changelog文件
lookup模式下changelog文件会先查询变更前的数据,然后和当前操作合并出一个changelog文件来
在这里插入图片描述

data文件

lookup模式下,从第二次写入开始,每次都会产生两个data文件,一个是本次操作数据,一个是本次操作COMPACT完成后的数据
为什么,input、none模式只有2个呢?

root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_lookup/snapshot# ll
total 16
-rw-r–r-- 1 root root 1 Nov 27 16:26 EARLIEST
-rw-r–r-- 1 root root 1 Nov 27 16:31 LATEST
-rw-r–r-- 1 root root 621 Nov 27 16:26 snapshot-1
-rw-r–r-- 1 root root 672 Nov 27 16:26 snapshot-2
-rw-r–r-- 1 root root 621 Nov 27 16:31 snapshot-3
-rw-r–r-- 1 root root 673 Nov 27 16:31 snapshot-4
cat这四个snapshot文件你会,发现执行一次APPEND操作后会执行一次COMPACT(合并)操作
root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_lookup/snapshot# cat snapshot-1
{
“version” : 3,
“id” : 1,

“commitKind” : “APPEND”,

}
root@wsl01:/data/soft/paimon/catalog/default.db/t_changelog_lookup/snapshot# cat snapshot-2
{
“version” : 3,
“id” : 1,

“commitKind” : “COMPACT”,

}
也就是说,lookup模式会在写入完成后,立即执行一次Compaction动作,所以才会产生双份了snapshot,才产生了两个data文件,一个是当前操作,一个是合并后数据

本次操作数据
在这里插入图片描述
本次操作完成后的数据在这里插入图片描述

sqlclient 流式查询

-- Flink SQL
SET 'execution.runtime-mode' = 'streaming';

--设置检查点的间隔为10秒
SET 'execution.checkpointing.interval'='10 s';
set parallelism.default=1;

-- 使用changelog,展示op,操作类型
SET 'sql-client.execution.result-mode'='changelog';

-- 从当前快照开始,读取变化情况 
SELECT * FROM t_changelog_lookup;

在这里插入图片描述

-- 从ID=1的快照开始,读取变化情况 
SELECT * FROM t_changelog_lookup/*+ OPTIONS('scan.snapshot-id' = '1') */;

在这里插入图片描述

sqlclient 批查询

Flink SQL> SET 'sql-client.execution.result-mode'='tableau';
[INFO] Execute statement succeed.

Flink SQL> SET 'execution.runtime-mode' = 'batch';
[INFO] Execute statement succeed.

Flink SQL> SELECT * FROM t_changelog_lookup;
+-----+-------+----+
| age | money | hh |
+-----+-------+----+
|  10 |  2000 |  1 |
+-----+-------+----+
1 row in set

Flink SQL> SELECT * FROM t_changelog_lookup/*+ OPTIONS('scan.snapshot-id' = '1') */;
+-----+-------+----+
| age | money | hh |
+-----+-------+----+
|  10 |  1000 |  1 |
+-----+-------+----+
1 row in set

Flink SQL> SELECT * FROM t_changelog_lookup/*+ OPTIONS('scan.snapshot-id' = '2') */;
+-----+-------+----+
| age | money | hh |
+-----+-------+----+
|  10 |  2000 |  1 |
+-----+-------+----+
1 row in set

结论

  • changelog=lookup的情况下,一次checkpoint,产生两个data文件的同时(第一次只会产生一个),也会产生一个changelog文件
  • changelog文件内容,会查询变化前的数据,并对比变化后数据,自动生成一份chagelog。相比input模式,这就是lookup的最大区别,他会自己产生正确的changelog,而不管你的输入数据是否符合规范
  • lookup模式针对于不是cdc采集的表,而且要用于流式处理的表

应用场景

  • (非cdc采集的表-不能完整的提供数据变化流
  • and
  • 后期要进行流式处理的表
  • and
  • 更在乎数据延迟(见4full-compaction)
  • or
  • 使用了聚合引擎或者写入过程有计算逻辑
  • or
  • 流处理表使用了first-row合并引擎
<think>好的,用户现在问的是关于Apache Paimon中的Changelog Input和Lookup的区别,并且希望有例子说明。我需要先回顾一下之前对话的内容,看看有没有相关的知识点可以借鉴。之前的对话中,用户询问了Flink的Event Time和Processing Time,我详细解释了它们的区别、机制和适用场景,还给出了SQL示例。现在用户转向了Paimon的相关问题,说明他们对流处理和数据湖技术比较感兴趣,可能是在实际项目中遇到了相关需求。 首先,我需要确定用户对Paimon的了解程度。Paimon是一个流式数据湖存储系统,通常与Flink结合使用,支持实时数据更新和查询。Changelog Input和LookupPaimon中的两种数据读取方式,但用户可能不太清楚它们的具体差异和应用场景。需要先明确这两个概念的定义,然后对比它们的区别,再通过例子说明。 接下来,我需要回忆Paimon的文档或相关知识。Changelog Input通常用于处理变更日志流,比如CDC数据,适用于需要实时处理增删改操作的场景,适合流式计算任务。而Lookup则是用于点查,根据键值快速检索当前状态,适用于维表关联或实时查询,比如在流处理中需要关联维度信息时使用。 然后,要考虑用户可能的实际使用场景。比如用户可能在处理订单数据,需要实时更新订单状态(Changelog Input),或者在处理交易流时需要查询用户信息(Lookup)。举这样的例子会更贴近实际应用,帮助用户理解。 需要确认是否有可能混淆的概念。比如Changelog Input是否与流处理中的CDC捕获有关,而Lookup是否类似于数据库的查询操作。另外,要注意用户可能对“输入”和“查询”这两个术语的理解,需要明确它们在Paimon中的具体含义。 还要考虑用户的需求层次。他们可能不仅仅想知道定义,还想了解如何选择使用哪种方式,以及在实际项目中如何应用。因此,在回答中除了区别和例子外,还需要给出选择建议,比如根据数据更新频率、延迟要求等因素来决定。 最后,要检查是否有遗漏的关键点,比如Changelog Input是否支持回放,Lookup的性能如何,或者两者的实现机制有何不同。确保回答全面且准确,避免误导用户。</think>在 Apache Paimon(流式数据湖存储系统)中,**Changelog Input** 和 **Lookup** 是两种不同的数据读取方式,适用于不同的场景和数据处理需求。以下是它们的核心区别和具体示例: --- ### **1. Changelog Input(变更日志输入)** #### **定义** - **Changelog Input** 是一种流式读取数据变更日志(Insert/Update/Delete 操作)的方式,适用于需要实时处理数据变化的场景。 - 它会将 Paimon 表的变更日志(如 CDC 数据)作为流持续输出,类似于 Kafka 中的消息队列。 #### **特点** - **流式消费**:持续读取表的增量变更(`+I`插入、`-U`更新前、`+U`更新后、`-D`删除)。 - **有序性**:保证变更日志的顺序性(基于事件时间或处理时间)。 - **适用场景**: - 实时同步数据到下游系统(如 Elasticsearch、另一个 Paimon 表)。 - 构建实时数仓的增量 ETL。 - 需要处理数据更新的流式计算(如 Flink SQL 实时聚合)。 #### **示例** 假设有一张订单表 `orders`,存储订单状态的变更记录: | 订单ID | 状态 | 更新时间 | 操作类型 | |--------|------------|-------------------|----------| | 1001 | CREATED | 2023-10-01 10:00 | +I | | 1001 | PAID | 2023-10-01 10:05 | +U | | 1001 | SHIPPED | 2023-10-01 10:30 | +U | 通过 `Changelog Input` 读取这张表,会输出以下流式事件: ```plaintext +I(1001, CREATED, 2023-10-01 10:00) -U(1001, CREATED, 2023-10-01 10:00) // 更新前的旧值 +U(1001, PAID, 2023-10-01 10:05) // 更新后的新值 -U(1001, PAID, 2023-10-01 10:05) +U(1001, SHIPPED, 2023-10-01 10:30) ``` --- ### **2. Lookup(点查)** #### **定义** - **Lookup** 是一种基于键(Key)的随机访问方式,用于快速查询当前表的最新状态(即某条记录的当前值)。 - 类似于数据库的 `SELECT ... WHERE id = ?` 查询,返回指定键的当前值。 #### **特点** - **实时性**:直接查询表的最新快照(当前状态)。 - **低延迟**:适合高频、按需的点查请求。 - **适用场景**: - 实时查询某条记录的当前状态(如订单状态、用户信息)。 - 流计算中的维表关联(如 Flink 流 Join 静态维表)。 #### **示例** 继续以订单表 `orders` 为例,表中当前数据为: | 订单ID | 状态 | 更新时间 | |--------|------------|-------------------| | 1001 | SHIPPED | 2023-10-01 10:30 | | 1002 | CREATED | 2023-10-01 11:00 | 通过 `Lookup` 查询订单 ID=1001 的当前状态,直接返回: ```plaintext (1001, SHIPPED, 2023-10-01 10:30) ``` --- ### **3. 核心区别对比** | **特性** | **Changelog Input** | **Lookup** | |-------------------|----------------------------------------|--------------------------------| | **读取方式** | 流式消费增量变更(持续监听变更日志) | 按需查询当前状态(单次请求响应) | | **数据范围** | 所有历史变更记录(包含更新/删除) | 仅最新版本数据 | | **延迟** | 低延迟(近实时) | 极低延迟(毫秒级响应) | | **资源消耗** | 需要维护流式消费的上下文(如 offset) | 无状态,每次查询独立 | | **适用场景** | 增量同步、流式计算 | 实时查询、维表关联 | --- ### **4. 典型场景示例** #### **场景 1:订单状态实时同步** - **Changelog Input**: 监听订单表的变更日志,实时同步到 Elasticsearch。例如,订单状态从 `PAID` 变为 `SHIPPED` 时,下游系统立即更新。 - **Lookup**: 用户在前端查询订单 ID=1001 的当前状态时,直接返回最新结果(`SHIPPED`)。 #### **场景 2:流计算中的维表关联** - **Changelog Input**: 不适合!维表关联需要直接查询当前状态,而非监听变更流。 - **Lookup**: 在 Flink 流处理中,将订单流与用户信息表(存储在 Paimon)通过 `Lookup` 关联,实时补充用户姓名、地址等字段。 --- ### **5. 技术实现(Flink + Paimon)** #### **Changelog Input 代码示例** ```sql -- 创建 Paimon 表(包含变更日志) CREATE TABLE orders ( order_id STRING, status STRING, update_time TIMESTAMP(3), PRIMARY KEY (order_id) NOT ENFORCED ) WITH ( &#39;connector&#39; = &#39;paimon&#39;, &#39;path&#39; = &#39;file:///path/to/orders&#39;, &#39;changelog-producer&#39; = &#39;input&#39; -- 启用变更日志生成 ); -- 流式读取变更日志(Flink SQL) SELECT * FROM orders /*+ OPTIONS(&#39;scan.mode&#39;=&#39;latest&#39;) */; ``` #### **Lookup 代码示例** ```sql -- 创建 Paimon 表(支持 Lookup) CREATE TABLE users ( user_id STRING, name STRING, address STRING, PRIMARY KEY (user_id) NOT ENFORCED ) WITH ( &#39;connector&#39; = &#39;paimon&#39;, &#39;path&#39; = &#39;file:///path/to/users&#39; ); -- 流计算中关联订单流与用户表(Lookup Join) SELECT o.order_id, o.status, u.name, u.address FROM orders_stream AS o JOIN users FOR SYSTEM_TIME AS OF o.proc_time AS u ON o.user_id = u.user_id; ``` --- ### **6. 如何选择?** - **用 Changelog Input**: 需要实时处理数据变更(如同步、聚合、ETL),关注增量更新。 - **用 Lookup**: 需要按需查询最新数据(如 API 查询、流计算维表关联)。 通过合理选择两种模式,可以高效实现流式数据湖的实时处理与查询需求。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值