Flink CDC：基于 Apache Flink 的流式数据集成框架
择要：本文整理自阿里云 Flink SQL 团队研发工程师于喜千（yux）在 SECon 环球软件工程技能大会中数据集成专场沙龙的分享。内容重要为以下四部门：[*] Flink CDC 开源社区先容；
[*] Flink CDC 的演进汗青；
[*] Flink CDC 3.x 焦点特性解读；
[*] 基于Flink CDC 的及时数据集成实践。
1. Flink CDC 开源社区先容
1.1 Flink CDC 的演进汗青
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvMzQyZjY4ZDBiY2VlODFhNjM3OTFjNjNkMGUwMjRkYmEucG5n
Flink CDC 最早的发展就始于 GitHub 开源社区。自 2020 年 7 月开始，项目在 Ververica 公司的 GitHub 堆栈下以 Apache 2.0 协议开放源代码。并提供了从主流 MySQL 和 PG SQL 数据库中捕获厘革数据的本事。2.0 版本引入了运行更高效、更稳固、支持故障规复的增量快照框架，而且丰富了源数据库支持范围，可以或许从 Oracle、MongoDB 及时抽取数据。
客岁 11 月发布的 CDC 3.0 版本引入了全新的 YAML pipeline 作业，可以或许作为一个独立的端到端数据集成框架利用，通过极简的语法更轻松地形貌数据集成作业。
1.2 Flink CDC 社区近况
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvMTRlMGE4OTQ5NWI2ODM2M2Y2NmZlMGEzMTBhODVjNjkucG5n
2024 年年初，Flink CDC 正式作为 Flink 的一个子项目加入 Apache 软件基金会，依照 ASF 的标准规范流程举行新版本的开辟迭代，停止如今最新的 3.1.1 版本，已经积聚了来自一百三十多位贡献者的一千余次 commit、GitHub 上劳绩高出五千颗 star。
Flink CDC 社区同样有着极为多元的生态；GitHub Top 20 代码贡献者分别来自 10 家差别的公司，它们贡献了 MongoDB、Oracle、Db2、OceanBase 等毗连器及 Pipeline Transform 等焦点功能。
在加入 Apache 软件基金会后，Flink CDC 也在原有钉钉用户互换群的根本上、利用 Apache Flink 邮件列表、及面向国际用户的 Slack 频道等多样化的方式，与社区用户保持沟通、互换答疑、罗致新功能发起。
2. Flink CDC 的演进汗青
2.1 CDC 技能简介
CDC（Change Data Capture，厘革数据捕获）是一种及时监控数据变更，并将形貌数据厘革的记载及时写入数据流中的技能。在 Flink CDC 的语境里，通常特指捕获外部数据库中的增编削等操纵带来的变更。CDC 技能可以被用于举行一对一的数据同步，比方自动提取主数据库中的厘革并同步到备份数据库，以便举行数据备份或迁徙；CDC 也支持一对多、多对一的数据分发，将源表按规则举行拆分和归并；也支持在收罗数据（Extraction）后举行转换（Transform）并加载（Load）到数据堆栈或数据湖中。
数据库厘革捕获（CDC）的有效实行计谋重要包罗两种：一是定期查询方法（Query-based CDC），二是基于日记的及时处置惩罚（Log-based CDC）。前者通过周期性地直接查询数据库来探测厘革，此法简朴但受限于查询频率与延长，难以满足及时性要求，尤其在资源斲丧与低延长需求的流处置惩罚场景下非最优选择。相比之下，后者利用了数据库自带的日记机制（如 MySQL 的 Binlog、Oracle 的 Redo Log、MongoDB 的 OpLog）来捕获变更。该方式通过监听并剖析这些连续更新的日记流，可以或许在数据更改发生时险些无延长地捕获到厘革，无需频仍查询数据库自己。此过程不但减轻了数据库压力，而且由于日记的次序性和完备性，能确保每个变更变乱准确地被消耗一次，实现“恰好一次”的处置惩罚语义，保障了数据处置惩罚的划一性和可靠性。Flink CDC 从一开始就接纳这一计谋，融合了基于日记的及时 CDC 技能与 Flink 引擎提供的 Checkpoint 机制，确保了数据处置惩罚过程中的划一性与容错本事，为及时数据分析与处置惩罚提供了一个高效、可靠的办理方案。
2.2 早期 CDC 技能范围
早期的各种 CDC 实现的实用性并不理想。以 Flink CDC 1.x 版本为例，重要标题包罗以下几个方面：
[*] 快照处置惩罚服从低下：Flink CDC 1.x 在实行数据库快照时，仅支持单一并发模式访问源数据库，导致快照天生过程大概耗时数小时以致更久。
[*] 必要获取数据库锁和表锁：为了确保快照后能无缝衔接增量数据处置惩罚，必要准确记载日记的读取位置。但这一过程必要利用FLUSH TABLES WITH READ LOCK下令，它会锁定全局数据库，在最坏环境下大概导致数据库的全部读写操纵全部挂起，乃至引起服务制止。
[*] 缺乏故障规复机制：快照阶段在遭遇网络故障、数据不划一等非常环境时，缺乏有效的故障规复计谋，迫使整个快照过程重新开始。联合前述快照的低效性，这一缺陷极大地低落了体系的稳固性和实用性，使得在现实生产环境摆设时风险较高，难以与成熟的数据同步办理方案相竞争。
2.3 Flink CDC 接入增量快照框架
真正让 Flink CDC 开始变得更加易用，而且相比其他框架具备肯定上风的是 CDC 2.0 版本中的几项框架层面的大更新。起首，针对 MySQL、MongoDB 等主流常用数据库，实现了增量快照算法的改造，终于支持了恣意多并发快照读取、无需对数据库、数据表举行加锁，也一并支持了 checkpoint 和故障规复功能；依据 Netflix 的一篇 DBlog 论文提出的无锁快照的算法，实现了不锁表、多并发的环境下准确完成划一性快照的功能。下面我来详细先容一下这些改进的实现。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvZTBkZmViNzBiODRjNzFhMTdjZmNmYTQ0MGVmZTNhYjYucG5n
早期的Flink CDC 基于 Flink 的原始 SourceFunction API 实现，要求开辟者自行实现并发处置惩罚、数据分片、多线程使命和谐及状态管理等底层细节，大大增长了实现难度和维护本钱。FLIP-27 提案则引入了新的 Flink Source API 架构，将数据源的读取架构拆分为两大焦点组件：SplitEnumerator 与 Reader。SplitEnumerator 负责数据源的逻辑分别，将其细分为多个独立的处置惩罚单元（分片），而 Reader 则负责从给定的分片中抽取数据，这一筹划极大地提拔了抽象条理和机动性。
在 Flink CDC 增量快照框架的实现中，SplitEnumerator 会在快照初始化阶段根据数据库特性，尽大概匀称地将待捕获的数据集切分为多个快照分片。比方，MongoDB CDC 会利用数据库提供的 splitVector 函数按数据量举行匀称分割；MySQL CDC 则采取抽样计谋评估每行数据巨细，依据主键举行匀称产生分片。随后，这些分片被 Flink 引擎调治分发至多个并行的 Reader 实例，独立实行并发数据读取，明显增强了快照处置惩罚的并发服从与团体吞吐量。此架构还允许每个 Reader 维护独立的内部状态并恒久化至Checkpoint 中，确保体系在遭遇故障时，可以或许规复至迩来一次的状态，而无需重新实行快照，极大地增强了体系的结实性和容错本事。
CDC 2.x 系列版本系列历经五次小版本迭代，在不绝维持最新 Flink 版本兼容性的根本上，在原来支持的 MySQL、Oracle、PG 数据库的根本上扩展 CDC 数据源支持，并将更多数据源接入了高效的增量快照框架。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvODJmMjcxYjA2NTE0NmIxZWQyZDUyZWMxOWQxMzk4ZjIucG5n
3. Flink CDC 3.0 焦点特性解读
3.1 Flink CDC 2.x 版本回顾
回顾 Flink CDC 2.x 的终极版本，从最开始的 CDC Connectors for Flink 开始历经三年多发展，本质上仍旧是依赖 Flink 运行时的一组毗连器工具类库，用户必须编写 SQL 作业或 Java DataStream 作业方可利用，这在用户体验上不敷直观友好。别的，Flink CDC 受制于 Flink Source 的职责束缚，难以在保持与现有鄙俚毗连器及 SQL 框架兼容的同时对变乱格式举行扩展或调解，难以支持诸如表布局变更、数据路由、恒久化存储、自动扩展等进阶本事。
比方，利用 Flink CDC 2.x 调解表布局过程涉及到多个体系组件的手动实行：停息作业、记载 savepoint、同步更新上鄙俚数据库 Schema、末了从生存点规复作业。这一过程不但引入了数据同步的延长，还存在因 Schema 差别步导致的作业稳固性风险，而这些标题超出了 Flink CDC 作为单一 Source connector 所能办理的本事范畴。
别的，项目标开源属性和中立性亦成为关注点。Flink CDC Connector 的代码库及版权属于 Ververica 贸易实体，与 Apache Software Foundation 及 Flink Committee 在法律上相互独立，让用户在贸易化利用、外部贡献者思量代码贡献时带来一些疑虑。
3.2 Flink CDC 3.0 的筹划目标
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvZjFjMGQxMmQxMGYzYmU2NGQwYzg2ZmNmMzUxYTJkMDQucG5nhttps://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvNTU5NzdiNzJjMGNmZjRhZjEzN2IwNzljYjRhNGVjZGYucG5n
CDC 3.0 渴望可以或许在生存已有的成熟代码库的根本上，办理上述这些关键的痛点标题。起首，在已有的 SQL 和 Java API 的根本上，提供全新的 YAML API，作为一种重要面向数据集成用户的利用方式，支持对数据摄取、变更、路由、写入的全过程举行自界说的形貌。YAML 并非重新开始的重新实现，而是基于已有的成熟 API 的封装和增强。原有的 Table 和 DataStream API 仍旧会被积极维护、增加新功能和修正错误，供具有高级数据处置惩罚需求的用户利用。
别的，YAML API 还提供了针对 Schema Evolution 表布局变更提供了支持。如今要修改 Schema 无需再重启作业；CDC 在从上游表中检测到 Schema 布局变更的变乱后，会将表布局状态恒久化到 State 中记载，并自动将兼容的变更应用到鄙俚的 Sink 数据库中。CDC 3.0 为 Schema Evolution 功能提供了开箱即用的支持，只必要选用兼容的 Source 和 Sink 毗连器，而且在 pipeline 设置项中打开 Schema Evolution 的开关即可。
末了，在完成上述新增功能演进之后，Flink CDC 被作为一个独立的流式数据集成框架，被捐赠进入 Apache 软件基金会，确保了项目管理和开辟的规范和中立。
3.3 Flink CDC 3.0 焦点架构
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvMjgzM2RhNmJjMjJhN2RmN2QyM2VhZjNiZDgzYjM0ZjQucG5n
从软件架构上来说，3.0 版本之前的 Flink CDC 仅仅是一组 Flink Source 毗连器的组合，无法独立利用；这些组件在版本更新后并没有被废弃，而是被用于实现 Flink CDC 3 版本中最为关键的毗连层（Flink CDC Connect），它们用于支持上层的 YAML pipeline 作业和 Flink CDC 下令行界面（Flink CDC CLI）的运行。在 Connect 层之下，是负责创建 Flink CDC 作业实行算子图、天生 Flink 使命的 Composer 层、以及在运行时为毗连器提供 Schema Evolution、Transform 和 Route 等功能支持的 Runtime 层。上述的运行时模块均作为独立的 Flink 算子由 Flink Runtime 提供状态存储、生命周期管理等支持。
Flink CDC 3.0 接纳了无状态（stateless）的筹划模式，不负担恒久化任何额外状态的职责，保持了架构的简便性与轻量化；在架构图中，也未引入一个单独的 CDC Server API 服务负责使命的生命周期管理，诸如初始化、实行与停止等关键功能均由Flink 原生引擎框架负担，且可以或许更好地利用 Flink 成熟且强大的作业管理与调治机制。此筹划决定极大地简化了 Flink CDC 的摆设架构与运维复杂度，消除了额外摆设独立的“CDC服务”的必要。用户仅需提供一个可用的 Flink 集群环境，便能无缝集成并启动 Flink CDC 使命，无论该集群是设置为独立 Standalone 模式、运行于 YARN 之上，还是构建在 Kubernetes 之中。这种筹划不但强化了体系的机动性与可扩展性，还充实利用了 Flink 现有的多样化摆设本事，实现了与 Flink 生态体系深度且高效的整合。
3.4 Flink CDC 3.0 API 筹划
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvNTFmMDYzY2Q4MDg1ZWZhNmI5Njc1NGU5ZTdmOTAxYWEucG5n
Flink CDC 3.0 引入了基于 YAML 的作业设置方式，接纳基于设置的形貌性语句全面地界说端到端的数据集成流程和 Pipeline 作业。这一筹划围绕数据同步的焦点要素睁开，通过五大设置模块形貌了源数据库设置、目标数据库设定、数据转换与过滤逻辑、数据路由计谋，以及全局作业选项所需的信息。YAML Pipeline 的筹划侧重于直观表达使命需求，而非技能实现细节，从而极大提拔了 Pipeline 作业的抽象程度和易用性。相较于 Flink 的 DataStream API 与 Table API，YAML 设置方法在生存高级功能的同时，有效屏蔽了底层实现的复杂性，如数据布局处置惩罚、序列化/反序列化机制、网络传输细节等，利用户可以或许聚焦于数据集成使命自己，而非技能实现的细节。这种筹划不但低落了用户上手利用的难度，还促进了设置的可读性和维护性，提拔了数据集成使命的设置服从与机动性。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvMmI4MWMwYzFjYTI4ZTNhMTE1NDk1MDA0MTdmMjExNDgucG5n
Flink CDC 3.0 通过引入强大的数据转换（Transform）支持，在确保设置简便直观的同时，提供了丰富的数据处置惩罚和转换的本事。在 SQL 语句中编写的 SELECT、WHERE 等指令，或是 Java 代码里调用的 .map、.filter等算子表达式实现的转换逻辑，如今仅需 YAML 设置文件中撰写简便的语句即可清晰地界说。这种筹划不但简化了开辟流程，还明显提拔了设置的可读性和维护性。转换规则利用类 SQL 的兼容表达式语法，允许用户直接在设置中实行列盘算，同时集成了 Flink SQL 的 Scalar Function 库，涵盖了大部门 SQL 内置函数，确保了从传统 SQL Transform 使命向 YAML 设置模式平滑过渡的无缝体验。
技能实现层面，Transform 流程构建了一个高效的实行图：PreTransform 算子分析设置的转换规则，辨认并筛选出必要处置惩罚的列——包罗明白指定的输出列、盘算列中引用的列，以及过滤条件涉及的列，从而提前优化数据流，剔除非须要数据，有效减小传输负担。后续的 PostTransform 算子则更加风雅化地实行过滤与投影操纵。起首，依据用户设定的过滤条件准确筛选数据行，随后，按照设置的投影规则盘算添补新的列值，确保输出数据布局与预期方案匹配。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvYjQ4NjIxODlkZTFlNGZlYTg3ZDEzMmQxNWY1MDRjMjkucG5n
在筹划实现焦点的 Connect 毗连层时，鉴于 Pipeline 作业需在已有的 CDC Source Connectors 根本上实现 Schema Evolution 等新特性，单纯相沿旧有接口显然无法满足需求。然而，完全摒弃既有生态的丰富资源并非明智之举，尤其是思量到 Flink 生态体系中已经广泛存在的现有 Source 与 Sink 毗连器。
为此，Flink CDC 3.0 界说了 DataSource与DataSink，他们是专为 3.0 版本新特性打造的，而涉及 Schema 元数据操纵的复杂性则被封装于 MetadataAccessor 与 MetadataApplier 类中，使得数据读写的焦点逻辑仍旧可以或许无缝对接 Flink 既有的 Source 与 Sink API，极大地减轻了毗连器迁徙的工作负担。别的，通过利用 SourceProvider 与 SinkProvider 这一抽象层级，Flink CDC 实现了对 Flink 新旧 API 的双重兼容，包罗对早期 Function API 的支持。实践证明，这一计谋不但加快了如 JDBC、Oceanbase、MaxCompute 等多样鄙俚毗连器的快速集成，同时也为将来毗连器的扩展与迭代铺设了机动且坚固的基石。
3.5 Flink CDC 3.0 Schema Evolution 功能
接下来先容 CDC 3.0 重点支持的 Schema Evolution 功能。由于 Flink CDC 不为每条数据变更变乱携带对应 Schema 的信息，因此包管并行实行作业时，确保注册中心中记载的 Schema 始终保持准确和划一非常告急，否则如果利用了错误版本的 Schema 对变乱举行处置惩罚，会导致消息记载的序列化过程失败。
为了包管这一点，Flink CDC 规定了如许的 Schema 变更处置惩罚过程：
1、在作业的某一个 Schema Operator 节点收到表布局变更变乱时，
2、Schema Operator 会立刻壅闭来自上游的全部变乱（包罗数据变更变乱和表布局变更变乱），
3、而且向 Schema 注册表中心 Registry 陈诉；
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvYmUxMGE4ZjhmOTg4MDMxZjBlZmY5Nzk1NDU2Mzk5OWEucG5n
4、注册表中心在收到表布局变更哀求后，会先向鄙俚发送 FlushEvent，要求 Sink 将未提交的数据变更全部落盘；由于按照语义，必须在全部先前的、对应旧 Schema 信息的数据记载都准确落盘之后，方可开始应用一次布局变更。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvZThjYmVkZjMzMGE3MzE2MDBmNDY5YjJhNmJmNTIxOTgucG5n
5、在全部的 Sink 都完成 Flush 操纵并转达 Registry 后，
6、Registry 会通过 MetadataApplier API 将表布局变更应用到鄙俚数据库之中；
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvYTcxMTBmYjZmNTk3YzI1OWU0OTNjMWEyOGE2ZGMxODgucG5n
7、末了，向 Schema Operator 告知此次 Schema 变更变乱竣事，
8、可以制止壅闭，开始继续处置惩罚来自上游的其他变乱了。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvNzhiOGQzMjhiNDVjYzNkNWY4YTM0Zjc5NDFlNTk0YTgucG5n
这是一次正常表布局变更演化的全过程。而在向鄙俚应用表布局变更发生错误时，Flink CDC 提供了多种可设置的活动模式：
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvYzMxYTgzOGVhMDU0MGMxZTA4NzQyM2RlMDMyYmEzNGEucG5n
[*] Ignore 模式下，忽略全部布局变更。
[*] Try Evolve 模式下，实验举行布局变更，失败则忽略。
[*] Evolve（默认）模式下，举行布局变更，失败则停止使命。
[*] Exception 模式下，拒绝任何布局变更，一旦发生直接停止使命。
从 Ignore 到 Exception，对 Schema Evolution 的限定是从最宽容到最严酷的。通过支持差别的设置文件模式设置，用户可以根据自己的必要和现实需求，为每个作业设置特定的 Schema Evolution 规则。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvMGY3ODNhZTE2ZTY5MDQyMzAxNDQ0ZmYxMjhkMzI4NmIucG5n
除了表布局变更功能之外，在网络用户反馈需求时，开辟者们相识到一种很常见的数据同步场景是将来自上游 MySQL 数据库的多张分表归并，并写入鄙俚的数据堆栈或数据湖中。如今，用户只必要在 YAML 设置文件中编写一条路由规则块，指定源表和写入表即可实现分库分表的归并。比方，这里来自上游的分表在颠末路由后归并为单逐一张 merged 表，来自上游三张表的建表变乱被归并为同一条，来自每张源表的数据变更变乱也被改写为对单一归并表的记载。
路由功能也可以与表布局变更功能共同发挥作用，提供额外的容错功能。比方，在上游某一张分表发生表布局变更，导致上游归并的三张分表布局产生差别的时间，一样平常的处置惩罚活动就是以为归并分表的条件已经不再满足了，直接抛出失败制止作业。CDC 为了只管包管作业的容错性、可以或许在包管不丢失有效数据的环境下只管稳固地连续运行作业，提供了额外的容错机制选项，允许 Pipeline 作业在某些环境下容忍错误继续运行。
比方，在上游某一张表增长了额外的一列的时间，这一信息会被自动同步到鄙俚；而对于其他不存在这一新增列的表，对应的数据行则会自动被用 NULL 值添补，以便符合鄙俚最新的布局。雷同的，删除某一张表的一列也不会导致鄙俚表的对应列被删除，只是这张表接下来到来的数据会被添补上空值。对于列范例修改导致各张分表对应字段范例不划一的环境，则会实验推导出可以或许无损容纳全部上游范例的协变范例。比方，框架允许将 FLOAT 宽转换为 DOUBLE，SMALLINT 转换 BIGINT、精度较低的 DECIMAL 转换到精度较高的数字范例。
但在这种无损的转换不创建的时间，CDC 还是会抛堕落误并制止作业，而不是岑寂地举行有损的数据压缩和变更。作为一个数据集成框架，在举行隐式自动转换的时间，服从的筹划原则是不扬弃、不删除、不压缩任何来自上游的数据，确保在默认的模式下尽大概完备地将数据转达给鄙俚。
4. 基于 Flink CDC 的及时数据集成实践
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvODg1ZjRkM2U5Y2UxYjQ5NzJmMWIwNDQ2MWI3MDI0ZmYucG5n
首个案例聚焦于实现MySQL数据库至Apache Kafka的及时数据传输。在不接纳 Flink CDC 的场景下，必要独立摆设 Debezium 或 Canal 集群，这些体系负责监听 MySQL 的 Binlog，转换数据为特定的 JSON 模子（依照 Debezium 或 Canal 的格式界说），并推送至 Kafka，便于鄙俚的 Flink、Spark Streaming 等多种流处置惩罚引擎订阅并进一步加工处置惩罚。
Flink CDC 3.0 版本明显增强了其功能集，内建了直接写入 Kafka 的输出毗连器，不但支持 Debezium 和Canal JSON 格式的输出，还深度整合了 Flink 的生态体系上风，为同属 Flink 环境下的数据摄取与分析使命提供了无缝集成的便利性，免除了额外根本办法的设置需求。别的，Flink CDC 3.0 还引入了多项高级特性，包罗但不限于模式进化（Schema Evolution）、列操纵（如投影和过滤）的 Transform 本事、丰富的内置函数支持，以及全面的数据库同步机制，为数据在进入消息队列条件供了高度可定制的预处置惩罚本事，如数据净化、选择性过滤及表布局优化，从而提拔了数据处置惩罚的机动性与服从。
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvOTljZDA0ZTE4MzBlYmUwZmM0NTI4ZDMzZDUwNTMxOTkucG5n
总结
[*] 作为一个从开始就诞生于 GitHub 的开源项目，Flink CDC 如今有着活泼的用户社区和繁荣的开源生态；
[*] 在三次大版本迭代的过程中发展为技能领先的分布式数据集成框架；
[*] 在最新的 3.0 版本中，CDC 为用户提供了开箱可用、功能丰富的 YAML Pipeline 作业支持；
[*] 而且可以或许支持典范的及时数据集成、入仓入湖的实践。
“ Flink CDC 社区 ② 群”群的钉钉群号：80655011780
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvY2Y2OGI1YWNlOWYyNjY3YzI2ODhhZmQ4OGZjOGYyYjMucG5n
” Flink CDC 公众号“的微信号：ApacheFlinkCDC
https://dis.qidao123.com/imgproxy/aHR0cHM6Ly9pLWJsb2cuY3NkbmltZy5jbi9ibG9nX21pZ3JhdGUvOGI3ZmM1NTFlNmUzM2I2MDY3ZGM0OWMzOTNiMmViZjcuanBlZw==
https://flink.apache.org/what-is-flink/community/#slack
https://flink.apache.org/what-is-flink/community/#mailing-lists
https://github.com/apache/flink-cdc
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金
页:
[1]