共计 5815 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：本文整顿自阿里云技术专家，Apache Flink PMC Member & Committer, Flink CDC Maintainer 徐榜江和阿里云高级研发工程师，Apache Flink Contributor & Flink CDC Maintainer 阮航，在 Flink Forward Asia 2022 数据集成专场的分享。本篇内容次要分为四个局部：
1. 深刻解读 Flink CDC 2.3 版本
2. 基于 Flink CDC 构建古代数据栈
3. 阿里云外部实际和改良
4.Demo & 将来布局
一、深刻解读 Flink CDC 2.3 版本
1.1 Flink CDC
首先介绍一下 Flink CDC 技术。Flink CDC 是基于数据库的日志 CDC 技术，实现了全增量一体化读取的数据集成框架。配合 Flink 优良的管道能力和丰盛的上下游生态，Flink CDC 能够高效实现海量数据的实时集成。
如上图所示，在数据库中，咱们有历史的全量数据，也有实时的增量数据。比方上游有业务零碎在源源不断实时写入数据，Flink CDC 技术的能力就是将全量数据和增量数据无缝集成到 Flink 引擎中，为上游利用提供实时的一致性快照。
1.2 Flink CDC 2.3 根本介绍
2022 年 11 月 10 日，Flink CDC 社区公布了 2.3 版本。此版本的贡献者共有 49 位，解决了 126 个 issue，合并的 PR 达到 133 个；合并的 commits 达到 173 个。
在 Flink CDC 2.3 版本中，咱们按代码的奉献模块进行了划分。其中 MySQL 占比最高达到了 24%，Oracle 占 15%，MongoDB 占 7%，TiDB 占 7%，蕴含全量框架的 Base 模块占比 11%。此外文档的奉献也占有 22% 的比例，其中包含新增了很多中文文档和视频教程，这些文档的目标就是为了帮忙用户特地是中文用户更好地应用 Flink CDC。
1.3 Flink CDC 2.3 技术改良
以下是 Flink CDC 2.3 版本中次要新个性和改良，包含：
- 反对了 Db2 数据源。
- Oracle CDC 反对增量快照。
- MongoDB CDC 反对增量快照。
- MySQL CDC 反对指定位点。
- MySQL CDC 性能优化。
- OceanBase CDC 反对了 OceanBase 的全副数据类型。
- 兼容 Flink 1.15 & 1.16 两个大版本。
- 提供中文文档及视频教程反对。
1.4 Flink CDC 2.3 外围个性解读
在 Flink CDC 2.3 版本中，有四大外围个性值得深刻介绍：
- 新增 Db2 数据源反对。
- MySQL CDC 稳定性晋升。
- Oracle CDC 反对增量快照读取。
- MongoDB CDC 反对增量快照读取。
上面将为大家进行具体解说。
第一局部，Db2 CDC 连接器。Db2 数据库在国内外都有很多用户在应用，社区用户反馈的声音也比拟大，所以在 Flink CDC 2.3 中版本中社区反对了 Db2。
Db2 CDC 的全量数据是通过 SQL 查问的形式拉取；而增量数据是当表开启了 Capture Mode 的时候，Db2 会把增量数据的 Changelog 写到 Change Table 里，在须要增量数据时，从 Change Table 中拉取 Changelog 即可。这样 Db2 CDC 就实现了全量数据和增量数据的一致性读取，在上游也提供了实时的一致性快照。
第二局部，MySQL CDC 稳定性晋升，对它的晋升次要包含以下四个方面。
- 反对指定位点启动，包含 timestamp、binlog offset、binlog gtid、earliest-offset 这这几种形式来指定位点。
- 稳定性晋升，包含主动获取服务器时区；反对全字符集；反对解析更宽容的默认值；边界条件下的数据一致性问题修复等改良。
- 分片算法优化，包含反对异步分片；反对自定义切分列；分片过程反对 Checkpoint。
- 性能晋升，包含 JM 内存优化；TM 全量阶段内存优化；Binlog 读取性能优化。
除了这两大外围个性，另外两个重点 Feature 就是 Oracle CDC 和 MongoDB CDC 均对接到了 Flink CDC 的增量快照框架。
Flink CDC 的增量快照框架的起源是 Flink CDC 2.0 版本提供的一个增量快照算法，它提供了无所读取、并发读取、断点续传三个外围个性。但过后只反对 MySQL CDC Connector 接入，其余 Connector 接入老本较高，所以社区就把这套算法形象成了一个框架，叫 Flink CDC 的增量快照框架，不便其余 Connector 接入。之后在 Flink CDC 2.3 版本中，社区便接入了 Oracle 和 MongoDB 两个数据源。
当初，Oracle 和 MongoDB 都反对在全量阶段进行并行读取。全量读取完之后，通过无所一致性切换到增量阶段。全量到增量的切换是全自动的，不须要人为干涉。
在接入 Oracle CDC 和 MongoDB CDC 到增量快照框架之后，Flink CDC 的增量快照框架反对的矩阵就变得相当丰盛，笼罩了包含 MySQL、MariaDB、PoloDB、ORACLE、MongoDB 等数据源。
二、基于 Flink CDC 构建古代数据栈
2.1 古代数据栈（Modern Data Stack）
数据栈这个概念在最近几年比拟炽热，特地是在海内数据集成的行业或者圈子里。首先看一下数据栈相干的两个概念。
数据栈是一组对原始数据进行采集、转换和存储 (ETL) 的技术或工具的组合，这些工具能够让数据工程师和分析师可能提取和荡涤数据，将原始数据转换为有价值的数据并存储，而后依据须要进行剖析。
古代数据栈是在数据栈的根底上，应用翻新的 (如 ELT) 或基于云上数仓 / 湖的工具或技术的组合，古代数据栈基于云上构建的特点，具备传统数据栈很难具备的弹性和扩容劣势，古代数据栈档次清晰有利于垂直畛域的工具造成规范的 SaaS 服务，而 SaaS 服务极大地升高了运维和治理老本。
2.2 古代数据栈组件
在刚刚介绍当初数据栈概念的时候，提到了两个词，ETL 和 ELT。
ETL 是经典数据集成里的一个处理过程，即采集、转换、存储。以 Flink CDC 为例，在传统的数据栈里做 ETL。Flink CDC 做采集的时候，如果还须要进一步转换，就通过 Flink 来做，而后 load 到上游存储。
转换到古代数据栈 ELT 的架构。还以 Flink CDC 为例，它负责采集和 load，即帮忙数据从数据源采集并 load 到存储里，这个存储包含 Iceberg、Hudi 等等。而转换个别都围绕在数据湖或者数据仓库上，所以能够用其余工具做一些转换，从而把 E 和 L 提取进去。
2.3 开源古代数据栈
上图是 State of Data Engineering 2022 map，在这个图里能够发现，有很多和古代数据栈或者数据集成畛域相干的技术和组件。比方 Airbyte、Fivetran 等等，既有开源的，也有闭源的。
上图是一个典型的开源古代数据栈，能够发现这个表里每一行都代表一个垂直畛域。比方咱们要做数仓，就能够用 rudderstack、Airbyte 等开源数据集成工具来做等等。
2.4 基于 Flink CDC 的古代数据栈
如上图所示，Flink CDC 是一个十分好的数据集成框架，它目前曾经反对了 MySQL、MongoDB、Db2 等丰盛的数据源，用户能够针对本人的需要抉择并对数据进行加工。
那么如何基于 Flink CDC 构建古代数据栈呢？如上图所示，数据栈的最底层是数据源，比方 MySQL、PG、Oracle、MongoDB 等等。EL 由 Flink CDC 来做，它负责从数据源里提取数据，load 到经典的数据仓库或者数据湖这层。
Transformation 通过 Flink、Spark 在数仓之上做剖析，而后通过 Superset、Metabase、Tabular 等等 BI 工具，对其后果进一步加工。加工完之后，最上层是面向终端用户的，比方各种利用的报表剖析、实时大屏、数据利用，这就形成了一个基于 Flink CDC 的古代数据栈。
三、阿里云外部实际和改良
3.1 常见业务场景的实际
场景一，海量 CDC 数据实时 ETL。通过 Flink CDC 表实时读取源表批改，用在实时作业里进行一些计算和解决，最终写入到上游数据仓库中。比方应用 Flink CDC 源表和其余实时数据流进行 Join，打宽业务表并写入上游数据库中。在这样的应用场景下，同一个作业可能会同时拜访数据库中的多张表，常常一个作业蕴含多个 CDC 表，同时持有多个 Binlog Client。
随着业务规模的一直扩大，开发的作业数量也会继续减少。但每个作业的 Binlog Client 是独占的，无奈进行复用，这会使连贯到数据库时 Binlog Client 也继续减少。最终导致数据库侧的压力继续减少，甚至影响数据库上承当的线上业务。
场景二，日志数据实时入湖入仓。用户通常会将日志先汇聚到音讯队列中，比方 Kafka，再从 Kafka 中生产进行剖析、归档，比方通过 Flink 实时生产日志数据后，归档到上游的数据仓库或者数据湖中。
在这样的场景下，用户开发一个作业的工夫会比拟长，须要的人力也会很多。首先须要手动创立好上游的存储表，在开发 SQL 作业时，须要编写对应的 Source 表，Sink 表的 CREATE TABLE 语句，参照不同连接器的需要，自行定义好表的 Schema 和须要应用的配置，并且这样的作业无奈同步 Schema 的变更。
以上图左侧为例，实现了从 Kafka_monitor_log 同步到 Hudi_monitor_log 的 Hudi 表的作业编写。首先要通过 CRATE TABLE 语句创立一张 Kafka 表，并定义好表的三个字段 id、event、level，以及 WITH 参数里表的一些配置。同样，在 Hudi 表的定义时还要进行这样反复的操作。
3.2 常见业务场景的扩大和改良
上图是阿里云外部基于 Flink CDC 的古代数据栈。除了前文介绍过的对开源局部的反对，阿里云外部还进行了一些额定的改良和扩大。
数据源方面，咱们不仅反对数据库，还反对了 Kafka 音讯队列，并且在采集层能够在实时计算 Flink 版中，启动 Flink CDC 作业进行采集，将数据采集到数据仓库中。除了常见的开源仓库对接，也提供了企业级实时数仓 Hologress 和音讯队列 Kafka 的反对。
在计算层，能够在实时计算 Flink 版中进行 SQL 作业的开发和数据分析解决。在剖析层，能够借助各种 BI 工具数据分析，最终对接终端实现报表剖析、实时大屏，或其余数据利用。
借助咱们外部基于 Flink CDC 的古代数据栈，解决了数据库 Flink CDC 数据集成和日志数据集成两大场景的痛点。
第一个场景是海量 CDC 数据的实时集成场景。在这个场景中，为了解决数据库压力过大的问题，咱们通过提供 Kafka JSON Catalog，联合 CTAS、CDAS 的整库同步语法，将上游的数据库的数据同步到 Kafka 中来进行解耦。将数据库中的热点表同步到 Kafka 后，后续应用到该表的作业能够间接生产对应的 Kafka Topic，从而升高了源头数据库的压力。
在 CDAS 这样一个整库同步的过程中，能够对 Binlog Client 进行复用，这样 Binlog Client 连贯就不再随着业务的扩大而减少，同时升高了 Binlog 的复制压力。另外，这样一个整库同步的作业，启动时只会进行一次全量的数据同步，不会每次作业启动都进行一次全增量的同步，升高了全量阶段产生的数据库查问压力。
开发这样一个整库同步作业只须要如上图所示。注册 Kafka JSON Catalog 和 MySQL Catalog 后，只须要简略的一条 SQL 就能够实现同步工作开发，节俭了开发者的开发工夫。
如上图右侧展现，MySQL 数据库里蕴含 Order、User、Address 三张数据表。在启动了 CDAS 整库同步作业后，Kafka JSON Catalog 会主动在 Kafka 集群里，创立 Order、User、Address 三个 Topic，而后进行 CDAS 作业的启动，把数据同步到对应的 Topic 中。
在存储时会以 JSON 格局存储数据。在 key 局部会存储对应的数据表主键，在 value 局部会存储除了主键以外的其余字段。后续的作业能够间接应用 Kafka 集群里的 Kafka 表实现作业的剖析和计算。
第二个场景是日志数据实时入湖入仓。通过 Kafka JSON Catalog 能够简略的应用 CTAS 或 CDAS 的整库同步语法同步数据到数据仓库，如数据湖 Hudi，这个过程极大地简化日志数据实时入湖入仓的开发难度，同时实现上咱们也对 Kafka Source 进行了合并优化（Source Merge），缩小了资源的应用。
上图展现了从 Kafka_monitor_log 同步日志数据到 Hudi 数据湖中的过程。在 Kafka_monitor_log 的 Topic 中，key 局部存在一个字段 id，value 局部有三个字段 id，event、level。同步作业会主动解析 Kafka 字段，并在 Hudi 中实现建表的操作，而后启动作业进行同步。
为了避免字段产生抵触，Kafka JSON Catalog 在解析 Schema 时，会在 key 的字段名前加 key_ 的前缀，在 value 字段增加 value_的前缀。同时会增加 Kafka 的元数据列，partition，offset 和 timestamp。
这样一个同步作业开发，只须要像上图右侧这样写一条 SQL，即 CREATE TABLE AS 语句，定义好从 Kafka 的哪张表，同步到上游 Hudi 数据湖中的哪张表即可。作业启动后，会主动在 Hudi 中创立表，并且会同步 Kafka 中的变动字段到 Hudi。极大升高了用户的开发难度和开发工夫。
四、Demo & 将来布局
4.1 Demo
上面针对之前提到的两个用户痛点场景进行 demo 展现，第一个 demo 次要展现：如何将数据库整库同步到 Kafka 进行数据打宽，最终解决写入到 Hudi 数据湖中。第二个 demo 次要展现：Kafka 中的日志数据如何整库同步到 Hudi 数据湖中。
Demo 演示：https://www.bilibili.com/video/BV1ej411c7jd
4.2 将来布局
将来 Flink CDC 2.4 版本在社区中的布局如下：
- 反对 Batch 模式，优化全量阶段的读取性能。
- 反对限流配置，缩小全量阶段对数据库的影响。
- 提供更丰盛的监控指标，如已解决的表数量，不同类型变更记录的解决数量等。
- 后续也会继续晋升 CDC Connector 的易用性和性能。如增量框架在全量阶段完结后的 reader 资源开释，更多的数据源利用增量快照框架等。
原文链接
本文为阿里云原创内容，未经容许不得转载。