共计 3504 个字符，预计需要花费 9 分钟才能阅读完成。
摘要：本文整顿自阿里巴巴开发工程师，Apache Flink Committer 任庆盛，在 9 月 24 日 Apache Flink Meetup 的分享。次要内容包含：
1.Flink CDC 技术比照与剖析
2.Flink + Kafka 实时数据集成计划
3.Demo：Flink+Kafka 实现 CDC 数据的实时集成和实时剖析
一、Flink CDC 技术比照与剖析
1.1. 变更数据捕捉（CDC）技术
狭义概念上，可能捕捉数据变更的技术统称为 CDC（Change Data Capture）。通常咱们说的 CDC 次要面向数据库的变更，是一种用于捕捉数据库中数据变动的技术。
CDC 的次要利用有三个方面：
- 数据同步，通过 CDC 将数据同步到其余存储地位来进行异地灾备或备份。
- 数据散发，通过 CDC 将数据从一个数据源抽取进去后分发给上游各个业务方做数据处理和变换。
- 数据采集，应用 CDC 将源端数据库中的数据读取进去后，通过 ETL 写入数据仓库或数据湖。
依照实现机制，CDC 能够分为两种类型：基于查问和基于日志的 CDC。基于查问的 CDC 通过定时调度离线工作的形式实现，个别为批处理模式，无奈保证数据的实时性，数据一致性也会受到影响。基于日志的 CDC 通过实时生产数据库里的日志变动实现，如通过连接器间接读取 MySQL 的 binlog 捕捉变更。这种流解决模式能够做到低提早，因而更好地保障了数据的实时性和一致性。
1.2. Flink CDC 的技术劣势
在上图中，咱们比拟了几种常见的 CDC 计划。相比于其余计划，Flink CDC 在性能上集成了许多劣势：
- 在实现机制方面，Flink CDC 通过间接读取数据库日志捕捉数据变更，保障了数据实时性和一致性。
- 在同步能力方面，Flink CDC 反对全量和增量两种读取模式，并且能够做到无缝切换。
- 在数据连续性方面，Flink CDC 充分利用了 Apache Flink 的 checkpoint 机制，提供了断点续传性能，当作业呈现故障重启后能够从中断的地位间接启动复原。
- 在架构方面，Flink CDC 的分布式设计使得用户能够启动多个并发来生产源库中的数据。
- 在数据变换方面，Flink CDC 将从数据库中读取进去后，能够通过 DataStream、SQL 等进行各种简单计算和数据处理。
- 在生态方面，Flink CDC 依靠于弱小的 Flink 生态和泛滥的 connector 品种，能够将实时数据对接至多种内部零碎。
1.3. Flink CDC 全增量一体化框架
自 2.0 版本起，Flink CDC 引入了增量快照框架，实现了数据库全量和增量数据的一体化读取，并能够在全量和增量读取之间进行无缝切换。在读取全量数据时，Flink CDC source 会首先将数据表中的已有数据依据主键散布切分成多个 chunk（如上图中的绿色方块所示），并将 chunk 分发给多个 reader 进行并发读取。
对于数据变动频繁、已有数据较多的数据库，在全量同步过程中已同步的数据可能会发生变化。一些数据集成工具的解决方案是在读取前获取表锁阻止数据变更，再进行全量数据读取，然而这种计划会对在线业务造成较大影响。为解决该问题，Flink CDC 的增量快照框架引入了水位线（watermark）的概念：在启动全量同步前，首先获取数据库以后最新的 binlog 位点，记为低水位线（low watermark），如上图中的蓝色方块所示，随后启动全量读取。
在所有全量数据读取实现后，CDC source 会再次获取最新的 binlog 位点，并记为高水位线（high watermark），如上图中第二个蓝色方块所示。位于高下水位线之间、与被捕捉表相干的 binlog 事件（上图中的黄色方块）即为全量数据在读取阶段产生的数据变动，CDC source 会将这部分增量数据合并至现有快照，合并实现后即可取得与源数据库完全一致的实时快照，并且在此过程中无需对数据库进行加锁，不会影响线上业务的失常运行。
业界罕用的另一个 CDC 工具是 Debezium。与 Flink CDC 相比，Debezium 计划须要在全量读取前为数据库加锁，且只能应用单并发读取。如果在同步过程中工作产生失败，须要从全量数据从新读取才可能保障一致性。Flink CDC 的增量快照框架计划在全量读取前无需加锁，并且能够应用多并发读取。依靠于 Flink checkpoint 机制，如果在同步过程中作业产生异样，可疾速从最近一次胜利的 checkpoint 复原读取。
1.4. Flink CDC 社区倒退
Flink CDC 社区从 2020 年 7 月份创建至今受到了各位开发者的宽泛关注，整个社区蓬勃发展。截至 2023 年 1 月，我的项目 star 数量超过 3000 个，超过 70 位贡献者提交了超过 500 个 commit，我的项目 fork 数量超过 1200 次。在此也特别感谢每一位参加 Flink CDC 的开发者为社区蓬勃发展做出的卓越贡献！
2022 年 11 月，Flink CDC 社区公布了最新的 2.3 版本，对 MySQL CDC 进行了诸多稳定性和稳定性改良，新增了 Db2 CDC 连接器，MongoDB CDC 连接器接入了增量快照框架。详情可浏览 Flink CDC 2.3 发布公告：https://mp.weixin.qq.com/s/eo…
二、Flink + Kafka 实时数据集成计划
上图展现了一个典型的数据同步场景，源数据库中的变更数据应用 Flink CDC 同步到上游。如果上游业务方较多、须要同步的数据库表较多或数据处理逻辑较简单，因为每张数据表都须要启动一个 Flink 作业进行同步，这样会对源数据库造成极大压力。此外，某些热点表或数据库会被多个 Flink CDC 同步工作频繁拜访，同样会加剧数据库的拜访压力。
为了解决以上业务痛点，一种可行的设计是在数据流水线中引入音讯队列中间件的分布式能力，缓解数据库压力。比方先将源库中的变更数据同步到 Kafka 中，再由各个业务方生产。但引入音讯队列后仍然存在许多须要人工染指的问题，比方配置 CDC source、配置 Kafka sink、手动创立 Kafka topic 和 partition 等。另外，基于目前 Flink CDC 的设计，每一张表都须要启动一个同步作业，如果数据库里的表十分多，也会为源库带来很大的压力。
针对以上问题，阿里云实时计算平台推出了 Flink + Kafka 实时数据集成解决方案，用户应用一句 SQL 即可将数据库疾速同步到 Kafka。解决方案应用了 CREATE TABLE AS（CTAS）语法和 CREATE DATABASE AS（CDAS）语法，指定源表名或源数据库名，以及指标表名或指标数据库名，即可疾速将源库中的数据同步到指标 Kafka 中，无需手动配置配置工作和创立 Kafka topic / partition。
此外，解决方案还反对对源表的构造变更进行主动同步。如果源表中新退出可空列、删除可空列或重命名列，Kafka sink 会动静调整写入时应用的 JSON format，依照变更后的表构造将数据写入 Kafka 音讯中。
依照 Flink CDC 以后的设计，在进行整库同步时，对数据库中的每张数据表都须要启动一个 Flink 作业进行生产，如果表数量十分多，Flink 作业数及其耗费的资源也会十分多。整库同步解决方案针对该问题进行了优化，在 Flink 作业中对同一个数据库复用一个 CDC source 实例，连贯多个 sink 将不同表中的数据散发至不同的 Kafka topic，因而只需启动一个 Flink 作业即可同步数据库中的所有表。如果数据量十分大，也只需调节同步作业的并发，无需启动多个作业来对同一个数据库进行生产，大大降低 Flink 对于数据库连接数的压力。
Flink + Kafka 实时数据集成的解决方案有如下几个劣势：
- 只须要一条 SQL（CTAS、CDAS）即可实现单表或整库同步，无需重复配置作业参数来启动多个作业。
- 主动创立指标端 Kafka topic 和 partition，用户无需在 Kafka 集群中进行手动配置。
- 原生反对了增加可空列、删除可空列以及重命名列等表构造变更同步的策略，可能反对更多数据同步的场景。
三、Demo：Flink+Kafka 实现 CDC 数据的实时集成和实时剖析
数据库中有三张表，别离是产品、订单、运输表。通过 CDAS 整库同步能力，将数据一次性同步到 Kafka 中，上游有多条业务线来生产 Kafka 里数据。Flink 作业将后面三张表做 join，打成宽表。如果没有两头的 Kafka 或同步能力，则须要起多个 Flink 作业，生产源库中某两个或多个数据表的变更数据，比方 order 表，自身可能变动十分快，会对数据库产生十分大的压力。咱们将通过 demo 来演示如何解决该问题。
原文链接
本文为阿里云原创内容，未经容许不得转载。
