作者：陈政羽，目前就职于深圳依时货拉拉科技术有限公司，在公司数据平台组负责湖仓一体平台和实时计算平台相关开发工作，是 Apache Amoro PMC Memeber，ALC ShenZheng Memeber ，也是 Apache Flink 社区贡献者和志愿者，目前在开源社区专注于实时计算方向以及 Amoro 社区海外和国内的运营和开发工作。
摘要：今天的文章撰写自陈政羽老师在 Apache Asia Community Over Code 2024 上的分享《货拉拉在 Flink CDC 生产实践落地》，系统地介绍货拉拉的业务背景，技术选型，整体能力构建与收益，最后分享了开源参与以及开展的未来工作和期望。
业务介绍
货拉拉（HuoLaLa）是一家拉货搬家跑腿发长途平台，创立于 2013 年，成长于粤港澳大湾区，是从事同城/跨城货运、企业版物流服务、搬家、零担、跑腿、冷运、汽车租售及车后市场服务的互联网物流商城。通过共享模式整合社会运力资源，完成海量运力储备，并依托移动互联、大数据和人工智能技术，搭建“方便、科技、可靠”的货运平台，实现多种车型的即时智能调度，为个人、商户及企业提供高效的物流解决方案。
截至 2023 年 12 月，货拉拉业务范围覆盖全球 11 个市场，包括中国及东南亚、南亚、南美洲等地区，其中中国内地总共覆盖 363 座城市，月活司机达 90 万，月活用户达 1200 万。
每天产生订单、司机、汽车物联网数据量是PB级别，如何稳定、高效、快速采集到这些数据，挖掘业务数据价值，释放新质生产力成为公司关键运营和决策因素。
2022至2024年初，随着货拉拉业务体量提升，陆续开始有采集稳定性故障通报，原有架构不适合支撑新业务大的采集，整改迫在眉睫。采集进程、网络、硬件资源发生争抢，核心链路资源无法得到保障，数据准确性下降，从而导致触发数据熔断无法查看数据，导致业务产生舆情可能性增大。在 2023 年关于实时稳定性故障中，数据订阅的稳定性故障通报较多，数据平台组内从 2023 年 9 月已经开始关注 Flink CDC 技术，并且在 2024 年 1 月陈政羽同学加入后开始推进工程化落地。
从货拉拉业务需求层面来看，我们既要满足当下业务需求，也要面对未来高速发展的海量数据采集需求，我们面临着以下四大挑战：
功能性：想利用 Flink SQL 进行一些配置化，就可以完成整库的一些同步开发，就不需要用户再去有一些额外的成本
稳定性：稳定性上面来说，我们希望说这样的一些新技术下游不需要做过多的改动 SQL 任务，只需要切换 CDC 相关数据的 Kafka topic 就可以完成链路的切换，保障数据链路的稳定
兼容性：业务方之前有可能使用一些 Canal 等一些数据订阅组件进行数据的订阅，我们需要对这一部分功能进行兼容，实现业务方最小的感知改动
数据一致性：切换完成之后，也需要对数据的最终一致性进行一个保证，切换完后数据的结果必须要最终等价，我们会进行一些双跑验证去保证数据最终的一致性
基于以上四象限考虑，我们开始对开源社区产品进行相关技术评估和技术选型
在做数据同步技术选型时候，我们关注 稳定性、时效性、准确性、兼容性等多方面因素考虑。我们既要解决当下数据库数据采集问题，也要考虑到未来可能遇到其它业务数据库系统采集问题。通过各个组件的横向对比，选择Flink CDC ，我们可以借助 Flink的能力，不仅能保障数据时效性，还能够享受到多个上下游Connector组件生态，进行灵活搭配结合使用。最终我们选择了Apache Flink CDC 框架作为实时数据同步的框架。
整体能力构建
在完成技术选型后，我们开始对现有的业务进行梳理，并且从稳定性、上层应用、平台适配、数据架构 四个方面入手去构造 CDC 整体能力（如下图）。
应用层是直接提供给飞流任务和多方业务使用的。目前包括了罗盘、实时看板、指标波动告警、交易、营销等多个业务方直接或者间接的使用 Flink CDC。
平台适配能力上面我们对配置化、感知、协议、SDK等做了适配数据架构我们希望未来借助 CDC+数据湖 构建多应用适配场景稳定性方面做了限流、HA、血缘、性能验证等多方面测试和改进。
适配性改造方面，我们去兼容了 Canal 一些功能，例如根据指定的Key去取相应的值，Hash 后分发到 Kafka对应分区上面，保障同个主键id分区有序。同时进行了相关的协议改造，可以使用 Flink SQL完成整库同步开发。
从稳定性上面，我们开发自己一套监控逻辑，保障业务连续性和稳定性。并且在原生告警上面，我们不仅做了相关监控大盘，底层还增加了 Debezium 一些指标采集上报到Flink Metric，构造整体CDC监控大盘。其中包括了原生指标 NumberOfDisconnects，一些采集等待队列大小、事件产生数量等等一些指标，这些指标有助于我们排查任务故障和了解日常使用情况，协助我们更好的去优化作业参数。
业务场景
公司内部目前的业务有小拉出行、货拉拉、LaLaMove、跑腿等多业务线，同时还区分国内和海外多DC环境，整体业务数据量达到 TB～PB 级别，目前已经接入的已经有实时看板、云台、 kepler、 BI 报表、Monitor 、交易等业务，陆续还有订单、跑腿等业务接入中。
3.1 数据实时加工
如图上所示，业务方首先在飞流计算平台配置相关采集信息，包括采集 DB、采集库表等信息就完成了一次基础配置。完成配置后即可启动 Flink 采集任务，经过 Flink CDC 数据实时订阅后，把 MySQL 数据实时采集到 Kafka。业务方可以按需订阅自己需要的topic并且取出相关表的变更数据，通过 Flink ETL 进一步加工能力，把加工后的数据输出至 OLAP 关系型数据库、Hive 离线数仓、数据湖等不同的地方，最后业务方通过自己的业务系统加工完成相关数据后进行展示与输出。这样一条完整的数据采集、计算、存储、展示链路即可快速完成。
3.2 整库同步场景
当多个任务使用同一张 MySQL 表做处理时，MySQL 数据库会启动多个连接，对 MySQL 服务器和网络造成很大的压力。飞流通过引入 Kafka 作为中间层，并封装了表和库的同步语句到 Kafka 来解决 MySQL 重复链接问题，在面对整库同步场景下，我们使用 Kafka 作为转发中间层，下游任务消费中间层数据即可，避免直接消费 binlog。
通过飞流 SQL+Flink CDC 能力，我们完善了整库同步能力。用户可以把分库分表数据进行统一采集到 Kafka 中间层，在数据下游消费即可完成统一视图构建，在一张 Hive/湖表查询分库分表数据，完成业务分析和查询操作，大大的提高业务数据连续性和便捷性。
链路切换
用户在切换时候，通常会对新技术会有顾虑，包括数据最终一致性，切换便捷程度，技术信任度，效率等多方面去考察是否值得切换。为了打消用户疑虑，同时让切换更加丝滑，我们团队提供了多种切换方式，新链路只需用户完成页面SQL基本配置/一键采集页面拖拉拽即可完成数据采集，简单方便。
对于历史用户希望全链路切换至 Flink CDC，我们提供了简单切换思路和复杂切换的方式
简单链路的切换我们可以通过双采集模式，把 CDC 接入新的采集表中，通过 Flink SQL Union 逻辑完成数据合并操作，按照时间进行切分数据进入时间，即可完成链路切流动作。业务做到无感知完成 Flink CDC 链路接入。
对于复杂的链路，我们可以使用多层逐层对数。这里给大家展示了我们实时大屏切换的流程。实时大屏由于多实时链路之间延迟计算差异特性，对DM层设计了独特的对数方案，多达 15+ 对数规则，利用现有的云台，加速可视化分析的过程，在对数中累计修复双跑链路不一致问题 2 个
切换过程中我们也遇到了数据性一致性的挑战，于是我们基于公司内部工具和一些常见的数学统计方法，设计了一套科学的方法论区对齐数据格式和数据准确性。我们需要统计 Flink CDC 与 Canal 数据差异率，利用常用统计学方法找出异常数据进行逐步归因排查，并且输出结论报告给到业务方，让业务方放心切换。
从上图可以看到，我们利用公司云台产品，去做数据校验可视化。在实时大屏这个业务里面，它的指标会比较多，其中一个比较关键性的指标叫做响应时长中位数。大家从图中可以看到我们会从以下几个方面去输出一些对数的一些结论。首先我们会从数据的一个总量、总记录数去对比差异，同时还会通过一些利用一些统计学的一些方法去逐步地找出这两条链路上面的一些数据上的一些不同或者是趋势。例如利用正负 rate 分布差异、统计表指标差值 max 的平均值、差异率趋势等等的这样的一些指标。然后大家可以看到第二幅图，我们是统计了每一个分片时间内每一条数据以及是一些值的一些差异率。我们这边可以利用公司内部云台上面的一些功能，把这一部分数据进行一些交叉对比后，产出结论给到业务方进行快速双链路对数这样的一个动作。
整体收益
切换后，我们从多个维度去对比切换前后带来的收益，我们主要针对以下这几个维度进行量化对比
采集性能对比：采集吞吐量、采集延迟、数据延迟、数据格式大小
采集业务切换效果对比：业务方反馈切换后的整体情况
采集稳定性：对比采集稳定性提升，故障和冒烟总次数是否下降
5.1 日常采集Canal / Flink CDC 延迟对比
大家可以看到这是 CDC 跟 Canal 日常的一些采集的一些延迟对比，当业务方把从这个 Canal 切换到 CDC 之后，对比原链路突刺减少，采集稳定性大幅度提升，整体的延迟下降率最高达到80%（最高延迟从30S下降到3S）。业务反馈数据时效性提示，同时因为采集延迟的下降，业务反馈整体的一个数据统计双流Join、准确性等各方面都得到了一定程度的提升。
5.2 归档任务恢复
第二个场景的话是深夜归档的一些任务，因为在深夜的时候有一些业务方需要对数据进行一些备份或者是回刷的一些操作。这种操作导致 DB 的 IO 大量提升，也会影响当前的一些采集任务。在这样高负载的场景下， Canal 的最大延迟可以达到 250 秒， CDC 的延迟在 30 秒就可以去恢复。经过研究因为 CDC 它支持断点续传，同时的 CDC 具有 GTID 切换恢复能力，所以在任务采集的自愈性和恢复能力上面更加显著。
最后我给大家展示一下当前的一个链路的一个切换情况，当前已经有 50 多个链路替换为Flink CDC，每天处理数据量达到TB级别，陆陆续续海外国内业务方主动询问Flink CDC 技术和相关切换SOP流程。从整体效果来对比，大家看到下图基本上延迟都在 1-2 秒左右，然后对比以前的采集模式，当前的采集效率得到大幅提升，同时延迟下降十分明显。同时借助Flink引擎的分布式处理能力，数据发送的吞吐量提升，稳定性得到保障。
同时我们在存储上面也有一些额外的收获，我们自己实现了一套协议（兼容Debezium）后，对比原来Canal的协议，Kafka中间的存储量下降20%-60% 不等（下图是其中一个分库分表存储量对比）
开源参与
未来展望
从数据入湖，我们希望 Flink CDC 支持数据入湖，为数据的时效性带来新的新鲜度。社区目前已经支持Paimon数据入湖，希望未来使用 Flink CDC 的 YAML 作业配置，即可实现入湖 ETL + Schema Evolution 能力，完成数据入湖入仓的整个链路场景。
从稳定性建设上面，我们会继续持续深耕 Flink CDC 任务链路预警系统的一些开发，提升数据采集、感知和发现能力，做到业务方的一个及时预警。同时我们也会探索这一部分数据的实时入库同步，然后通过数据湖来搭配去解决数据修正慢、数据回溯慢的等问题。我们也会保障 CDC 底层数据链路采集的稳定性和正确性，保障在不同的复杂采集数据类型上面的一些正确的语义，提升数据采集稳定性，让业务平安夜时长提升，提升平台和值班人员幸福感。
我们也会积极跟开源社区开展合作，把一些内部的一些 Feature 和社区进行分享，以及是把一些相关案例去给到我们的开源社区。同时在组内外开展 Flink CDC 的一些技术培训，包括像最近公司的派课堂培训用户使用 Flink CDC 完成数据入库，去完善周边的一些生态和功能。包括后续希望使用 Amoro + Flink CDC + Paimon/Iceberg + Dinky / SP 等平台形成完整入湖管理能力，同时和各大社区一起开发相关 Feature，并在公司落地服务业务。
欢迎大家多多关注 Flink CDC，从钉钉用户交流群[1]、微信公众号[2]、Slack 频道[3]、邮件列表[4]加入 CDC 用户社区，以及在 Flink CDC GitHub 仓库[5]上参与代码贡献！
[1] “ Flink CDC 社区 ② 群”群的钉钉群号：80655011780
[2] ” Flink CDC 公众号“的微信号：
[3] https://flink.apache.org/what-is-flink/community/#slack
[4] https://flink.apache.org/what-is-flink/community/#mailing-lists
[5] https://github.com/apache/flink-cdc
活动推荐
