先上一张图，后面再慢慢介绍：
CDC概述
CDC 的全称是 Change Data Capture ，在广义的概念上，只要能捕获数据变更的技术，我们都可以称为 CDC 。我们目前通常描述的CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。
CDC主要分以下两类
- 基于查询的 CDC：优点是实现简单，是通过批处理实现的，需要依赖离线调度，不能保证数据强一致性和实时性；
- 基于日志的 CDC：实现比较复杂，但是可以实时消费日志，流式处理，可保证数据一致性和实时性；
方案对比
目前市面上的CDC技术比较多，我们选取了几种主要的开源CDC方案做了对比，总体如下图：
如上图所示，从CDC机制、增量同步、断电续传、全量同步、全量+增量、架构、数据计算、生态这八个方面做了对比。可以看出其中的佼佼者主要是Flink CDC和Oracle OGG以及Debezium；
由于基于查询的CDC方案缺陷明显，这里不作讨论，下面我们对基于日志的CDC方案的优劣来做详细的介绍。
各方案优缺点
Flink CDC：Flink CDC是最近几年的新贵，Flink CDC 底层封装了 Debezium，功能比较全面，目前已经迭代到了2.4版本，社区活跃度在几个方案中是最高的；
- 优点：全、增量一体的分布式数据集成框架；同步时无需加锁；吞吐量大，适合海量数据实时同步；操作简单，SQL即可完成；具有强大的 transformation 能力，通过 Flink SQL 即可完成ETL 中的数据转换；有丰富的 Connector，除关系型数据库外，HBase、ClickHouse、TiDB等也支持，而且支持自定义 connector；
- 缺点：依赖Flink集群，数据量较大时对服务器要求较高；
Oracle OGG：Oracle OGG历史比较悠久，最初是设计用来从Oracle迁移数据到其它数据库，或者从其它平台迁移数据到Oracle，随着发展，目前已支持Mysql、Hadoop、Hive、Kafka登数据源；
- 优点：支持增量和全量同步，支持分布式，高性能，支持数据过滤和转化，是目前主流的实时同步方案之一；
- 缺点：支持的数据库比较少，像一些MongoDB、TiDB等不支持；
Debezium：Debezium最初设计成一个Kafka Connect 的Source Plugin，目前开发者虽致力于将其与Kafka Connect解耦，但当前的代码实现还未变动。下图引自Debeizum官方文档，可以看到一个Debezium在一个完整CDC系统中的位置。
- 优点：支持全量+增量同步；
- 缺点：全量同步时会加锁，而且加锁时间不确定，会严重影响业务；最重要的是跟Kafka等消息中间件强耦合，下游数据要经过Kafka；
Canal：主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。
- 优点：用于单一的MySQL环境做数据同步还不错；
- 缺点：缺点较为明显，只支持MySQL的CDC，只支持增量同步，全量需要用DataX或者Sqoop，全量和增量同步割裂；不支持分布式；