引言：
此篇文章是基于公司内部分享的实际ppt整理而得，在公司内部已经实际运行几个月之久，效果比较明显，是一套比较纯粹的数据实时同步系统，核心组旨高效进行数据同步，而不是在数据同步过程中对数据进行处理。由于内容较多分为几篇列出：
- 《异构数据源的CDC实时同步系统》 系列第一篇 （已完成）
- 《零编码打造异构数据实时同步系统——异构数据源CDC之2》 系列第二篇（已完成）
- 《零编码打造异构数据实时同步系统——异构数据源CDC之3》 系列第三篇（已完成）
- 《零编码打造异构数据实时同步系统——异构数据源CDC之4》 系列第四篇
一、什么是CDC，和传统的ETL系统有什么区别
数据变更抓取(change data capture, CDC): 通过数据源的事务日志抓取数据源变更，这能解决一致性问题(只要下游能保证变更应用到新库上)。它的问题在于各种数据源的变更抓取没有统一的协议，如 MySQL 用 Binlog，PostgreSQL 的WAL日志，最新版本用 Logical decoding 机制，MongoDB 里则是 oplog。
ETL目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。生产实践中多为从业务系统抽取数据到数仓的过程
采用CDC系统一般对实时性要求比较高，不希望对业务系统有影响；而传统的etl系统优势在于流程控制和中间处理过程的灵活性，性能反而不是追求的极致目标。
二、常见ETL工具对比
kettle是一个比较经典的etl工具，在数据同步场景下引用比较多，也是etl场景下使用最多的工具
dataX是阿里主推的开源工具，操作比较简单，在国内有着不错的应用
streamset是一套功能比较齐全，我个人比较推荐的系统，在etl场景下可以接入的数据源是最全的，你能想到的数据源基本都可以找到，中间大数据库场景下的中间组件如kafka也都涵盖在内，同时工作流的布局方式也是比较好的。
三、CDC工具对比
在工具调研的过程中，是需要面对一个具体的应用场景下，然后再谈方案的优劣的。我们面对的场景就是如何最快速度下，支持最大并发下的异构数据可以尽快进入到我们的MPP数仓体系中。这里我们选型的几个诉求：
- 同时支持多个异构数据源的数据流转
- 配置简单，最好支持零编码
- 性能强大，能支持高并发处理
- 最好支持实时流转处理
在面对这样的场景需求下，我们主要对下面的几个方案进行了调研：
1.各工具在整体数据系统中的位置和作用
其中greenplum是MPP系统的目的端，mysql为源端（当然我们期望可以支持越多的源是最好的），从这个图中我们可以看到，其中各个工具的作用，rds_dbsync、mysql_dfw和go-mysql-pgsql这三个工具不借助中间MQ，是采用自身的作用实现，虽然可以满足mysql-gpdb（postgresql），但系统的扩展性不强，仅实现固定源、目的端的同步，下面分别就各个工具说明：
2.rds_dbsync介绍
这个组件是我们目前在系统中应用范围最广的一个组件，它即可以实现直接的数据同步也可以实现基于解析binlog的CDC同步。它的特点非常突出，下面仅以直接数据同步说明：
- 配置非常简单，仅需要配置mysql和gpdb的地址账号信息即可
- 可以自由设置读取的表、列信息，同时可支持远端和目的端的表不同名、列不同名情况
- 可以自由设置并行度，效率非常高，默认并行开启5个线程读取数据
- 可自动生成基于postgresql语法的目的ddl，对分布式的postgresql（greenplum），也可以生成对应的ddl语句，非常方便
实际编辑的文件只有2个：my.cfg和loader_init.txt，其中txt文件可以自由指定
./mysql2pgsql -d -n -f #生成对应的ddl语句
./myssql2pgsql -l loader_init.txt #默认开启5个线程读取mysql数据插入到postgresql
#对应参数
-l 指定加载的table文件，不一定是loader_init.txt可以是任意名称
-j 指定线程数，默认是5
-d 获取ddl语句，不获取数据
-n 在生成ddl语句不指定分区
-f 在ddl语句生成过程中使用第一列作为分布键，在生成greenplum的ddl语句中非常有用
-s 指定目的端的schema，比如数据要导入到newschema.testtable下，需要增加参数 -s newschema
-b 指定buffer大小，单位KB，一般不需要额外指定#loader_init.txt使用说明
#常规用法
tableA
tableB
#源端和目的端表名不一致
destA:sourceA
#只同步部分列数据
destA:select colA,colB from sourceA
#只同步部分行数据
destA:select * from sourceA where colA>100在非实时同步场景下，rds_dbsync表现优异，这个早年阿里开源的工具性能一直很好，但是长时间没有维护了，在CDC场景下的表现有很多问题：
- 配置需要中间搭建一个postgresql的中转库
- 需要在my.cfg中指定中转库的信息
- 在极限场景下，解析binlog会出现异常，导致对mysql的连接会出现雪崩式的增加，拖垮mysql，这也是我们最早尝试也最终放弃它的原因
