干货 | 准实时数仓落地实战：携程商旅基于Paimon的湖仓一体架构设计与批流融合实践

作者简介

Cuirj，携程资深数据仓库工程师，关注数仓架构和AI在BI的应用；

Joey Qin，携程数据仓库工程师，关注湖仓技术和AI在BI的应用；

团队热招岗位：数据分析师、高级前端开发工程师

导读：本文介绍了携程商旅在准实时数仓与湖仓一体化建设中的实践。团队基于Paimon构建稳定高效的数据链路，覆盖订单宽表加工、退票提醒、广告归因等场景，并探索批流一体与 Tag 增量计算，总结了不同场景下Partial Update、Aggregation 等特性的应用经验，对准实时数仓建设具有一定参考价值。

一、背景

携程商旅专注于为企业客户提供一站式差旅管理服务，覆盖机票、酒店、用车、火车等多类差旅场景。用户可通过商旅平台完成预订、审批、报销等全流程操作，业务链条长、数据流转环节多，数据规模与复杂度持续攀升。

伴随商旅业务的增长和产品形态的日益丰富，业务对数据时效性的要求不断提高，原有的T+1离线数仓架构已无法满足准实时数据分析需求，而基于Kafka、Flink的传统实时数仓虽能支撑部分实时计算场景，但适用性有限，且其计算中间层无法直接用于分析。

因此商旅大数据团队积极探索准实时湖仓一体路线，提升业务数据新鲜度，推动以Paimon为代表的新型湖仓引擎在核心业务场景落地，助力数据架构升级和业务创新。

目前Paimon在携程商旅的使用场景主要有以下两个方面：

1）准实时数仓搭建：基于Flink CDC和Paimon搭建准实时湖仓，也是当前业界比较典型的湖仓一体解决方案；

2）批流一体融合实践：基于Paimon的流批一体存储基础上，分别用Flink和Spark进行流式处理和批处理。

二、准实时数仓搭建

2.1 准实时订单宽表开发

订单明细宽表是商旅订单管理模块的核心应用层表，支撑用户随时查询订单明细，当前链路采用小时级离线任务加工宽表。随着商旅业务的快速发展，用户对数据的实时性提出了更高的期望，但是订单明细宽表字段很多，数据来源分散，ETL过程涉及近十张表、加工逻辑复杂而且链路较长。 

在引入Paimon之前，我们也尝试过基于Flink+Kafka搭建实时宽表，但在实际过程中暴露出以下主要痛点：

1）离线小时级的批任务运行不稳定，ETL流程一旦超时将阻塞下个小时实例运行，数据延迟更高。

2）而Flink+Kafka多流Join在复杂链路下稳定性不足，维护成本高。

如何在保证数据新鲜度的同时，兼顾开发效率和链路稳定性，成为准实时订单宽表开发的核心挑战。引入Paimon能够有效解决上述问题，其湖仓一体的特性支持Upsert更新和动态写入，兼容离线与实时场景，Partial Update特性可代替多流Join构建宽表，显著提升了链路的稳定性和开发效率。

基于Paimon的准实时宽表构建过程如下图所示，ODS层通过Flink CDC将MySQL业务数据实时入湖，EDW层借助Paimon的Partial Update和Aggregation合并引擎构建宽表，另外也使用Paimon表当作维表存储，代替HBase/Redis进行Lookup Join。

在离线ETL任务中，宽表的加工过程通过多表Join的方式放在一个Job里完成，但Paimon的Partial Update不同于Join，使用场景是有条件的，要求目标宽表的主键和源表主键相同，因此离线ETL逻辑不能照搬到实时任务上，所以将离线作业拆分为三个Flink作业：基于Partial Update构建订单产品通用信息宽表、基于Aggregation构建订单中间宽表、基于Lookup Join退化维度信息。