jindyliu

> 1. 是的。目前确实有这个问题。也是将来的一个改进方向。 > 2. 支持的。具体可以看 debezium 的文档。 1、、这几天看了下debezium，这个snapshot reader + binlog的切换确实，相比其它cdc工具的一个亮点。目前公司内部的一些cdc 系统（自研）都是增量数据往kafka发送的模式，全量数据基本都是离线导入，kafka offsize按全量导入的时间点往前点开始消费，主要大多数的job场景都只需at_least_once的要求。 2、关于1中的效率问题除了i/o线程不能复用以外，还有体现在dump的效率上；现在debezium mysql connector无法感知后续的任务是什么，debezium都会把表的全量数据导入（写死了为select * from table），对于10亿级的表，有些任务其它加了些字段过滤条件后，大部分可能只有几百w条左右需要全量输入，效率一下可以提升满多的。后续的优化思路上，jark会在这方面做考虑么？ 另外，看过你的一些分享，你概括的几种场景的flink cdc接入方式：你开源的mysql-cdc的方式确实对于没有历史包袱的公司很方便（批流统一起来，还能Exactly-once）；但估计有些公司都已经是用了cdc（平台）+kafka的架构，并运行了较久且有专门人员维护，主要是中间层为做业务上的解藕。像这种cdc平台+kafka的场景，如果要用flink的对接做一些任务，除了去做一个cdc contector（类flink的canal-json 、debezium-json）做格式的适配外，全量数据的导入是个问题；就拿一个实时宽表来看，但历史数据怎么先流入flink并和后续的kafka的结合起来，任务目前语义上可以at_least_once（大不了把kafka offsize往前移多一点，比如半小时）。 关于cdc的历史数据与增量数据的按顺序拼接在一起，不知道jark可以分享flink一些做法和思路吗？ 我目前没找到flink比较好的做法，尝试过往两个思路想： a、历史数据做为一个自定义的stream, 历史数据支持条件过滤（非全表），并将历史数据转成cdc的格式流（都是insert）；增量cdc数据做为别一个stream，但这里flink里没有很好的算子(不知道是不是我没找到)，去协调两个stream的消费顺序，需先装历史数据先消费完再消费kafka数据……（这里先不考虑语义的Exactly-once，先只考虑业务的at_least_once） b、像这个开源的mysql...

> 1. filter&projection pushdown 是后续的优化方向 > 2. 全量数据+增量数据拼接的问题 > > * 如果用的 debezium+kafka，这个问题应该也还好，应为 debezium 支持全量+增量同步到 kafka。 kafka topic 可以开启 compaction 机制，所以 kafka topic 中存了全量+增量的数据，但中间的历史过程会清理，所以存储上一般不是问题。 > * 如果上面存储还是存不下，flink 社区有些公司在尝试多层级存储的机制，即历史数据存在 s3，临近的数据存 kafka。...

> hybrid source 目前社区还没有官方的出来，也还在孵化中，以前我们做过一个基于 FLIP-7 的 POC，不过也只做了一半：https://github.com/wuchong/flink-hackathon > > 这个全量流+增量流的连接，在DataStream 上是可以做的，不过在 SQL 上比较麻烦（没有这种语义的算子）。 1、感谢，flink-hackathon我这边也看看，要消化下，看看思路。是拉hybird-sql-source分支还是master？ 2、我现在能想到的flink + kakfa的架构下的思路，确实只想到先解决DataStream的（历史与增量数据）结合问题，然后在用DataStream看能不能转成table，再在table级别下，去看看能不能直接加载sql语句去处理业务逻辑，没做过从底层，到table，再到sql整个路径上的，不知道可不可行？看看能否解决大部分的sql语句场景。jark这方面有社区的公司尝试过吗？