关于flink:Flink-CDC-在大健云仓的实践

本文整顿自卑健云仓基础架构负责人、Flink CDC Maintainer 龚中强在 5 月 21 日 Flink CDC Meetup 的演讲。次要内容包含：

1. 引入 Flink CDC 的背景
2. 现今外部落地的业务场景
3. 将来外部推广及平台化建设
4. 社区单干

点击查看直播回放 & 演讲 PDF

一、引入 Flink CDC 的背景

公司引入 CDC 技术，次要基于以下四个角色的需要：

• 物流科学家：须要库存、销售订单、物流账单等数据用于做剖析。
• 开发：须要同步其余业务零碎的根本信息。
• 财务：心愿财务数据可能实时传送到财务零碎，而不是月结前能力看到。
• 老板：须要数据大屏，通过大屏查看公司的业务和经营状况。

CDC 是数据捕捉变更的技术。狭义上来说，凡是可能捕捉数据变更的技术，都能被称为 CDC。但通常咱们说的 CDC 技术次要面向数据库的变更。

CDC 的实现形式次要有两种，别离是基于查问和基于日志：

• 基于查问：查问后插入、更新到数据库即可，毋庸数据库的非凡配置以及账号权限。它的实时性基于查问频率决定，只能通过进步查问频率来保障实时性，而这必然会对 DB 造成微小压力。此外，因为是基于查问，所以它无奈捕捉两次查问之间数据的变更记录，也就无奈保证数据的一致性。
• 基于日志：通过实时生产数据的变更日志实现，因而实时性很高。而且不会对 DB 造成很大的影响，也可能保证数据的一致性，因为数据库会将所有数据的变动记录在变更日志中。通过对日志的生产，即可明确晓得数据的变动过程。它的毛病是实现绝对简单，因为不同数据库的变动日志实现不一样，格局、开启形式以及非凡权限都不一样，须要针对每一种数据库做相应的适配开发。

正如 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 因为是官网套件，上游丰盛水平不佳。

二、现今外部落地的业务场景

• 2018 年之前，大健云仓数据同步的形式为：通过多数据利用定时同步零碎之间的数据。
• 2020 年之后，随着跨境业务的飞速发展，多数据源利用常常打满 DB 影响在线利用，同时定时工作的执行程序管理混乱。
• 因而，2021 年咱们开始调研选型 CDC 技术，搭建了小型试验场景，进行小规模的试验。
• 2022 年，上线了基于 Flink CDC 实现的 LDSS 零碎库存场景同步性能。
• 将来，咱们心愿依靠 Flink CDC 打造数据同步平台，通过界面的开发和配置实现同步工作的开发、测试和上线，可能全程在线治理同步工作的整个生命周期。

LDSS 库存治理的业务场景次要有以下四种：

• 仓储部门：要求仓库的库存容量和商品品类散布正当，库存容量方面，须要留一些 buffer 以防从天而降的入库单导致爆仓；商品品类方面，季节性的商品库存调配不合理导致热点问题，这必将给仓库的治理带来微小挑战。
• 平台客户：心愿订单解决及时，货物可能疾速、精准地交到客户手上。
• 物流部门：心愿可能晋升物流效率，升高物流老本，高效利用无限的运力。
• 决策部门：心愿 LDSS 零碎可能对在何时何地新建仓库提供迷信的倡议。

上图为 LDSS 库存治理分单场景架构图。

首先，通过多数据源同步的利用向下拉取仓储零碎、平台零碎以及外部 ERP 零碎数据，将所需数据抽取到 LDSS 零碎的数据库中，以撑持 LDSS 零碎订单、库存、物流三大模块的业务性能。

其次，须要产品信息、订单信息以及仓库信息能力进行无效的分单决策。多数据源定时同步工作基于 JDBC 查问，通过工夫做筛选，同步变更的数据到 LDSS 零碎中。LDSS 零碎基于这些数据做分单决策，以取得最优解。

定时工作同步的代码，首先须要定义定时工作、定义定时工作的类、执行办法以及执行距离。

上图左侧为定时工作的定义，右侧是定时工作的逻辑开发。首先，关上 Oracle 数据库进行查问，而后 upsert 到 MySQL 数据库，即实现了定时工作的开发。此处以靠近原生 JDBC 的查问形式，将数据顺次塞到对应的数据库表中，开发逻辑非常繁琐，也容易呈现 bug。

因而，咱们基于 Flink CDC 对其进行了革新。

上图为基于 Flink CDC 实现的实时同步场景，惟一的变动是将此前的多数据源同步应用程序换成了 Flink CDC。

首先，通过 SqlServer CDC、MySQL CDC、Oracle CDC 别离连贯抽取对应仓储平台、ERP 零碎数据库的表数据，而后通过 Flink 提供的 JDBC connector 写入到 LDSS 零碎的 MySQL 数据库中。可能通过 SqlServer CDC、MySQL CDC、Oracle CDC 将异构数据源转化为对立的 Flink 外部类型，再往上游写。

此架构相比于之前的架构，对业务零碎没有侵入性，而且实现较为简单。

咱们引入了 MySQL CDC 和 SqlServer CDC 别离连贯 B2B 平台的 MySQL 数据库以及仓储零碎的 SqlServer 数据库，而后将抽取到的数据通过 JDBC Connector 写入到 LDSS 零碎的 MySQL 数据库。

通过以上革新，得益于 Flink CDC 赋予其实时的能力，不须要治理繁冗的定时工作。

基于 Flink CDC 同步代码的实现分为以下三步：

1. 第一步，定义源表 —— 须要同步的表；
2. 第二步，定义指标表 —— 须要写入数据的指标表；
3. 第三步，通过 insert select 语句，即可实现 CDC 同步工作的开发。

上述开发模式非常简单，逻辑清晰。此外，依靠 Flink CDC 的同步工作和 Flink 架构，还取得了失败重试、分布式、高可用、全量增量一致性切换等个性。

三、将来外部推广及平台化建设

上图为平台架构图。

左侧 source 是由 Flink CDC + Flink 提供的源端，可能通过丰盛的源端抽取数据，通过数据平台上的开发写入到指标端。指标端又依靠于 Flink 的弱小生态，可能很好地撑持数据湖、关系型数据库、MQ 等。

Flink 目前有两种运行形式，一种是国内比拟风行的 Flink on Yarn，另一种是 Flink on Kubernets。两头局部的数据平台向下治理 Flink 集群，以向上撑持 SQL 在线开发、工作开发、血统治理、工作提交、在线 Notebook 开发、权限和配置以及对工作性能的监控和告警，同时也可能对数据源做到很好的治理。

数据同步的需要在公司外部特地旺盛，须要通过平台来进步开发效率，放慢交付速度。而且平台化之后，能够对立公司外部的数据同步技术，收拢同步技术栈，缩小保护老本。

平台化的指标如下：

1. 可能很好地治理数据源、表等元信息；
2. 工作的整个生命周期都能够在平台上实现；
3. 实现工作的性能观测以及告警；
4. 简化开发，疾速上手，业务开发人员通过简略培训即可上手开发同步工作。

平台化能带来以下三个方面的收益：

1. 收拢数据同步工作，对立来治理；
2. 平台治理保护同步工作的全生命周期；
3. 专门的团队负责，团队可能专一前沿的数据集成技术。

有了平台之后，即可疾速落地利用更多的业务场景。

• 实时数仓：心愿通过 Flink CDC 以反对更多实时数仓的业务场景，借助 Flink 弱小的计算能力做一些数据库的物化视图。将计算从 DB 里解脱进去，通过 Flink 的内部计算再从新写回数据库，以减速平台利用的报表、统计、剖析等实时利用场景。
• 实时利用：Flink CDC 可能从 DB 层捕捉变更，因而能够通过 Flink CDC 实时更新搜索引擎中的内容，实时向财务零碎推送财务和核算数据。因为大部分财务零碎的数据都须要业务零碎通过跑定时工作以及通过大量关联、聚合、分组等操作能力计算出来，再推送到财务零碎中。而借助 Flink CDC 弱小的数据捕捉能力，再加上 Flink 的计算能力，将这些数据实时地推送到核算零碎和财务零碎，就可能及时发现业务的问题，缩小公司的损失。
• 缓存：通过 Flink CDC，可能构建一个脱离于传统的利用之外的实时缓存，对于在线利用的性能有极大的晋升。

有了平台的助力，置信 Flink CDC 可能在公司外部更好地开释它的能力。

四、社区单干

咱们心愿能与社区发展多元化的单干，以晋升咱们的代码品质以及公司的开源单干能力。社区单干次要将通过三个方面开展：

• 第一，开源共建。心愿可能有更多机会与同行交换分享 Flink CDC 在公司落地实际的教训以及接入的场景，也会在外部发展培训 Flink CDC 技术，通过培训让大家理解 Flink CDC 技术，并在理论工作中可能通过这项技术来解决更多的业务痛点。

目前公司和社区的单干共建已获得一些成绩，公司向社区奉献了 SqlServer CDC Connector 以及单干实现了 TiDB CDC Connector。

• 第二，服务社区。造就部门开发的开源单干能力，并将公司外部版本的个性奉献给社区，只有通过社区宽广用户的打磨，个性能力更加稳固正当。此外，也心愿可能在 schema evolution、turning performance、整库同步的方向与社区发展严密单干。

• 第三，摸索方向。置信 Flink CDC 不会满足于当下的成就，必定会持续向更远的指标后退。所以心愿可能与社区独特摸索挖掘 Flink CDC 更多可能的方向。

近期公司与社区的单干是：将 SqlServer CDC 基于并发无锁框架实现的个性奉献给社区。

上图展现了 SqlServer CDC 的原理。

首先，SqlServer 会将数据变更记录到 transaction log 中，通过捕捉的过程去匹配 log 中开启 CDC table 的 log 日志，将匹配到的日志通过转化后插入到 CDC 生成的 change tables 中，最终由 SqlServer CDC 调用 CDC query function 实时获取 insert、update、delete 以及 DDL 语句，而后转化成 Flink 外部的 OpType 和 RawData 做计算、入湖等操作。

社区同学应用了以后版本的 SqlServer CDC 后，次要反馈的问题有以下三个：

1. 快照过程中锁表：锁表操作对于 DBA 和在线利用都是不可忍耐的，DBA 无奈承受数据库被夯住，同时也会影响在线利用。
2. 快照过程中不能 checkpoint：不能 checkpoint 就意味着快照过程中一旦失败，只能从新开始跑快照过程，这对于大表十分不敌对。
3. 快照过程只反对单并发：千万级、上亿级的大表，在单并发的状况下须要同步十几甚至几十个小时，极大解放了 SqlServer CDC 的利用场景。

咱们针对上述问题做了实际和改良，参考社区 2.0 版本 MySQL CDC 并发无锁算法的思维，对 SqlServer CDC 进行了优化，最终实现了快照过程中无锁，实现一致性快照；快照过程中反对 checkpoint；快照过程中反对并发，减速快照过程。在大表同步的状况下，并发劣势尤为显著。

然而因为 2.2 版本社区将 MySQL 的并发无锁思维形象成了对立公共的框架，SqlServer CDC 须要从新适配这套通用框架后能力奉献给社区。

问答

Q：须要开启 SqlServer 本人的 CDC 吗？

A：是的，SqlServer CDC 的性能就是基于 SqlServer 数据库本人的 CDC 个性实现的。

Q：物化视图通过什么形式去刷新定时工作触发器？

A：通过 Flink CDC 将须要生成物化视图的 SQL 放在 Flink 里运行，通过原表的变动触发计算，而后同步到物化视图表里。

Q：平台化是怎么做的？

A：平台化参考了社区泛滥的开源我的项目以及优良的开源平台，比方 StreamX、DLink 等优良的开源我的项目。

Q：SqlServer CDC 在生产 transaction log 时有瓶颈吗？

A：SqlServer 并没有间接生产 log，其原理是 SqlServer capture process 去匹配 log 内哪些表开启了 CDC，而后将这些表从日志里捞到开启 CDC 表的变更数据，再转插到 change table 里，最初通过开启 CDC 之后数据库生成的 CDC query function 获取到数据的变更。

Q：Flink CDC 高可用如何保障同步工作过多或密集解决计划？

A：Flink 的高可用依赖于 Flink 个性比方 checkpoint 等来保障。同步工作过多或解决计划密集的状况，倡议应用多套 Flink 上游集群，而后依据同步的实时性辨别看待，将工作公布到相应的集群中。

Q：两头须要 Kafka 吗？

A：取决于同步工作或数仓架构是否须要将两头数据做 Kafka 落地。

Q：一个数据库中有多张表，能够放到一个工作里运行吗？

A：取决于开发方式。如果是 SQL 的开发方式，要实现一次性写多表只能通过多个工作。但 Flink CDC 提供了另外一种比拟高阶的开发方式 DataStream，能够将多表放到一个工作里运行。

Q：Flink CDC 反对读取 Oracle 从库的日志吗？

A：目前还无奈实现。

Q：通过 CDC 同步后两个端的数据品质如何监控，如何比对？

A：目前只能通过定时抽样来做数据品质的查看，数据品质问题始终是业内比拟辣手的问题。

Q：大健云仓用的什么调度零碎？零碎如何与 Flink CDC 汇合？

A：应用 XXL Job 作为分布式的任务调度，CDC 没有用到定时工作。

Q：如果采集增删表，SqlServer CDC 须要重启吗？

A：SqlServer CDC 目前不反对动静加表的性能。

Q：同步工作会影响零碎性能吗？

A：基于 CDC 做同步工作必定会影响零碎性能，尤其是快照过程对数据库会有影响，进而影响利用零碎。社区未来会做限流、对所有 connector 做并发无锁的实现，都是为了扩充 CDC 的利用场景以及易用性。

Q：全量和增量的 savepoint 怎么解决？

A：（未通过并发无锁框架实现的连接器）全量过程中不能够触发 savepoint，增量过程中如果须要停机公布，可通过 savepoint 复原工作。

Q：CDC 同步数据到 Kafka，而 Kafka 外面存的是 Binlog，如何保留历史数据和实时数据？

A：将 CDC 同步的数据全副 Sync 到 Kafka，保留的数据取决于 Kafka log 的清理策略，能够全副保留。

Q：CDC 会对 Binlog 的日志操作类型进行过滤吗？会影响效率吗？

A：即便有过滤操作，对性能影响也不大。

Q：CDC 读 MySQL 初始化快照阶段，多个程序读不同的表会有程序报错无奈获取锁表的权限，这是什么起因？

A：倡议先查看 MySQL CDC 是不是应用老的形式实现，能够尝试新版本的并发无锁实现。

Q：MySQL 上亿大表全量和增量如何连接？

A：倡议浏览雪尽老师在 2.0 的相干博客，非常简单清晰地介绍了并发无锁如何实现一致性快照，实现全量和增量的切换。

点击查看直播回放 & 演讲 PDF

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…