Flink CDC 在货拉拉的落地与实践

作者：陈政羽，现在就职于深圳依时货拉拉科技术有限公司，在公司数据平台组负责湖仓一体平台和实时计算平台相关开辟工作，是 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 、交易等业务，陆续另有订单、跑腿等业务接入中。
1. 数据实时加工

如图上所示，业务方首先在飞流计算平台配置相关采集信息，包括采集 DB、采集库表等信息就完成了一次基础配置。完成配置后即可启动 Flink 采集任务，颠末 Flink CDC 数据实时订阅后，把 MySQL 数据实时采集到 Kafka。业务方可以按需订阅自己必要的topic而且取出相关表的变更数据，通过 Flink ETL 进一步加工本领，把加工后的数据输出至 OLAP 关系型数据库、Hive 离线数仓、数据湖等不同的地方，末了业务方通过自己的业务体系加工完成相关数据后举行展示与输出。这样一条完整的数据采集、计算、存储、展示链路即可快速完成。
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 的平均值、差异率趋势等等的这样的一些指标。然后各人可以看到第二幅图，我们是统计了每一个分片时间内每一条数据以及是一些值的一些差异率。我们这边可以利用公司内部云台上面的一些功能，把这一部门数据举行一些交叉对比后，产出结论给到业务方举行快速双链路对数这样的一个动作。
五、团体收益

切换后，我们从多个维度去对比切换前后带来的收益，我们主要针对以下这几个维度举行量化对比

• 采集性能对比：采集吞吐量、采集耽误、数据耽误、数据格式大小
  
• 采集业务切换效果对比：业务方反馈切换后的团体情况
  
• 采集稳定性：对比采集稳定性提升，故障和冒烟总次数是否下降
  

1. 日常采集Canal / Flink CDC 耽误对比

各人可以看到这是 CDC 跟 Canal 日常的一些采集的一些耽误对比，当业务方把从这个 Canal 切换到 CDC 之后，对比原链路突刺减少，采集稳定性大幅度提升，团体的耽误下降率最高达到80%（最高耽误从30S下降到3S）。业务反馈数据时效性提示，同时由于采集耽误的下降，业务反馈团体的一个数据统计双流Join、正确性等各方面都得到了肯定程度的提升。

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% 不等（下图是其中一个分库分表存储量对比）

六、开源参与

我们在贡献这一部门代码的同时，我们也积极跟开源社区合作，不仅积极在社区贡献Feature，同时在本年7月在参加 Apache Asia Community Over Code 2024 国际会议，作为实时计算生产案例去参加这一部门的演讲，在这里也非常感谢阿里实时计算团队的 @庆盛 @徐榜江 老师以及其团队给予我们的协助，资助货拉拉快速落地Flink CDC用于生产情况。

七、将来展望

从数据入湖，我们希望 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 公众号“的微信号：ApacheFlinkCDC
[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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。