前言:
主要讲解了技术原理,入门与生产实践,主要功能:全增量一体化数据集成、实时数据入库入仓、最详细的教程。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
-
- 离线调度查询作业,批处理。依赖表中的更新时间字段,每次执行查询去捕获表中的最新数据
- 无法捕获的是删除事件,从而无法保证数据一致性问题
- 无法保障实时性,基于离线调度存在天然的延迟
- 基于日志的CDC
-
- 实时消费日志,流处理。比如说MySQL里面的BinLog日志完整记录数据库中的数据变更,可以把binLog文件作为流的数据源
- 保障数据一致性,因为binLog文件中包含了所有历史变更明细
- 保障实时性,因为类似binLog的日志文件可以流式消费的,提供的实时数据
常见开源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,并未成功处理该结果的场景,可
以考虑将中间计算结果放在高可用的 DataStore 里。
下游去重,应对下游处理完消息后发生 failure,重复接收消息的场景,这种可通过给消息设置
SequcenceId 实现去重,或者下游实现幂等