文章目录
[Flink CDC基本介绍](#Flink CDC基本介绍)
[三、传统 CDC ETL 分析](#三、传统 CDC ETL 分析)
[四、基于 Flink CDC 的 ETL 分析](#四、基于 Flink CDC 的 ETL 分析)
[五、什么是 Flink CDC](#五、什么是 Flink CDC)
[六、Flink CDC 的功能特性](#六、Flink CDC 的功能特性)
[七、Flink CDC 技术的核心](#七、Flink CDC 技术的核心)
Flink CDC基本介绍
一、什么是CDC
CDC 的全称是 Change Data Capture ，在广义的概念上，只要是能捕获数据变更的技术，我们都可以称之为 CDC 。目前通常描述的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。
CDC 技术的应用场景非常广泛：
- 数据同步：用于数据备份，容灾；
- 数据分发：一个数据源分发给多个下游系统；
- 数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是非常重要的数据源。
二、CDC的实现机制
CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种：
基于主动查询的 CDC：
用户通常会在数据源表的某个字段中，保存上次更新的时间戳或版本号等信息，然后下游通过不断的查询和与上次的记录做对比，来确定数据是否有变动，是否需要同步。
特点：
- 离线调度查询作业，批处理。把一张表同步到其他系统，每次通过查询去获取表中最新的数据;
- 无法保障数据一致性，查的过程中有可能数据已经发生了多次变更；
- 持续的频繁查询对数据库的压力较大。
- 不保障实时性，基于离线调度存在天然的延迟。
基于事件接收CDC：
可以通过触发器（Trigger）或者日志（例如 Transaction log、Binary log、Write-ahead log 等）来实现。当数据源表发生变动时，会通过附加在表上的触发器或者 binlog 等途径，将操作记录下来。下游可以通过数据库底层的协议，订阅并消费这些事件，然后对数据库变动记录做重放，从而实现同步。
- 实时消费日志，流处理，例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把 binlog 文件当作流的数据源；
- 保障数据一致性，因为 binlog 文件包含了所有历史变更明细；
- 保障实时性，因为类似 binlog 的日志文件是可以流式消费的，提供的是实时数据。
综合来看，事件接收模式整体在实时性、吞吐量方面占优，如果数据源是 MySQL、PostgreSQL、MongoDB 等常见的数据库实现，建议使用 Debezium来实现变更数据的捕获。如果使用的只有 MySQL，则还可以用 Canal。
三、传统 CDC ETL 分析
我们来看下传统 CDC 的 ETL 分析链路，如下图所示：
传统的基于 CDC 的 ETL 分析中，数据采集工具是必须的，国外用户常用 Debezium ，国内用户常用阿里开源的 Canal ，采集工具负责采集数据库的增量数据，一些采集工具也支持全量数据同步。采集到的数据一般输出到消息中间件如 Kafka，然后 Flink 计算引擎再去消费数据并写入到目的端，目的端可以是各种数据库、数据仓库、数据湖和消息队列。
**注意：**Flink 提供了 changelog-json format，可以将 changelog 数据写入离线数仓（如 Hive）； 对于消息队列（如 Kafka），Flink 支持将 changelog 通过 upsert-kafka connector 直接写入 Kafka 的 compacted topic
官方一直在思考是否可以使用 Flink CDC去替换上图中虚线框内的采集组件和消息队列，从而简化分析链路，降低维护成本。同时更少的组件也意味着数据时效性能够进一步提高。答案是可以的，于是就有了我们基于 Flink CDC 的 ETL 分析流程。
四、基于 Flink CDC 的 ETL 分析
在使用了 Flink CDC 之后，除了组件更少，维护更方便外，另一个优势是通过 Flink SQL 极大地降低了用户使用门槛，可以看下面的例子：
该例子是通过 Flink CDC 去同步数据库数据并写入到 TiDB，用户直接使用 Flink SQL 创建了产品和订单的 MySQL-CDC 表，然后对数据流进行 JOIN 加工，加工后直接写入到下游数据库。通过一个 Flink SQL 作业就完成了 CDC 的数据分析、加工和同步。
大家会发现这是一个纯 SQL 作业，这意味着只要会 SQL 的业务线同学都可以完成此类工作 。与此同时，用户也可以利用 Flink SQL 提供的丰富语法进行数据清洗、分析和聚合。此外，利用 Flink SQL 双流 JOIN、维表 JOIN、UDTF 语法可以非常容易地完成数据打宽，以及各种业务逻辑加工。
而对于其他 CDC 工具（如 Debezium）来说，进行数据的清洗过滤都是非常困难的，更无法支持复杂的聚合和关联了。
五、什么是 Flink CDC
Flink CDC 基于数据库日志的 Change Data Caputre 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。
目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 等丰富的数据源，对 Oceanbase、TiDB、SQLServer 等数据库的支持也已经在社区的规划中。
Flink CDC 的下游则更加丰富，支持写入 Kafka、Pulsar 消息队列，也支持写入 Hudi、Iceberg 等数据湖，还支持写入各种数据仓库。
同时，通过 Flink SQL 原生支持的 Changelog 机制，可以让 CDC 数据的加工变得非常简单。用户可以通过 SQL 便能实现数据库全量和增量数据的清洗、打宽、聚合等操作，极大地降低了用户门槛。 此外， Flink DataStream API 支持用户编写代码实现自定义逻辑，给用户提供了深度定制业务的自由度。
六、Flink CDC 的功能特性
- 支持数据库级别的快照，读取全量数据，2.0版本可以支持不加锁的方式读取
- 支持 binlog，捕获增量数据
- Exactly-Once
- 支持 Flink DataStream API，不需要额外部署 Debezium 和 Kafka即可在一个 Flink 作业中完成变更数据的捕获和计算
- 支持 Flink Table/SQL API，可使用 SQL DDL 来创建 CDC Source 表，并对表中的数据进行查询。
七、Flink CDC 技术的核心
Flink CDC 技术的核心是支持将表中的全量数据和增量数据做实时一致性的同步与加工，让用户可以方便地获每张表的实时一致性快照。比如一张表中有历史的全量业务数据，也有增量的业务数据在源源不断写入，更新。Flink CDC 会实时抓取增量的更新记录，实时提供与数据库中一致性的快照，如果是更新记录，会更新已有数据。如果是插入记录，则会追加到已有数据，整个过程中，Flink CDC 提供了一致性保障，即不重不丢。
- 📢博客主页：https://lansonli.blog.csdn.net
- 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
- 📢本文由 Lansonli 原创，首发于 CSDN博客🙉
- 📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨