基于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数据实时入湖方案

本文有对应的免费视频课程讲解，需要的同学可以扫描添加下方微信。

想了解更多大数据技术，如大数据架构、湖仓一体化、流批一体、离线+实时数仓等等，可以扫描添加下面微信。