摘要:货拉拉是一家拉货搬家跑腿发长途平台,创立于 2013 年,成长于粤港澳大湾区,是从事同城/跨城货运、企业版物流服务、搬家、零担、跑腿、冷运、汽车租售及车后市场服务的互联网物流商城。通过共享模式整合社会运力资源,完成海量运力储备,并依托移动互联、大数据和人工智能
导读
本文将分享货拉拉基于 Flink CDC 的建设实践,以及对 CDC 数据入湖的新思考。主要内容包括:
1. 货拉拉业务背景介绍
2. 货拉拉为何选择 Flink CDC 作为实时数据同步链路组件
3. 货拉拉 CDC 生产实践
4. CDC 数据入湖和未来展望
分享嘉宾|陈政羽 货拉拉 高级大数据开发工程师
编辑整理|齐来军
内容校对|李瑶
出品社区|DataFun
01 货拉拉业务背景介绍
1.货拉拉背景介绍
货拉拉是一家拉货搬家跑腿发长途平台,创立于 2013 年,成长于粤港澳大湾区,是从事同城/跨城货运、企业版物流服务、搬家、零担、跑腿、冷运、汽车租售及车后市场服务的互联网物流商城。通过共享模式整合社会运力资源,完成海量运力储备,并依托移动互联、大数据和人工智能技术,搭建“方便、科技、可靠”的货运平台,实现多种车型的即时智能调度,为个人、商户及企业提供高效的物流解决方案。
2. 业务整体增长情况
截至 2023 年 12 月,货拉拉业务范围覆盖全球 11 个市场,包括中国及东南亚、南亚、南美洲等地区,其中中国内地总共覆盖 363 座城市,月活司机达 90 万,月活用户达 1200 万,每天产生订单、司机、汽车物联网数据量达到 PB 级别。如何稳定、高效、快速采集到这些数据,挖掘业务数据价值,释放新质生产力成为公司运营和决策的关键。
3. 业务攀升的稳定性挑战
随着企业业务量的急速攀升,逐渐遇到新的挑战,首先是实时抽数延迟严重,导致下游 Flink 的双流 Join 产生问题,并带来数据时效性、数据链路稳定性等问题。早期使用 Canal 作为实时数采集主要存在以下问题:
架构陈旧:单节点部且非分布式运行,维护频率低。
Canal 维护性差:可维护性差,Canal 社区的整体上下游处于不活跃,导致维护性成本特别高。
上游数据采集稳定性差,结合历史故障以及冒烟测试,发现实时数据采集稳定性主要集中在上游数据采集端。
接下来将介绍货拉拉实时数据采集改造为什么选择 Flink CDC 作为新的实时数据采集和同步框架。
02 货拉拉为何选择 Flink CDC
1. 选择四象限作为思考切入点
首先我们会从上述四点去考虑到底需要一款什么工具作为货拉拉的实时数据同步工具。
功能性:实时数据平台首先考虑完善的功能性,Flink SQL 目前开源版本仅支持单表单库同步,如果业务方想完成其同步作业的话,必须使用 SQL 或 Flink CDC3.0 的 yaml 配置化方式才能完成整库同步开发。
对标 Canal 兼容性:历史业务方使用 Canal 进行数据采集,以及下游不限于大数据团队的消费方均使用 Canal,因此要对部分 Canal 功能进行兼容性对标,已实现业务感知和改动最小化。
链路稳定性保障:涉及下游任务方的改造,当前只能通过 Kafka 消费组获取下游消费方,因此希望下游消费方无需做过多改动,如 SQL 任务下游仅需切换 CDC 数据源即可;同时包装了一个消费 CDC 的 SDK 供业务使用,依据相关 topic 命名规则即可完成整个链路切换,保障链路切换的稳定性。
保障数据一致性:链路切换时希望保障数据的一致性,即最终数据结果是等价的。因此需要通过一些科学的数据验证手段,如双跑验证、采用对数工具,保证数据最终一致。
2. 开源组件对比
我们在进行实时数据同步调研时对一些开源组件的功能、使用场景、稳定性以及社区生态等多方面进行了对比,包括 Flink CDC、Canal、Apache SeaTunnel 以及 DataX。
CDC 同步机制:传统数据同步方面,DataX 只支持查询的 CDC 操作。Flink CDC 只需要订阅 binlog 即可完成数据采集比较服务业务诉求。
全量+增量同步:只有 Flink CDC 支持全量+增量数据同步,满足货拉拉某些场景下采集全量数据构建湖仓一体,业务需要持续性地对历史数据进行全量采集并加上增量数据同步,而其他组件在此方面表现为不支持或部分支持。
部署形态:由于 Flink CDC 是依托于 Flink 的底层架构,Flink 本身采用分布式部署,架构选型会考虑 Flink CDC 在数据采集阶段以及下游消费阶段的整体的一些协调性。
稳定性:Flink CDC 依靠于 Flink 的 HA 机制,包括 ZooKeeper 以及 on K8s 的高可用,整体上会更加倾向于 Flink CDC 作为实时链路的数据同步工具。
3. 未来数据入湖需求
我们正在建设的数据入湖,也做了一些面向未来的设计,包括 CDC 数据入湖分析,数据时效性高且为结构化数据,而埋点数据时效性低且非结构化数据,以及日志数据需要间接性统计和分析,并且为非结构树数据。这里我们需要通过引入 CDC pipeline 机制对接 Paimon Yaml 配置,便可通过 CDC 将传统 MySQL 数据库直接订阅入湖到 Paimon,然后进行数据加工等 ETL 相关操作。
经过前期的深度思考、对比与总结最终形成了如上图所示的架构,主要包括数据来源、业务场景、数据服务以及数据湖平台、数据引擎、湖仓格式、数据存储层以及业务等。数据内部开发平台主要是元数据平台(元初)、离线数据平台(IDP)以及实时数据开发平台(飞流);数据湖平台主要包含数据集成服务和湖仓优化服务。数据集成服务采用 Flink CDC 实时采集把数据源的数据订阅到湖仓里面,并通过 Amoro 进行自动优化湖仓,从而达到湖仓一体的整体架构。在执行引擎方面当前只是完成了基于 Flink Engine 的建设,对于灰色的 Doris Engine、Spark Engine 以及 Presto Engine 将是 2025 年的建设重点,数据加工完成后将输送给业务方,如埋点业务、业务画像以及实时大屏、同时也会输出给内部 GPT 项目等提供给业务方去使用。
03 货拉拉 CDC 生产实践
1. 飞流实时计算平台能力建设
飞流作为货拉拉的实时计算平台,为了很好的对接 Flink CDC,实时数据计算平台进行了升级优化,主要包括以下几个方面:
平台感知能力:修改了很多底层代码,新增了 Metrics 的一些能力,如把 DB 底层的 Metrics 进行了封装,连同 Flink 的 Metrics 一并上报,形成报警能力,便于业务及时发现 DB 底层的整体采集状况。
平台配置化能力:对 Flink CDC 的 catalog 做了一层封装,同时支持 Flink Yaml 的配置化方式,提供了更多的灵活性。
平台数据协议优化:由于采用 Flink CDC Connector 进行二次开发,当前对数据协议进行了二次封装,把内部的 DB 层数据进行打宽,并增加了一些原始字段,支持业务方消费这些数据,同时做到了传统数据库的采集数据落库。
数据解析优化:通过增加元数据字段的一些信息,提高了在数据协议和数据解析的速度。
SDK 封装:由于 CDC 数据的使用者不仅包括大数据内部平台,还包含很多线上业务方,因此封装了一套 SDK,屏蔽 CDC 相对业务方比较复杂的概念与逻辑,交付业务方使用。
从数据架构层面,目前正在做的是统一数据采集的工作,如海内网逐步推进整体使用 Flink CDC 替换掉 Canal,以及一键入仓、一键入湖的工作,甚至一些流量回放业务场景。在数据迁移方面,我们也会用到 Flink CDC。
稳定性方面,引入了限流的能力,如会限制 sink 的采集速度,避免在采集高风险期引起数据库的整体压力。采集性能方面引入了多线程处理,提升解析能力。同时做了全局血缘的关联,用于快速感知业务方使用 CDC 表,以及 CDC 采集数据影响下游任务,可以快速让业务方感知采集出现问题时会导致哪些业务受到影响。
以上就是对飞流实时计算平台整体能力的介绍。
2. 常规对数方法校验
由于采用 Flink CDC 代替了 Canal 进行实时数据采集,因此需要进行数据校验和对比。首先在常规对数方面,对特殊字段类型,如时间类型、bigInt、dynamic 等特殊字段的数据一致性校验,同时基于时间切片做了 count 统计操作。由于消费方在大数据内部,因此还会涉及到数仓分层逐层对数的校验,这里我们使用 Flink Batch task 在维度时间对齐、最终切片对齐的最大差异、差异占比以及差异分布等方面进行统一对数。
3. 数据科学方法校验
上文提到使用 Flink batch task 进行统一对数,主要会在基于差异率的正负进行分布式对数,差异统计表、全局指标的差值以及与 Canal 对比差异的趋势率。如上图可以看到,可通过总条数以及每一个时间切片上面每一个数据的准确性进行整体对比,确保从 ODS 到 DWD 以及 DWS 层整体链路数据准确性和最终一致性,如果出现数据缺少将会主动进行排查。
4. 数据双跑校验
还会通过数据双跑进行数据校验,如通过生产 Kafka 和验证 Kafka 去进行数据交叉链路验证对比,然后基于 binlog 采集时间对比这一段时间的数据总数以及数据的准确性进而得出一个交叉率,当两部分数据完全一致时交叉率应该是 100%,最终会输出一份报告给到业务方,使业务方信任,并推动业务使用链路切换工作顺利开展。
5. Schema Change 信息变更处理
由于基于 Flink CDC Connector 进行开发,只有 3.0 才支持 Schema 变更操作,当前做法是把 Schema change 通过一个测流发送到对应告警的 Kafka topic,并通过消费再发出一个告警卡片,同时会将此任务告警和下一个任务 Flink taskId 进行关联,通知下游业务方 Schema 变更消息。后续我们将接入 CDC3.X Pipeline Connector,进行定制化开发,提供分流告警和下游支持等。
6. Canal VS Flink CDC 稳定性对比
下面介绍一下切换后的整体稳定性。以某一真实在线业务为例,在下午高峰期采集的时候,使用 Canal 最大的延迟在 3030s 左右,而使用 Flink CDC 基本维持在毫秒级别。在采集的整体稳定性方面,可以看到 CDC 整体采集稳定性要比 Canal 有显著提升,最高可提高 80 倍。采集波动率方面,Canal 采集按照 Batch 作业有批量的波动,而 CDC 则保持在一个稳定的水平。
截止到目前,我们已经有 100+ 个 CDC 采集业务,其中有 70+ 是之前的 Canal 任务切换到 Flink CDC,后续海外一些 Canal 采集也将会采用 Flink CDC 代替。
整体上延迟最高下降了 80%,同时我们基于协议进行改造,因此消息中间件的数据存量也下降了 30%,并且完成了一些核心应用加关键线上业务的接入。上图给出了整体延迟的 1h 截图,可发现使用 Flink CDC 的数据采集基本上稳定保持在 1s 左右,可以比较好地保持数据的新鲜度。
7. 建设成果
整体建设成果方面,当前通过订阅关系型数据库,通过飞流平台使用 Flink 作业进行数据采集,写入到 Kafka 或流入数据湖组件上,后续经过离线 ETL 加工输出后生成一些报表。目前公司内部业务包括小伙拉行、货拉拉、跑腿等多个业务线使用 Flink CDC 代替了原先的 Canal 进行实时数据链路采集,整体业务数据量达到 TB-PB 级别,并且多个实时看板、云台、BI 报表以及交易 2.0 等业务也使用 Flink CDC 进行实时数据采集。最终我们希望可以实现数据订阅链路的“以旧换新“,后续将持续对老链路的替换,最终完成平台化工程建设。
04 CDC 数据入湖&未来展望
结合公司内部使用场景以及阿里最新发布的 Fluss 项目,为我们带来了一些新的想法。如上图,业务数据经过 CDC 订阅同步后进入到 Fluss,Fluss 将消费 CDC 的数据产生 changeLog,并将这个 changeLog 给到 Flink 下游继续去消费。同时也会通过 Compaction Service 生成数据到 LakeHouse Storage,这一部分数据通过 Compaction Service 生成一些湖格式的表,如 Paimon 或 Iceberg 表,这些表可以通过外表的形式给到 OLAP 引擎或流计算引擎进行查询。同时在 Flink 的 source 一端做合并读的操作,如把 LakeHouse storage 进行合并读从而屏蔽掉用户对流和批的差异。
当然这样将数据引入到 LakeHouse storage 会带来读放大的问题,可以引入 Amoro 持续优化 Paimon 和 Iceberg 表减少小文件的数量,同时在为下游消费这部分 CDC 数据时带来更好的体验。
当前我们正在探索 Flink CDC+数据湖(Paimon 和 Iceberg),并结合 Apache Amoro 实现全自动数据入湖,形成完整的数据入湖生态体系,进一步提升数据时效性和准确性,以满足业务方对数据新鲜度的需求。并将与数据湖开源社区开展深度合作与探讨,把场景固化,加速湖仓一体落地的进程。
我们还会考虑多数据源订阅的需求,满足关系型和非惯性数据的订阅查询,如支持 MongoDB 数据的订阅,构建货拉拉统一实时采集和湖仓数据生态。
以上就是本次分享的内容,谢谢大家。
INTRODUCTION
陈政羽
高级大数据开发工程师
陈政羽,目前就职于深圳依时货拉拉科技术有限公司,在公司数据平台组主导湖仓一体平台开发工作以及实时计算平台周边组件开发工作。同时是 Apache Amoro PPMC Memeber,ALC ShenZheng Memeber ,也是 Apache Flink 社区贡献者和志愿者,曾持续在游戏行业负责数据平台建设与开发工作。目前在开源社区专注于实时计算方向以及 Amoro 社区海外和国内的运营和开发工作。来源:一个数据人的自留地