前言：
主要讲解了技术原理，入门与生产实践，主要功能：全增量一体化数据集成、实时数据入库入仓、最详细的教程。Flink CDC 是Apache Flink的一个重要组件，主要使用了CDC技术从各种数据库中获取变更流并接入到Flink中，Apache Flink作为一款非常优秀的流处理引擎，其SQL API又提供了强大的流式计算能力，因此结合Flink CDC能带来非常广阔的应用场景。例如，Flink CDC可以代替传统的Data X和Canal工具作为实时数据同步，将数据库的全量和增量数据同步到消息队列和数据仓库中。也可以做实时数据集成，将数据库数据实时入湖入仓。还可以做实时物化视图，通过SQL对数据做实时的关联、打宽、聚合，并将物化结果写入到数据湖仓中。
作为新一代的数据集成框架，Flink CDC希望解决的问题很简单：成为数据从源头连接到数据仓库的管道，屏蔽过程中的一切复杂问题，让用户专注于数据分析，但是为了让数据集成变得简单，其中的难点仍然很多，比如说百亿数据如何高效入湖入仓？千表数据如何稳定入湖入仓，以及如何一键式的数据同步处理，表结构频繁变更 ，如何自动同步表结构变更到湖和仓中？本文将作为一一进行介绍
CDC概念
CDC的全称是Change Data Capture，在广义的概念上，只要是能够捕获数据变更的技术，都可以成为是CDC。目前通常描述的CDC技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术，CDC的应用非常广泛。
- 数据迁移：常用于数据库备份、容灾等
- 数据分发：将一个数据源分发给多个下游，常用语业务的解耦、微服务的使用场景
- 数据采集：将分散异构的数据源集成到数据仓中，消除数据孤岛，便于后续的分析，监控
目前主要的CDC有两种：
- 基于查询的CDC
- 离线调度查询作业，批处理。依赖表中的更新时间字段，每次执行查询去捕获表中的最新数据
- 无法捕获的是删除事件，从而无法保证数据一致性问题
- 无法保障实时性，基于离线调度存在天然的延迟
- 基于日志的CDC
- 实时消费日志，流处理。比如说MySQL里面的BinLog日志完整记录数据库中的数据变更，可以把binLog文件作为流的数据源
- 保障数据一致性，因为binLog文件中包含了所有历史变更明细
- 保障实时性，因为类似binLog的日志文件可以流式消费的，提供的实时数据
常见开源CDC方案比较
从这张图可以看出来，在数据加工能力上，CDC工具是够能够方便地对数据做一些清洗、过滤、聚合，甚至关联拓宽。Flink CDC依托强大的Flink SQL流式计算能力，可以非常方便对数据进行加工。Apache Flink的一个组件具有非常灵活的水平扩展能力。而DataX 和Canal是单体架构，在大数据场景下容易面临性能瓶颈的问题。
从生态方面，这个是上下游存储的支持。Flink CDC上下游非常丰富，支持对接MySQL、Post供热SQL等数据源，还支持写入到HBase、Kafka、Hudi等各种存储系统中，也支持灵活的自定义connector
Flink CDC 项目
Flink有两个基础概念，Dynamic Table和Changelog Stream
- Dynamic Table就是Flink SQL定义的动态表，动态表和流的概念是对等的，意思是流可以转换为动态表，动态表也可以转换成流
- 在Flink SQL中数据从 一个算子流向另一个算子时都是以Changelog Stream的形式，任意时刻的Changelog Stream可以翻译为一个表，也可以翻译成一个流
MySql中的表和binlog日志，就会发现MySql数据库的一张表所有的变更都记录在binlog日志中，如果一直对表进行更新，binlog日志流也会一直增加，数据库中的表就相当于binlog日志流在某个时刻点物化的形式；日志流就是将表的变更数据持续捕获的结果。说明Flink SQL的Dynamic Table是可以非常自然地表示一张不断变化的MySql数据库表
Debezium支持全量同步，也支持增量同步，也支持全量+增量的同步，非常灵活，同时日志的CDC技术使得提供Exactly-Once称为可能。
每条RowData都有一个元数据RowKind，包括4种类型，分别是插入、更新前镜像、更新后镜像、删除，这四种类型和数据库里面的binlog概念保持一致
而Debezium的数据结构，也有一个类似的元数据字段op，op字段的取值也是四种，分别是c、u、d、r，各自对应create、update、delete、read，对于代表更新操作的u，其数据部分包含了前镜像(before)和后镜像(after)
Flink CDC分析
传统的基于CDC的ETL分析中，数据采集工具是必须的，国外用户常用的Debezium，国内用户常用的阿里开源的Canal，采集工具负责采集数据库的增量数据，一些采集工具也支持全量数据同步。采集到的数据一般输出到消息中间件如kafka，然后Flink计算引擎再去消费数据并写入到目的端，目标端可以是各种数据库、数据仓库、数据湖和消息队列。
Flink提供了changelog-json format，可以使changelog数据写入到离线数据仓库(Hive)；对于消息队列Kafka，Flink支持通过changelog的upset-kafka connector直接写入到kafka的compacted topic。
一致性就是业务正确性，在“流系统中间件”这个业务领域，端到端一致性就代表 Exacly Once
Msg Processing(简称 EOMP)，即一个消息只被处理一次，造成一次效果。即使机器或软件出现故
障，既没有重复数据，也不会丢数据。
幂等就是一个相同的操作，无论重复多少次，造成的效果和只操作一次相等。流系统端到端链路较
长，涉及到上游 Source 层、中间计算层和下游 Sink 层三部分，要实现端到端的一致性，需要实
现以下条件：
上游可以 replay，否则中间计算层收到消息后未计算，却发生 failure 而重启，消息就会丢失。
记录消息处理进度，并保证存储计算结果不出现重复，二者是一个原子操作，或者存储计算结果
是个幂等操作，否则若先记录处理进度，再存储计算结果时发生 failure，计算结果会丢失，或者
是记录完计算结果再发生 failure，就会 replay 生成多个计算结果。
中间计算结果高可用，应对下游在接到计算结果后发生 failure，并未成功处理该结果的场景，可
以考虑将中间计算结果放在高可用的 DataStore 里。
下游去重，应对下游处理完消息后发生 failure，重复接收消息的场景，这种可通过给消息设置
SequcenceId 实现去重，或者下游实现幂等
