Flink CDC 新一代数据集成框架-Toy模板网

这篇具有很好参考价值的文章主要介绍了Flink CDC 新一代数据集成框架。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

前言：

主要讲解了技术原理，入门与生产实践，主要功能：全增量一体化数据集成、实时数据入库入仓、最详细的教程。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

1. 离线调度查询作业，批处理。依赖表中的更新时间字段，每次执行查询去捕获表中的最新数据
2. 无法捕获的是删除事件，从而无法保证数据一致性问题
3. 无法保障实时性，基于离线调度存在天然的延迟

基于日志的CDC

1. 实时消费日志，流处理。比如说MySQL里面的BinLog日志完整记录数据库中的数据变更，可以把binLog文件作为流的数据源
2. 保障数据一致性，因为binLog文件中包含了所有历史变更明细
3. 保障实时性，因为类似binLog的日志文件可以流式消费的，提供的实时数据

常见开源CDC方案比较

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，并未成功处理该结果的场景，可