Flink CDC
• 是变更数据获取的缩写 （Change Data Capture）
• 将源数据 （Source）的变动同步到一个或者多个目的地 (Sink)
• 再同步的过程中可以对数据进行一些额外操作 （GROUP BY | JOIN | ...）
• 解决: 对同一份数据多次下沉的场景，解决传统方式对一份数据多次分发的操作
• 比如落地： Redis | Elasticsearch | ClickHouse
实现模式
主动查询
• 在数据源表中 保存上次更新的时间戳跟版本号
• 下游通过不断查询和上次记录做对比，来确定数据是否有变动，是否需要同步
• 优点：不涉及底层 binlog 的采集与解析 （减少数据传输过程）
• 缺点：下游需要不断查询对数据库 Service 有压力
事件接收
• 通过触发器 Trigger 或者 日志的操作记录该事件 （例如 Transaction log、Binary log、Write-ahead log）
• 源数据发生改变后附加在 Trigger 或者 LOG(Binlog) 中
• 下游通过数据库底层的协议订阅并消费这些事件，对数据库的变动做回放的效果 达到数据的同步工作
• 优点：可以减少对数据库 Service 的压力，实时性比较高
• 缺点：针对于 LOG 需要有对应的解析工具参与解析 （Canal、Datax、Debezium）,学习成本高
使用方法
输入 Debezium 等数据流进行同步
• 特点：做到处理的解耦工作 | 对于数据的处理得到的解耦合
相当于是 DBServer ->  Debezium -> Kafka -> Flink -> TransSink
• 缺点：个人感觉维护量大、学习成本高
直接对接上游数据库进行数据同步
• 特点：学习成本小、无需考虑内部细节（内部都做了封装、开箱即用）
相当于是 DBServer -> Flink CDC ->TransSink
• 缺点：不透明化、内聚、数据安全需要考虑 （类似做一些加密操作）