Jark Wu

@Tan-JiaLiang ， 人工维护也会有问题，容易导致数据不一致。比如加列之后，马上来了一堆新数据，那么这些新数据到达目标表的时候就丢失了新列的数据。即使后续人工加上这个列，也已经丢失了那部分的数据。

@Tan-JiaLiang ，是的，这几点都是做 DDL 同步的难点。我们目前也正在研究方案。

@deadwind4 如果要输出 DDL 的话，不会放在 RowData 里面，会用新的数据结构。

watermark 可以 pushdown 到 cdc source 里面，这样 heartbeat 数据不用让 flink 框架感知。

1. 是的。目前确实有这个问题。也是将来的一个改进方向。 2. 支持的。具体可以看 debezium 的文档。

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

hybrid source 目前社区还没有官方的出来，也还在孵化中，以前我们做过一个基于 FLIP-7 的 POC，不过也只做了一半：https://github.com/wuchong/flink-hackathon 这个全量流+增量流的连接，在DataStream 上是可以做的，不过在 SQL 上比较麻烦（没有这种语义的算子）。

1. master 分支 2. 思路上是可行的。目前业界这方面尝试还比较少。

@SEZ9 如果有从库的话，可以连接从库。 1. 默认都是从最新 binlog 位置读取的。 2. 可行。你可以自己部署 debezium 把数据写到 kafka，然后用 flink 的kafka connector + debezium-json format 来解析。

@gitdongjian 支持。