基于流计算 Oceanus（Flink） CDC 做好数据集成场景

作者：黄龙，腾讯 CSIG 高级工程师

数据时代，企业对技术创新和服务水准的要求不断提高，数据已成为企业极其重要的资产。无论是在在企业数据中台的建设，亦或者是打造一站式数据开发和数据治理的PASS平台。首先需要做的就是进行跨应用的数据融合计算，需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地。此过程称之为ETL。通常所说的同步大致分为离线全量ETL、离线增量+离线全量的ETL、实时增量+离线全量ETL、实时增量ETL4种方式。数据同步成为企业数据开发和使用一个绕不过去的技术需求。业内也存在大量的开源的解决方案。在数据集成技术选型中，我们需要考虑的因素有哪些？主流开源方案中各自的优缺点有哪些？目前备受瞩目和推崇 Flink CDC ETL 是否能作为线上主力同步工具之一，它的优势有哪些？原理是什么？本文主要围绕以上几个疑问，进行论述。

1. 如何做好数据集成技术选型

常见的数据同步常包含以下场景：

1. 数据库的备份，容灾

2. 业务系统经常会遇到需要更新数据到多个存储的需求

3. 面向数仓/数据湖的ETL数据集成

在面对众多开源的数据同步产品工具时，我们如何做好技术选型，以及我们评判的标准或者说打分项有哪些？这里先按照通用的准则列举如下：

1. 是否支持增量+全量的数据同步能力

2. 同步的机制是什么？基于日志还是基于查询

3. 是否支持分布式的数据接入能力

4. 数据转换 / 数据清洗能力

5. 数据一致性的保证

6. 系统的复杂度，包含使用复杂度。

7. 数据同步链路( 更长的链路一般意味着，风险增高以及监控成本增加 )

8. 生态的丰富性

9. 是否对线上生产环境产生大的影响

10. 社区的活跃度，商业化的使用案例

基于以上的考量，再回到本文的想要表达的中心议题，我们想了解一下，Flink CDC 作为孵化才一年多的项目，为何在如此短的时间内受到如此多的关注以及如此迅猛发展 ？它是解决了数据同步场景的那些问题 ？有哪些优势 ？原理是什么？以及为何建议作为数据同步场景下的主力生产工具之一 ？

2. CDC 技术介绍

1. 定义

CDC 的全称是 Change Data Capture ，在广义的概念上，只要是能捕获数据变更的技术，我们都可以称之为 CDC。目前通常描述的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。CDC大体分为两种：侵入式和非侵入式。侵入式指 CDC 操作会给源系统带来性能影响，只要 CDC 操作以任何一种方式对源数据库执行了SQL 操作，就认为是侵入式的。一般基于查询的实现机制都归纳为入侵式，例如 DataX，Sqoop。基于日志的实现机制都归纳到非侵入式，典型的有 Canal，Debezium。

2. 主流的实现机制

CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种:

• 基于查询的 CDC：

  基于查询的 cdc 通常需要和调度系统搭配使用，常见的方式有基于时间戳的 CDC、基于触发器的 CDC、基于快照的 CDC。由于时效性比较差，而且在保证数据一致性方面具有天然的劣式(因为查询的过程中数据可能已经发生多次变更），数据的一致性须有整个调度链上下游一起辅助实现。所以一般离线的调度场景会用的会比较多。例如于调度查询作业，离线数仓等。

• 基于日志的 CDC：

  在业务系统中添加系统日志，当业务数据发生变化时，更新维护日志内容，当 ETL 加载时，通过读日志表数据决定需要加载的数据及加载的方式。例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把 binlog文件当作流的数据源，通过对 MySQL Binlog 进行实时采集，然后对接一些实时计算引擎或者 APP 进行消费后把数据传输入 OLAP 系统或者其他存储介质。

  优点：整个链路可以做到实时增量的 ETL 处理，实效性有保证，这对于一些对时效性要求比较高的应用场景非常适合。同时在数据一致性方面也是更有保证，因为 binlog文件包含了所有历史变更明细，可以根据日志的位点信息进行回溯和重放操作。并且基于日志的 CDC 在增量同步阶段是非入侵式的，对系统的性能影响是比基于查询的 CDC 要好很多。

3. 常见的开源 CDC 方案对比

	Flink CDC	Debezium	DataX	Canal	Sqoop	Kettle	Oracle Goldengate
实现机制	日志	日志	查询	日志	查询	查询	日志
全量同步	✔️	✔️	✔️	❌	✔️	✔️	✔️
增量同步	✔️	✔️	❌	✔️	✔️	❌	✔️
断点续传	✔️	✔️	❌	✔️	❌	❌	✔️
架构	分布式	单机	单机	单机	分布式	分布式	分布式
清洗/转换/聚合	⭐️⭐️⭐️	⭐️⭐️	⭐️⭐️	⭐️⭐️	⭐️⭐️	⭐️	⭐️
生态	⭐️⭐️⭐️	⭐️⭐️	⭐️⭐️	⭐️⭐️	⭐️	⭐️	⭐️⭐️

从上面表格的对比分析看，Flink CDC 的方案具有很大的优势。笔者认为这种优势主要来源有：  1.架构的先进行  2.集合了当下主流热门的技术优势  我们以腾讯云， 云上全托管流计算 Oceanus(Oceanus 是云上基于 Apache Flink 构建的高性能企业级实时大数据分析平台，并且采用的是云原生容器化部署模式) 为例来阐述一下 Flink CDC 方案的优越性。

4. Flink CDC 优势分析

4.1. Flink CDC 数据采集端的底层使用的是 Debezium

Flink 的应用程序结构，有 Source（源头）、Transformation（转换）、Sink（接收器）三个重要组成部分。Source 定义 Flink 从哪里加载数据，是以定义独立 Connector Jar 包通过 SPI方式和Flink 进行解耦。flink-cdc-connectors 就是自定义的 Source Connector 的插件化独立工程，其底层是用到了 Debezium 来对数据进行采集。  Debezium 是一个基于日志的 CDC 工具，将现有的数据库转换为事件流，可以捕捉到数据库中的每一个行级更改并立即做出响应，主要的特性有:

• 捕获所有数据更改(包括删除)

• 低延迟生成更改事件，同时避免增加频繁轮询的CPU使用量

• 可以捕获旧记录状态和其他元数据

• 不需要更改数据模型

• 变更事件可以序列化为不同的格式，例如 JSON 或 Apache Avro

Flink CDC 最终选择了 Debezium 作为 Flink CDC 的底层采集工具࿰