flink1.11的cdc功能对消息顺序性的处理

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

flink1.11的cdc功能对消息顺序性的处理

18392099563
hi everyone,
麻烦请教下各位大神,flink如何处理如下问题:
flink1.11引入cdc,可以解析canal和debezuim发送的CDC数据,其中canal一般是可以指定某些字段作为key进行hash分区发送到同一topic下的不同分区的。
如果源端短时间对pk值进行多次update,则有可能导致发往不同分区,从而无法保证顺序性。
假如
1.有源表和目标表:
create table test(
id int(10) primary key
)
2.源表的增量数据通过canal发往kafka,目标表接收kafka消息进行同步。
3.发往的topic下有三个partition:p0、p1、p2
4.源端和目标端都有一条记录id=1

此时对源端进行两次update:
update1:update test set id=2 where id=1;
update2: update test set id=3 wehre id=2;
假如两条消息都在同一批message中发往kafka,其中update1发送到p1,pudate2发送到p2,这两条消息的顺序性是无法保证的,假如update2先到达,则目标端最终结果为id=2,与源端结果id=3不一致。





--
Sent from: http://apache-flink.147419.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re:flink1.11的cdc功能对消息顺序性的处理

hailongwang
Hi,
 
可以看下 Jark 的 《基于 Flink SQL CDC 的实时数据同步方案》文章 [1]. 其中在最后的 Q&A 中描述了
"首先需要 kafka 在分区中保证有序,同一个 key 的变更数据需要打入到同一个 kafka 的分区里面,这样 flink 读取的时候才能保证顺序。"


个人认为,需要 Update 的 key 可以更 canal 采集到 kakfa 的 hash key 一致,这样就保证了有序?


[1] https://mp.weixin.qq.com/s/QNJlacBUlkMT7ksKKSNa5Q


Best,
Hailong Wang





在 2020-11-05 15:35:55,"18392099563" <[hidden email]> 写道:

>hi everyone,
>麻烦请教下各位大神,flink如何处理如下问题:
>flink1.11引入cdc,可以解析canal和debezuim发送的CDC数据,其中canal一般是可以指定某些字段作为key进行hash分区发送到同一topic下的不同分区的。
>如果源端短时间对pk值进行多次update,则有可能导致发往不同分区,从而无法保证顺序性。
>假如
>1.有源表和目标表:
>create table test(
>id int(10) primary key
>)
>2.源表的增量数据通过canal发往kafka,目标表接收kafka消息进行同步。
>3.发往的topic下有三个partition:p0、p1、p2
>4.源端和目标端都有一条记录id=1
>
>此时对源端进行两次update:
>update1:update test set id=2 where id=1;
>update2: update test set id=3 wehre id=2;
>假如两条消息都在同一批message中发往kafka,其中update1发送到p1,pudate2发送到p2,这两条消息的顺序性是无法保证的,假如update2先到达,则目标端最终结果为id=2,与源端结果id=3不一致。
>
>
>
>
>
>--
>Sent from: http://apache-flink.147419.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: flink1.11的cdc功能对消息顺序性的处理

Jark
Administrator
我理解你说的是对 pk 的更新的场景。

比如一张 user 表,有[user_id, user_name] 2个字段,
假设有 "101, Tim" 记录 做了两次更新
update1:update test set id=102 where id=101;
update2: update test set id=103 wehre id=102;

针对这种场景 debezium 是会把这种针对 pk的更新拆成一条 delete 和一条 insert,而不是 update 消息。

所以 update1 语句产生了:
DELETE(101,Timo) 发到了p1
INSERT(102,Tim) 发到了 p2

update2 语句产生了:
DELETE(102, Tim) 发到了 p2
INSERT(103, Tim) 发到了 p3

所以 flink 去对接这个数据的时候,仍然能够最终数据是 (103, Tim), 因为 102 的两条数据,INSERT, DELETE
仍然是有序的。

所以如果 canal 对于 pk 更新也是同样的策略,那么也是一样的。 但我不确定 canal 是怎么处理 pk 更新的,这个需要调研下。

Best,
Jark

On Thu, 5 Nov 2020 at 21:05, hailongwang <[hidden email]> wrote:

> Hi,
>
> 可以看下 Jark 的 《基于 Flink SQL CDC 的实时数据同步方案》文章 [1]. 其中在最后的 Q&A 中描述了
> "首先需要 kafka 在分区中保证有序,同一个 key 的变更数据需要打入到同一个 kafka 的分区里面,这样 flink
> 读取的时候才能保证顺序。"
>
>
> 个人认为,需要 Update 的 key 可以更 canal 采集到 kakfa 的 hash key 一致,这样就保证了有序?
>
>
> [1] https://mp.weixin.qq.com/s/QNJlacBUlkMT7ksKKSNa5Q
>
>
> Best,
> Hailong Wang
>
>
>
>
>
> 在 2020-11-05 15:35:55,"18392099563" <[hidden email]> 写道:
> >hi everyone,
> >麻烦请教下各位大神,flink如何处理如下问题:
>
> >flink1.11引入cdc,可以解析canal和debezuim发送的CDC数据,其中canal一般是可以指定某些字段作为key进行hash分区发送到同一topic下的不同分区的。
> >如果源端短时间对pk值进行多次update,则有可能导致发往不同分区,从而无法保证顺序性。
> >假如
> >1.有源表和目标表:
> >create table test(
> >id int(10) primary key
> >)
> >2.源表的增量数据通过canal发往kafka,目标表接收kafka消息进行同步。
> >3.发往的topic下有三个partition:p0、p1、p2
> >4.源端和目标端都有一条记录id=1
> >
> >此时对源端进行两次update:
> >update1:update test set id=2 where id=1;
> >update2: update test set id=3 wehre id=2;
>
> >假如两条消息都在同一批message中发往kafka,其中update1发送到p1,pudate2发送到p2,这两条消息的顺序性是无法保证的,假如update2先到达,则目标端最终结果为id=2,与源端结果id=3不一致。
> >
> >
> >
> >
> >
> >--
> >Sent from: http://apache-flink.147419.n8.nabble.com/
>
Reply | Threaded
Open this post in threaded view
|

回复: flink1.11的cdc功能对消息顺序性的处理

史 正超
Canal可以配置分区策略:配置保证相同id的记录都发到同一个分区,比如 `db.table1:id`
这样就保证了数据的有序。

发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用

发件人: Jark Wu<mailto:[hidden email]>
发送时间: 2020年11月5日 21:28
收件人: user-zh<mailto:[hidden email]>
主题: Re: flink1.11的cdc功能对消息顺序性的处理

我理解你说的是对 pk 的更新的场景。

比如一张 user 表,有[user_id, user_name] 2个字段,
假设有 "101, Tim" 记录 做了两次更新
update1:update test set id=102 where id=101;
update2: update test set id=103 wehre id=102;

针对这种场景 debezium 是会把这种针对 pk的更新拆成一条 delete 和一条 insert,而不是 update 消息。

所以 update1 语句产生了:
DELETE(101,Timo) 发到了p1
INSERT(102,Tim) 发到了 p2

update2 语句产生了:
DELETE(102, Tim) 发到了 p2
INSERT(103, Tim) 发到了 p3

所以 flink 去对接这个数据的时候,仍然能够最终数据是 (103, Tim), 因为 102 的两条数据,INSERT, DELETE
仍然是有序的。

所以如果 canal 对于 pk 更新也是同样的策略,那么也是一样的。 但我不确定 canal 是怎么处理 pk 更新的,这个需要调研下。

Best,
Jark

On Thu, 5 Nov 2020 at 21:05, hailongwang <[hidden email]> wrote:

> Hi,
>
> 可以看下 Jark 的 《基于 Flink SQL CDC 的实时数据同步方案》文章 [1]. 其中在最后的 Q&A 中描述了
> "首先需要 kafka 在分区中保证有序,同一个 key 的变更数据需要打入到同一个 kafka 的分区里面,这样 flink
> 读取的时候才能保证顺序。"
>
>
> 个人认为,需要 Update 的 key 可以更 canal 采集到 kakfa 的 hash key 一致,这样就保证了有序?
>
>
> [1] https://mp.weixin.qq.com/s/QNJlacBUlkMT7ksKKSNa5Q
>
>
> Best,
> Hailong Wang
>
>
>
>
>
> 在 2020-11-05 15:35:55,"18392099563" <[hidden email]> 写道:
> >hi everyone,
> >麻烦请教下各位大神,flink如何处理如下问题:
>
> >flink1.11引入cdc,可以解析canal和debezuim发送的CDC数据,其中canal一般是可以指定某些字段作为key进行hash分区发送到同一topic下的不同分区的。
> >如果源端短时间对pk值进行多次update,则有可能导致发往不同分区,从而无法保证顺序性。
> >假如
> >1.有源表和目标表:
> >create table test(
> >id int(10) primary key
> >)
> >2.源表的增量数据通过canal发往kafka,目标表接收kafka消息进行同步。
> >3.发往的topic下有三个partition:p0、p1、p2
> >4.源端和目标端都有一条记录id=1
> >
> >此时对源端进行两次update:
> >update1:update test set id=2 where id=1;
> >update2: update test set id=3 wehre id=2;
>
> >假如两条消息都在同一批message中发往kafka,其中update1发送到p1,pudate2发送到p2,这两条消息的顺序性是无法保证的,假如update2先到达,则目标端最终结果为id=2,与源端结果id=3不一致。
> >
> >
> >
> >
> >
> >--
> >Sent from: http://apache-flink.147419.n8.nabble.com/
>