持续分享有用、有价值、精选的优质大数据干货
致力于打造全网最优质的大数据专题

目录

一、Flink CDC概述

(一)Flink CDC是啥

(二)⽀持的连接器

1、最新稳定版2.1.1⽀持列表

2、即将发布的2.2.0⽀持列表(master分⽀)

(三)支持的Flink版本

 二、为什么需要Flink CDC

(一)传统CDC的不足

(二)Flink CDC采集方案

三、常见CDC方案比较

一、Flink CDC概述

(一)Flink CDC是啥

        Flink CDC是Flink社区开发的flink-cdc-connectors 组件,这是⼀个可以直接从 MySQL、PostgreSQL 等数据库直接读取全量数据和增量变更数据的 source 组件。
        ⽬前也已开源,开源地址:
        https://github.com/ververica/flink-cdc-connectors
        以下是官⽹:
        https://ververica.github.io/flink-cdc-connectors/master/

(二)支持的连接器

 1、最新稳定版2.1.1⽀持列表

2、即将发布的2.2.0支持列表(master分支)

(三)支持的Flink版本

 二、为什么需要Flink CDC

(一)传统CDC的不足

        传统的基于 CDC 的 ETL 分析中,数据采集⼯具是必须的,国外⽤户常⽤ Debezium,国内⽤户常⽤阿⾥开源的Canal,采集⼯具负责采集数据库的增量数据,⼀些采集⼯具也⽀持同步全量数据。采集到的数据⼀般输出到消息中间件如 Kafka,然后 Flink 计算引擎再去消费这⼀部分数据写⼊到⽬的端,⽬的端可以是各种 DB,数据湖,实时数仓和离线数仓。
        注意, Flink 提供了 changelog-json format,可以将 changelog 数据写⼊离线数仓如 Hive / HDFS;对于实时数仓, Flink ⽀持将 changelog 通过 upsert-kafka connector 直接写⼊ Kafka。

        Flink CDC的基本理念就是去替换上图中虚线框内的采集组件和消息队列,从⽽简化传输链路,降低维护成本。同时更少的组件也意味着数据时效性能够进⼀步提⾼。

(二)Flink CDC采集方案

Flink CDC1.0主要想解决三个⽅⾯的问题:
(1)统⼀采集⼯具:封装Debezium⽀持主流的数据库
(2)简化ETL链路:将采集⼯具和Kafka整体替换
(3)降低使⽤⻔槛:⽀持Flink SQL⼤⼤降低使⽤⻔槛

        基于FlinkCDC,我们只需要通过⼀个 Flink SQL 作业就完成了 CDC 的数据采集,加⼯和同步,下⾯是⼀个例⼦:

--需求:同步MySQL的orders表到TiDB的orders表
--1、定义MySQL中orders表的cdc源表
CREATE TABLE mysql_orders (
id INT NOT NULL,
product_id BIGINT,
...
PRIMARY KEY(id)
) WITH (
'connector' = 'mysql-cdc',
'hostname' = 'xx',
'port' = '3306',
'username' = 'xx',
'password' = 'xx',
'database-name' = 'xx',
'table-name' = 'orders'
);
--2、创建TiDB结果表
CREATE TABLE tidb_orders(
id INT NOT NULL,
product_id BIGINT,
...
PRIMARY KEY(id)
)
WITH (
'connector' = 'jdbc',
'url' = 'jdbc:mysql://localhost:3306/xx',
'table-name' = 'orders'
);
--3、从源表读取数据写⼊结果表
INSERT INTO tidb_orders
SELECT * FROM mysql_orders;

        所以基于Flink CDC的⽅案是⼀个纯 SQL 作业,⼤⼤降低了降低了使⽤⻔槛。当然,我们也可以利⽤ Flink SQL 提供的丰富语法进⾏数据清洗、分析、聚合,⽽不仅仅是简单的数据同步。利⽤ Flink SQL 双流 JOIN、维表 JOIN、UDTF 语法可以⾮常容易地完成实时打宽,以及各种业务逻辑加⼯。

三、常见CDC方案比较

1、对⽐增量同步能⼒
        (1)基于⽇志的⽅式,可以很好的做到增量同步(准实时);
        (2)⽽基于查询的⽅式必须侵⼊业务才能做到增量同步的,⽽且是T+1的增量同步。

2、对⽐全量同步能⼒,基于查询或者⽇志的 CDC ⽅案基本都⽀持,除了 Canal。

3、⽽对⽐全量 + 增量同步的能⼒,只有 Flink CDC、 Debezium、 Oracle Goldengate ⽀持较好。

4、从架构⻆度去看,该表将架构分为单机和分布式,这⾥的分布式架构不单纯体现在数据读取能⼒的⽔平扩展上,更重要的是在⼤数据场景下分布式系统接⼊能⼒。例如 Flink CDC 的数据⼊湖或者⼊仓的时候,下游通常是分布式的系统,如 Hive、 HDFS、 Iceberg、 Hudi 等,那么从对接⼊分布式系统能⼒上看, Flink CDC 的架构能够很好地接⼊此类系统。

5、在数据转换 / 数据清洗能⼒上,当数据进⼊到 CDC ⼯具的时候是否能较⽅便的对数据做⼀些过滤或者清洗,甚⾄聚合?
        (1)在 Flink CDC 上操作相当简单,可以通过 Flink SQL 去操作这些数据;

        (2)但是像 DataX、 Debezium 等则需要通过脚本或者模板去做,所以⽤户的使⽤⻔槛会⽐较⾼。

6、另外,在⽣态⽅⾯,这⾥指的是下游的⼀些数据库或者数据源的⽀持。 Flink CDC 下游有丰富的 Connector,例如写⼊到 TiDB、 MySQL、 Pg、 HBase、 Kafka、 ClickHouse 等常⻅的⼀些系统,也⽀持各种⾃定义connector。

持续分享有用、有价值、精选的优质大数据干货
致力于打造全网最优质的大数据专题

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐