一、引入 Flink CDC 的背景
img
公司引入 CDC 技术，主要基于以下四个角色的需求：
物流科学家：需要库存、销售订单、物流账单等数据用于做分析。
开发：需要同步其他业务系统的基本信息。
财务：希望财务数据能够实时传送到财务系统，而不是月结前才能看到。
老板：需要数据大屏，通过大屏查看公司的业务和运营情况。
img
CDC 是数据捕获变更的技术。广义上来说，但凡能够捕获数据变更的技术，都能被称为 CDC。但通常我们说的 CDC 技术主要面向数据库的变更。
CDC 的实现方式主要有两种，分别是基于查询和基于日志：
基于查询：查询后插入、更新到数据库即可，无须数据库的特殊配置以及账号权限。它的实时性基于查询频率决定，只能通过提高查询频率来保证实时性，而这必然会对 DB 造成巨大压力。此外，因为是基于查询，所以它无法捕获两次查询之间数据的变更记录，也就无法保证数据的一致性。
基于日志：通过实时消费数据的变更日志实现，因此实时性很高。而且不会对 DB 造成很大的影响，也能够保证数据的一致性，因为数据库会将所有数据的变动记录在变更日志中。通过对日志的消费，即可明确知道数据的变化过程。它的缺点是实现相对复杂，因为不同数据库的变动日志实现不一样，格式、开启方式以及特殊权限都不一样，需要针对每一种数据库做相应的适配开发。
img
正如 Flink 的宣言 “实时即未来”，在如今的大背景下，实时性是亟待解决的重要问题。因此，我们将主流 CDC 基于日志的技术做了对比，如上图所示：
数据源：Flink CDC 除了对传统的关系型数据库做到了很好的支持外，对文档型、NewSQL（TiDB、OceanBase） 等当下流行的数据库都能够支持；Debezium 对数据库的支持相对没有那么广泛，但是对主流的关系型数据库都做到了很好的支撑；Canal 和 OGG 只支持单一的数据源。
断点续传：四种技术都能够支持。
同步模式：除了 Canal 只支持增量，其他技术均支持全量 + 增量的方式。而全量 + 增量的方式意味着第一次上线时全量到增量的切换过程全部可以通过 CDC 技术实现，无须人为地通过全量的任务加上增量的 job 去实现全量 + 增量数据的读取。
活跃度：Flink CDC 拥有非常活跃的社区，资料丰富，官方也提供了详尽的教程以及快速上手教程；Debezium 社区也相当活跃，但资料大多是英文的；Canal 的用户基数特别大，资料也相对较多，但社区活跃度一般；OGG 是 Oracle 的大数据套件，需要付费，只有官方资料。
开发难度：Flink CDC 依靠 Flink SQL 和 Flink DataStream 两种开发模式，尤其是 Flink SQL，通过非常简单的 SQL 即可完成数据同步任务的开发，开发上手尤为简单；Debezium 需要自己解析采集到的数据变更日志进行单独处理，Canal 亦是如此。
运行环境依赖：Flink CDC 是以 Flink 作为引擎，Debezium通常是将 Kafka connector 作为运行容器；而 Canal 和 OGG 都是单独运行。
下游丰富程度：Flink CDC 依靠 Flink 非常活跃的周边以及丰富的生态，能够打通丰富的下游，对普通的关系型数据库以及大数据存储引擎 Iceberg、ClickHouse、Hudi 等都做了很好的支持；Debezium 有 Kafka JDBC connector， 支持 MySQL 、Oracle 、SqlServer；Canal 只能直接消费数据或将其输出到 MQ 中进行下游的消费； OGG 因为是官方套件，下游丰富程度不佳。
二、现今内部落地的业务场景
img
2018 年之前，大健云仓数据同步的方式为：通过多数据应用定时同步系统之间的数据。
2020 年之后，随着跨境业务的飞速发展，多数据源应用经常打满 DB 影响在线应用，同时定时任务的执行顺序管理混乱。
因此， 2021 年我们开始调研选型 CDC 技术，搭建了小型试验场景，进行小规模的试验。
2022 年，上线了基于 Flink CDC 实现的 LDSS 系统库存场景同步功能。
未来，我们希望依托 Flink CDC 打造数据同步平台，通过界面的开发和配置完成同步任务的开发、测试和上线，能够全程在线管理同步任务的整个生命周期。
img
LDSS 库存管理的业务场景主要有以下四种：
仓储部门：要求仓库的库存容量和商品品类分布合理，库存容量方面，需要留一些 buffer 以防突如其来的入库单导致爆仓；商品品类方面，季节性的商品库存分配不合理导致热点问题，这必将给仓库的管理带来巨大挑战。
平台客户：希望订单处理及时，货物能够快速、精准地交到客户手上。
物流部门：希望能够提升物流效率，降低物流成本，高效利用有限的运力。
决策部门：希望 LDSS 系统能够对在何时何地新建仓库提供科学的建议。
img
上图为 LDSS 库存管理分单场景架构图。
首先，通过多数据源同步的应用向下拉取仓储系统、平台系统以及内部 ERP 系统数据，将所需数据抽取到 LDSS 系统的数据库中，以支撑 LDSS 系统订单、库存、物流三大模块的业务功能。
其次，需要产品信息、订单信息以及仓库信息才能进行有效的分单决策。多数据源定时同步任务基于 JDBC 查询，通过时间做筛选，同步变更的数据到 LDSS 系统中。 LDSS 系统基于这些数据做分单决策，以获得最优解。
img
定时任务同步的代码，首先需要定义定时任务、定义定时任务的类、执行方法以及执行间隔。
上图左侧为定时任务的定义，右侧是定时任务的逻辑开发。首先，打开 Oracle 数据库进行查询，然后 upsert 到 MySQL 数据库，即完成了定时任务的开发。此处以接近原生 JDBC 的查询方式，将数据依次塞到对应的数据库表中，开发逻辑十分繁琐，也容易出现 bug。
因此，我们基于 Flink CDC 对其进行了改造。
