先上一张图,后面再慢慢介绍:
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,全量和增量同步割裂;不支持分布式;
版权归原作者 白杨Shayne 所有, 如有侵权,请联系我们删除。