Flink CDC + Hudi 海量数据入湖在顺丰的实践

简介：覃立辉在 5.21 Flink CDC Meetup 的分享。

本文整理自顺丰大数据研发工程师覃立辉在 5月 21 日 Flink CDC Meetup 的演讲。主要内容包括：

1. 顺丰数据集成背景
2. Flink CDC 实践问题与优化
3. 未来规划

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

一、顺丰数据集成背景

顺丰是快递物流服务提供商，主营业务包含了时效快递、经济快递、同城配送以及冷链运输等。

运输流程背后需要一系列系统的支持，比如订单管理系统、智慧物业系统、以及很多中转场、汽车或飞机上的很多传感器，都会产生大量数据。如果需要对这些数据进行数据分析，那么数据集成是其中很重要的一步。

顺丰的数据集成经历了几年的发展，主要分为两块，一块是离线数据集成，一块是实时数据集成。离线数据集成以 DataX 为主，本文主要介绍实时数据集成方案。

2017 年，基于 Jstorm + Canal 的方式实现了第一个版本的实时数据集成方案。但是此方案存在诸多问题，比如无法保证数据的一致性、吞吐率较低、难以维护。 2019 年，随着 Flink 社区的不断发展，它补齐了很多重要特性，因此基于 Flink + Canal 的方式实现了第二个版本的实时数据集成方案。但是此方案依然不够完美，经历了内部调研与实践，2022 年初，我们全面转向 Flink CDC 。

上图为 Flink + Canal 的实时数据入湖架构。

Flink 启动之后，首先读取当前的 Binlog 信息，标记为 StartOffset ，通过 select 方式将全量数据采集上来，发往下游 Kafka。全量采集完毕之后，再从 startOffset 采集增量的日志信息，发往 Kafka。最终 Kafka 的数据由 Spark 消费后写往 Hudi。

但是此架构存在以下三个问题：

• 全量与增量数据存在重复：因为采集过程中不会进行锁表，如果在全量采集过程中有数据变更，并且采集到了这些数据，那么这些数据会与 Binlog 中的数据存在重复；
• 需要下游进行 Upsert 或 Merge 写入才能剔除重复的数据，确保数据的最终一致性；
• 需要两套计算引擎，再加上消息队列 Kafka 才能将数据写入到数据湖 Hudi 中，过程涉及组件多、链路长，且消耗资源大。

基于以上问题，我们整理出了数据集成的核心需求：

1. 全量增量自动切换，并保证数据的准确性。Flink +