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 Jark Wu <im...@gmail.com> on 2020/03/11 06:56:36 UTC
[SURVEY] 您在使用什么数据变更同步工具(CDC)？
Hi, 大家好，
Flink 社区目前正在对接一些 CDC (Change Data Capture) 工具，以期在下个版本能支持读取和处理常见的 binlog
数据，所以需要调研下大家目前主要使用的 CDC 工具是什么。
欢迎大家填下问卷调查，您的反馈对我们非常重要，谢谢！
http://apacheflink.mikecrm.com/wDivVQ1
也欢迎大家在这个邮件下讨论关于 Flink 对接 CDC 的一些想法、需求、期望。
Best,
Jark
Re: [SURVEY] 您在使用什么数据变更同步工具(CDC)？
Posted by Jark Wu <im...@gmail.com>.
Hi 大家好,
非常感谢大家的反馈！我想与大家分享下调查问卷的结果。我在中英文邮件列表分别发了中英文的调查问卷，调查结果差异较大，很有意思。
*英文问卷*
- Top3 CDC tools: Debezium (66.7%), Oracle GoldenGate (15.6%), Maxwell
(13.3%)
- Top3 databases: PostgresSQL(52.3%), MySQL (50%), MS SQL Server (34.1%)
*中文问卷*
- Top3 CDC tools: Canal (70.7%), Debezium (26.8%), Maxwell (23.2%)
- Top3 databases: MySQL (85.4%), Oracle (13.4%) PostgresSQL (12.2%)
百分比 = 投票数/投票人数。
这份调查报告对于 Flink 社区支持 CDC 的规划非常有帮助，再次感谢大家的参与！
Best,
Jark
On Thu, 12 Mar 2020 at 10:22, Jark Wu <im...@gmail.com> wrote:
> Hi Benchao,
>
> Great feedbacks!
>
> 1) 全量初始化能力：
> 第一版中社区有计划引入 flink sql 直连 mysql 获取 binlog 的方案，该方案可以获取全量+增量 binlog，且有一致性保证。
> 但是对接db 全量+ mq binlog，将会是未来的一个工作，主要的难点在于全量如何平滑切换到 增量的 mq offset 上。
>
> 2) 自动生成watermark:
> 这也是 roadmap 上的一个工作。
>
> 3) binlog以state的形式存储，只需全量加载，后续只接受增量：
> 我理解这个和 (1) 是类似的需求。Flink SQL 对接之后 binlog，也即 binlog 数据流转成了一个动态表，也即 Flink
> 在维护这个动态表的数据（state）。
>
> 4) Schema 变更：
> 这会是生产中非常有用的一个特性。但是目前还没有很清楚的方案。
>
> 5) flink作为一个数据同步工具：
> 这是非常有可能的。基于 Flink 直连 db binlog 的能力，我们可以非常方便地基于该能力搭建出一个同步工具（类似 canal），基于
> flink sql 丰富的生态，
> 可以快速对接各种 connector。这也许将来会成为一个三方库。
>
> Best,
> Jark
>
>
>
>
> On Wed, 11 Mar 2020 at 23:52, Benchao Li <li...@gmail.com> wrote:
>
>> Hi，
>>
>> 感谢Jark发起这个话题的讨论，这个功能对于Flink SQL来讲是一个非常重要的扩展。
>>
>> 问卷已填，再此再提几个小想法：
>> 1. 希望对接binlog时可以有全量初始化的能力，这样在Flink中我们就有了一个全表的实时状态，方便其他表与之进行join。
>> 2. 希望能够自动生成watermark，这样子可以尽可能的减少接入成本。因为有些场景是其他的append
>> log数据可以跟实时维护的表进行join；也有些场景是两个binlog形成的动态表互相join。
>> 3. 希望可以把binlog以state的形式存储在flink里，除了第一次启动需要全量加载，后续的运维都可以再此基础上只接收增量即可。
>> 4. 如此之外，如果能有schema变更感知能力是最好的。（当然这个可能很难体现在SQL里面，毕竟SQL作业在启动时就已经确定了table
>> 的schema）
>> 5.
>>
>> 最后一点，感觉不太符合flink现在的定位，但是可能会有用户会这样来使用。就是直接把flink作为一个数据同步工具，消费binlog，直接同步到其他存储里面。（可能基本不需要做任何加工的那种，而且最好是能够有自动感知schema变更，同时可以变更下游的存储系统的schema）
>>
>> Jark Wu <im...@gmail.com> 于2020年3月11日周三 下午3:00写道：
>>
>> > Hi, 大家好，
>> >
>> > Flink 社区目前正在对接一些 CDC (Change Data Capture) 工具，以期在下个版本能支持读取和处理常见的 binlog
>> > 数据，所以需要调研下大家目前主要使用的 CDC 工具是什么。
>> >
>> > 欢迎大家填下问卷调查，您的反馈对我们非常重要，谢谢！
>> >
>> > http://apacheflink.mikecrm.com/wDivVQ1
>> >
>> > 也欢迎大家在这个邮件下讨论关于 Flink 对接 CDC 的一些想法、需求、期望。
>> >
>> > Best,
>> > Jark
>> >
>>
>>
>> --
>>
>> Benchao Li
>> School of Electronics Engineering and Computer Science, Peking University
>> Tel:+86-15650713730
>> Email: libenchao@gmail.com; libenchao@pku.edu.cn
>>
>
Re: [SURVEY] 您在使用什么数据变更同步工具(CDC)？
Posted by Jark Wu <im...@gmail.com>.
Hi Benchao,
Great feedbacks!
1) 全量初始化能力：
第一版中社区有计划引入 flink sql 直连 mysql 获取 binlog 的方案，该方案可以获取全量+增量 binlog，且有一致性保证。
但是对接db 全量+ mq binlog，将会是未来的一个工作，主要的难点在于全量如何平滑切换到 增量的 mq offset 上。
2) 自动生成watermark:
这也是 roadmap 上的一个工作。
3) binlog以state的形式存储，只需全量加载，后续只接受增量：
我理解这个和 (1) 是类似的需求。Flink SQL 对接之后 binlog，也即 binlog 数据流转成了一个动态表，也即 Flink
在维护这个动态表的数据（state）。
4) Schema 变更：
这会是生产中非常有用的一个特性。但是目前还没有很清楚的方案。
5) flink作为一个数据同步工具：
这是非常有可能的。基于 Flink 直连 db binlog 的能力，我们可以非常方便地基于该能力搭建出一个同步工具（类似 canal），基于
flink sql 丰富的生态，
可以快速对接各种 connector。这也许将来会成为一个三方库。
Best,
Jark
On Wed, 11 Mar 2020 at 23:52, Benchao Li <li...@gmail.com> wrote:
> Hi，
>
> 感谢Jark发起这个话题的讨论，这个功能对于Flink SQL来讲是一个非常重要的扩展。
>
> 问卷已填，再此再提几个小想法：
> 1. 希望对接binlog时可以有全量初始化的能力，这样在Flink中我们就有了一个全表的实时状态，方便其他表与之进行join。
> 2. 希望能够自动生成watermark，这样子可以尽可能的减少接入成本。因为有些场景是其他的append
> log数据可以跟实时维护的表进行join；也有些场景是两个binlog形成的动态表互相join。
> 3. 希望可以把binlog以state的形式存储在flink里，除了第一次启动需要全量加载，后续的运维都可以再此基础上只接收增量即可。
> 4. 如此之外，如果能有schema变更感知能力是最好的。（当然这个可能很难体现在SQL里面，毕竟SQL作业在启动时就已经确定了table
> 的schema）
> 5.
>
> 最后一点，感觉不太符合flink现在的定位，但是可能会有用户会这样来使用。就是直接把flink作为一个数据同步工具，消费binlog，直接同步到其他存储里面。（可能基本不需要做任何加工的那种，而且最好是能够有自动感知schema变更，同时可以变更下游的存储系统的schema）
>
> Jark Wu <im...@gmail.com> 于2020年3月11日周三 下午3:00写道：
>
> > Hi, 大家好，
> >
> > Flink 社区目前正在对接一些 CDC (Change Data Capture) 工具，以期在下个版本能支持读取和处理常见的 binlog
> > 数据，所以需要调研下大家目前主要使用的 CDC 工具是什么。
> >
> > 欢迎大家填下问卷调查，您的反馈对我们非常重要，谢谢！
> >
> > http://apacheflink.mikecrm.com/wDivVQ1
> >
> > 也欢迎大家在这个邮件下讨论关于 Flink 对接 CDC 的一些想法、需求、期望。
> >
> > Best,
> > Jark
> >
>
>
> --
>
> Benchao Li
> School of Electronics Engineering and Computer Science, Peking University
> Tel:+86-15650713730
> Email: libenchao@gmail.com; libenchao@pku.edu.cn
>
Re: [SURVEY] 您在使用什么数据变更同步工具(CDC)？
Posted by Benchao Li <li...@gmail.com>.
Hi，
感谢Jark发起这个话题的讨论，这个功能对于Flink SQL来讲是一个非常重要的扩展。
问卷已填，再此再提几个小想法：
1. 希望对接binlog时可以有全量初始化的能力，这样在Flink中我们就有了一个全表的实时状态，方便其他表与之进行join。
2. 希望能够自动生成watermark，这样子可以尽可能的减少接入成本。因为有些场景是其他的append
log数据可以跟实时维护的表进行join；也有些场景是两个binlog形成的动态表互相join。
3. 希望可以把binlog以state的形式存储在flink里，除了第一次启动需要全量加载，后续的运维都可以再此基础上只接收增量即可。
4. 如此之外，如果能有schema变更感知能力是最好的。（当然这个可能很难体现在SQL里面，毕竟SQL作业在启动时就已经确定了table
的schema）
5.
最后一点，感觉不太符合flink现在的定位，但是可能会有用户会这样来使用。就是直接把flink作为一个数据同步工具，消费binlog，直接同步到其他存储里面。（可能基本不需要做任何加工的那种，而且最好是能够有自动感知schema变更，同时可以变更下游的存储系统的schema）
Jark Wu <im...@gmail.com> 于2020年3月11日周三 下午3:00写道：
> Hi, 大家好，
>
> Flink 社区目前正在对接一些 CDC (Change Data Capture) 工具，以期在下个版本能支持读取和处理常见的 binlog
> 数据，所以需要调研下大家目前主要使用的 CDC 工具是什么。
>
> 欢迎大家填下问卷调查，您的反馈对我们非常重要，谢谢！
>
> http://apacheflink.mikecrm.com/wDivVQ1
>
> 也欢迎大家在这个邮件下讨论关于 Flink 对接 CDC 的一些想法、需求、期望。
>
> Best,
> Jark
>
--
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn