Press "Enter" to skip to content

基于FlinkCDC2.0+Flink SQL的实时采集与ETL解决方案

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

1.关系型数据库采集技术变迁史

 

1.1 关系型数据库数据采集的使用场景

 

错误使用场景

 

 

正确使用场景

 

 

1.2 CDC技术介绍

 

CDC 的全称是 Change Data Capture ,广义上,只要是能捕获数据变更的技术,我们都可以称之为 CDC 。我们通常描述的 CDC 技术是一种用于捕获数据库中数据变更的技术,主要是面向关系型数据库。CDC 技术的应用场景非常广泛,主要包括:

 

1.数据同步:用于灾备

 

2.数据分发:一个数据源分发给多个下游系统

 

3.数据采集:采集数据到数据仓库 / 数据湖

 

1.3 CDC技术变迁

 

 

1.4 基于触发器实现CDC(老黄历了)

 

触发器方式是早期普遍采取的一种增量抽取机制。该方式是根据抽取要求,在要被抽取的源表上建立插入、修改、删除3个触发器,每当源表中的数据发生变化,就被相应的触发器将变化的数据写入一个增量日志表,ETL的增量抽取则是从增量日志表中而不是直接在源表中抽取数据,同时增量日志表中抽取过的数据要及时被标记或删除。

 

为了简单起见,增量日志表一般不存储增量数据的所有字段信息,而只是存储源表名称、更新的关键字值和更新操作类型(insert、update或delete),ETL增量抽取进程首先根据源表名称和更新的关键字值,从源表中提取对应的完整记录,再根据更新操作类型,对目标表进行相应的处理。

 

CREATE OR REPLACE TRIGGER TRI_T_ETL_YB

 

BEFORE INSERT OR UPDATE OR DELETE ON T_ETL_YB

 

FOR EACH ROW

 

DECLARE

 

CZLX VARCHA2(1); — 定义操作类型

 

BEGIN

 

— 插入日志表(ID,操作时间,操作类型)

 

IF DELETING THEN INSERT INTO ETL_LOG(ID,CZSJ,CZLX) VALUES (:old.ID,sysdate,’D’);

 

ELSE IF UPDATING THEN INSERT INTO ETL_LOG(ID,CZSJ,CZLX) VALUES (:old.ID,sysdate,’U’);

 

ELSE IF INSERTING THEN INSERT INTO ETL_LOG(ID,CZSJ,CZLX) VALUES (:new.ID,sysdate,’I’);

 

END IF;

 

END;

 

1.5 基于查询实现CDC

 

增量字段方式来捕获变化数据,原理就是在源系统业务表数据表中增加增量字段,增量字段可以是时间字段(updatetime),同时也可以是自增长字段(如oracle的序列),设计要求就是源业务系统中数据新增或者被修改时,增量字段就会产生变化,时间戳字段就会被修改为相应的系统时间,自增长字段就会增加。 每当ETL工具进行增量数据获取时,只需比对最近一次数据抽取的增量字段值,就能判断出来哪些是新增数据,哪些是修改数据。这种数据抽取方式的优点就是抽取性能比较高,判断过程比较简单,最大的局限性就是由于某些数据库在进行设计的时候,未考虑到增量字段,需要对业务系统进行改造,基于数据库其他方面的原因,还有可能出现漏数据的情况。

 

 

1.6 基于日志实现CDC

 

这里以Canal实现MySQL数据增量采集的原理来说明基于日志的CDC的原理,其它数据库的采集原理也是类似的。

 

 

1.7 CDC实现机制的比较

 

 

注意:触发器实现方式已经没人使用,这里就不赘述了

 

2.常见CDC方案盘点与对比

 

2.1 Sqoop

 

 

2.2 DataX

 

 

2.3 canal

 

 

2.4 Debezium

 

 

2.5 常见CDC方案比较

 

 

3.基于Flink CDC2.0的实时采集与ETL方案

 

3.1 传统基于CDC的ETL方案

 

 

传统的基于 CDC 的 ETL 分析中,数据采集工具是必须的,国外用户常用 Debezium,国内用户常用阿里开源的 Canal,采集工具负责采集数据库的增量数据,一些采集工具也支持同步全量数据。采集到的数据一般输出到消息中间件如 Kafka,然后 Flink 计算引擎再去消费这一部分数据写入到目的端,目的端可以是各种 DB,数据湖,实时数仓和离线数仓。

 

注意,Flink 提供了 changelog-json format,可以将 changelog 数据写入离线数仓如 Hive / HDFS;对于实时数仓,Flink 支持将 changelog 通过 upsert-kafka connector 直接写入 Kafka。

 

 

存在的问题:

 

(1)依赖各种第三方采集工具

 

1)MySQL:Debezium/Canal/Maxwell

 

2)Oracle:OGG

 

3)其他

 

(2)采集链条长,依赖组件多导致可维护性降低、实效性变差

 

3.2 基于Flink CDC的ETL方案

 

 

Flink CDC1.0主要想解决三个方面的问题:

 

(1)统一采集工具:封装Debezium支持主流的数据库

 

(2)简化ETL链路:将采集工具和Kafka整体替换

 

(3)降低使用门槛:支持Flink SQL大大降低使用门槛

 

 

当然,基于Flink CDC的方案可以充分Flink强大的流计算能力进行各种运算。

 

3.3 基于Flink CDC的ETL方案存在的问题

 

 

Flink CDC2.0通过无锁算法解决了上述问题,建议大家使用Flink CDC2.0。

 

 

4.基于FlinkCDC2.0+Flink+Hudi数据实时入湖方案

 

Be First to Comment

发表评论

您的电子邮箱地址不会被公开。