You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by 18392099563 <18...@163.com> on 2020/11/05 08:35:55 UTC
flink1.11的cdc功能对消息顺序性的处理
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/
回复: flink1.11的cdc功能对消息顺序性的处理
Posted by 史 正超 <sh...@outlook.com>.
Canal可以配置分区策略：配置保证相同id的记录都发到同一个分区，比如 `db.table1:id`
这样就保证了数据的有序。
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
发件人: Jark Wu<ma...@gmail.com>
发送时间: 2020年11月5日 21:28
收件人: user-zh<ma...@flink.apache.org>
主题: 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 <18...@163.com> 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" <18...@163.com> 写道：
> >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/
>
Re: flink1.11的cdc功能对消息顺序性的处理
Posted by Jark Wu <im...@gmail.com>.
我理解你说的是对 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 <18...@163.com> 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" <18...@163.com> 写道：
> >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/
>
Re:flink1.11的cdc功能对消息顺序性的处理
Posted by hailongwang <18...@163.com>.
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" <18...@163.com> 写道：
>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/