文章目录
- 聊聊数据集成的发展和未来
- CDC概述
- 目前业内主流的CDC实现机制
- 常见的开源CDC方案对比
聊聊数据集成的发展和未来
在信息爆炸的时代，为了从海量数据中洞察业务价值，驱动运营决策，企业通常会构建用于数据分析的数据仓库。
数据仓库的数据一般来源于多个分散的、异构的数据源，通过数据集成技术将数据整合在一起，消除数据孤岛，便于后续的分析。近年来，面向分析的数据系统发展迅速，各种新型的 OLAP 系统开始显露锋芒，数据湖和 Lakehouse 的概念也变得炙手可热。然而，数据集成仍然是人们通往数据分析之路上的主要障碍。
构建一个中心化的数据仓库本身是一个艰巨的任务，每个数据源都需要单独的程序和工具来摄取、清洗和导入数据。尤其是随着业务的发展，企业对于数据实时性的要求越来越高。
在 2021 年 6 月，Apache 董事会宣布决定终止 Apache Sqoop 项目，以 Apache Sqoop 为代表的传统离线数据同步开始退出历史舞台。这也代表着传统的离线数据同步已经无法满足用户的需求，人们开始追求更为实时的数据同步方案。
基于数据库事务日志的 Change Data Capture (CDC) 技术作为一种更为优雅和先进的实时数据同步方案，开始广泛应用于增量数据集成中。
然而诸如 Canal 等专注于纯增量数据同步的开源项目也逐渐面临活跃度越来越低的困境，因为用户想要集成的数据从来不是单独的历史数据部分，或是单独的增量数据部分，而是历史数据和增量数据一体化地集成到数据仓库。这也是为什么如 Debezium、Flink CDC 等全增量一体化数据集成框架能越来越受欢迎的原因之一。
CDC概述
CDC 的全称是 Change Data Capture ，在广义的概念上，只要是能捕获数据变更的技术，我们都可以称之为 CDC 。目前通常描述的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。CDC 技术的应用场景非常广泛：
- 数据迁移：常用于数据库备份、容灾等；
- 数据分发：将一个数据源分发给多个下游，常用于业务解耦、微服务；
- 数据采集：将分散异构的数据源集成到数据仓库中，消除数据孤岛，便于后续的分析。
目前业内主流的CDC实现机制
目前业界主流的 CDC 实现机制可以分为两种：
- 基于查询的 CDC：
- 离线调度查询作业，批处理。依赖表中的更新时间字段，每次执行查询去获取表中最新的数据；
- 无法捕获删除事件，从而无法保证数据一致性；
- 无法保障实时性，基于离线调度存在天然的延迟。
- 基于日志的 CDC：
- 实时消费日志，流处理。例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把binlog 文件当作流的数据源；
- 保障数据一致性，因为 binlog 文件包含了所有历史变更明细；
- 保障实时性，因为类似 binlog 的日志文件是可以流式消费的，提供的是实时数据。
常见的开源CDC方案对比
- DataX 不支持增量同步，Canal 不支持全量同步。虽然两者都是非常流行的数据同步工具，但在场景支持上仍不完善。
- 在全量+增量一体化同步方面，只有 Flink CDC、Debezium、Oracle Goldengate 支持较好。
- 在架构方面，Apache Flink 是一个非常优秀的分布式流处理框架，因此 Flink CDC 作为Apache Flink 的一个组件具有非常灵活的水平扩展能力。而 DataX 和 Canal 是个单机架构，在大数据场景下容易面临性能瓶颈的问题。
- 在数据加工的能力上，CDC 工具是否能够方便地对数据做一些清洗、过滤、聚合，甚至关联打宽？Flink CDC 依托强大的 Flink SQL 流式计算能力，可以非常方便地对数据进行加工。而Debezium 等则需要通过复杂的 Java 代码才能完成，使用门槛比较高。
- 另外，在生态方面，这里指的是上下游存储的支持。Flink CDC 上下游非常丰富，支持对接MySQL、PostgreSQL 等数据源，还支持写入到 TiDB、HBase、Kafka、Hudi 等各种存储系统中，也支持灵活的自定义 connector。
