数据同步方案
| 开源方案 | Flink CDC | Debezium | DataX | Canal | Sqoop | Kettle | Oracle Goldengate（OGG） | | --- | --- | --- | --- | --- | --- | --- | --- | | CDC机制 | 日志 | 日志 | 查询 | 日志(mysql) | 查询 | 查询 | 日志(oracle) | | 增量同步 | ✓ | ✓ | ✓(侵入业务&T+1) | ✓ | ✓(侵入业务&T+1) | ✓(侵入业务&T+1) | ✓ | | 断点续传 | ✓ | ✓ | ✕ | ✓ | ✕ | ✕ | ✓ | | 全量同步 | ✓ | ✓ | ✓ | ✕ | ✓ | ✓ | ✓ | | 全量+增量 | ✓ | ✓ | ✕ | ✕ | ✕ | ✕ | ✓ | | 架构 | 分布式 | 单机 | 分布式 | 单机 | 分布式 | 分布式 | 分布式 | | 数据转换/清 洗 | 强 | 弱 | 弱 | 弱 | 弱 | 弱 | 较弱 |
| CDC组件/方案 | 所属类型 | 核心原理 | 主要优点 | 主要缺点 |
|---|---|---|---|---|
| Sqoop | 基于查询的CDC | 底层将导入/导出命令翻译成MapReduce程序，实现Hadoop与关系型数据库间数据传输，支持多种数据格式转换 | 1. 命令行界面简单易用，简化数据传输；<br>2. 并行处理技术提升传输效率；<br>3. 保持数据完整性和一致性 | 1. 仅支持批量同步，错误率无法控制（事务原子性）；<br>2. 数据类型转换存在限制，可能导致数据丢失或格式错误；<br>3. 依赖JDBC驱动，兼容性受影响；<br>4. 大规模数据传输时扩展性不足 |
| DataX | 基于查询的CDC | 采用Framework + Plugin架构，Reader采集数据源数据，Writer写入目标端，Framework处理缓冲、流控等核心问题 | 1. 支持多种数据源和目标（关系型数据库、Hadoop、Hive等）；<br>2. 分布式架构，多任务并行，传输效率高；<br>3. 配置选项丰富，灵活可扩展 | 1. 需具备编程和配置能力，学习成本较高；<br>2. 对网络带宽和计算资源要求高，资源不足会影响性能 |
| Kettle（Pentaho Data Integration） | 基于查询的CDC | 开源ETL工具，通过预定义转换步骤，提取源系统数据，经清洗转换后加载到目标系统 | 1. 可视化界面，拖放操作构建流程，无需复杂代码；<br>2. 优化ETL引擎，支持并行处理，处理效率高；<br>3. 支持多数据源/目标，转换步骤和插件丰富，灵活性强 | 1. 非技术人员学习和使用成本较高；<br>2. 数据转换需大量计算资源，资源不足影响吞吐量；<br>3. 复杂数据清洗/转换需自定义代码 |
| Canal | 基于日志的CDC | 解析数据库binlog日志，捕获增删改操作，转化为JSON等可读格式供其他应用消费 | 1. 实时捕获增量数据变更，及时性强；<br>2. 支持多数据库/表同步，配置管理灵活；<br>3. 基于日志解析，数据同步准确一致；<br>4. 日志解析算法高效，延迟低 | 1. 需具备数据库和日志解析知识，学习成本高；<br>2. 复杂同步场景下配置和管理复杂；<br>3. 依赖数据库日志服务（如MySQL binlog），部署维护复杂；<br>4. 需开启账号日志复制权限，企业数据控制严格时难以实现 |
| Maxwell | 基于日志的CDC | 监听数据库binlog日志，转换为可读格式（JSON等），轻量级设计，支持更多配置方式 | 1. 实时捕获增量变更，数据同步及时；<br>2. 支持JSON、AVRO、CSV等多种数据类型；<br>3. 提供友好API和命令行工具，操作便捷；<br>4. 日志解析确保数据准确一致，性能高、延迟低 | 1. 依赖MySQL binlog，binlog异常会影响功能；<br>2. 仅支持MySQL 5.5及以上版本，兼容性有限；<br>3. 需掌握数据库和日志解析知识，学习成本较高 |
| Debezium | 基于日志的CDC | Red Hat开源分布式工具，通过Connector监听数据库事务日志，捕获变更事件，转换为JSON格式发送到Kafka等介质 | 1. 实时捕获变更事件，生成实时数据流；<br>2. 基于事务日志，数据同步准确一致；<br>3. 支持MySQL、PostgreSQL、Oracle等多种数据库；<br>4. 架构支持水平扩展，可处理大规模数据变更 | 1. 配置复杂，需了解数据库事务日志和相关参数；<br>2. 依赖数据库事务日志，需保证日志可靠性；<br>3. 实时监控日志可能影响数据库性能 |
| Databus | 基于日志的CDC | LinkedIn开源数据总线平台，Agent进程监听数据源，捕获增删改事件，转换为JSON格式发送到Kafka等消息队列 | 1. 具备数据检验、重传、压缩等机制，可靠性高；<br>2. 支持水平扩展，兼容多数据源/目标，配置灵活；<br>3. 数据压缩、内存缓存优化，传输处理效率高；<br>4. 支持命令行、配置文件等多种配置方式 | 1. 占用CPU、内存、磁盘空间等系统资源较多；<br>2. 需学习系统架构、配置文件等，学习成本高 |
| Apache SeaTunnel | 基于日志的CDC | 支持全量/增量同步、流批一体，分布式架构依托Flink/Spark/Zeta引擎，零代码配置，含状态保存和两阶段提交机制 | 1. 简单易用，无需开发，配置灵活；<br>2. 模块化、插件化设计；<br>3. 支持SQL数据处理和聚合；<br>4. 兼容异构数据源，同步接入快速；<br>5. 抽象业务逻辑，减少代码冗余 | 1. 数据清洗逻辑简单，不支持复杂清洗需求；<br>2. 需自行解决Spark/Flink版本适配问题；<br>3. 需掌握参数调优知识以提升作业效率 |
| Chunjun（原FlinkX） | 基于日志的CDC | 基于Flink的分布式批流一体框架，抽象Reader/Writer插件，实现异构数据源高效迁移 | 1. 基于Flink，实时性较好；<br>2. 分布式架构，数据同步性能高 | 无明确突出缺点（文档未详细说明） |
| Flink CDC | 基于日志的CDC | 全量同步使用MySQL Dump，增量同步监听binlog日志，无需额外部署，直接对接Flink进行数据加工 | 1. 无需部署，维护成本低，链路简洁；<br>2. 原生支持Flink，可使用DataStream API/FlinkSQL；<br>3. 实时性较好，支持全量+增量一体化同步 | 无明确突出缺点（文档未详细说明） |
对于异常状态段，任务可以配置状态后端的 checkpoint
