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