使用 Paimon 构建湖仓一体

1 同程旅行数仓建设历程

早期，同程旅行的数仓体系基于 Hive 来实现离线数据分析，在满足用户实时需求方面存在不足。为了解决这一问题，我们引入了 Apache Kudu 组件，将 ODS 层的数据同时写入 Hive 和 Kudu。由于 Kudu 不支持流式读取，我们通过 Spark 读取Kudu进行下游处理，以 10 分钟或 1 小时为周期调度任务，将处理后的数据写回 Kudu 表。

然而，这种架构存在显著的问题：

数据被有两份，分别存储在 Hive 和 Kudu 中，无法共享；
Spark 调度周期较长，无法满足实时性需求；
Kudu 基于 SSD 构建，整体存储成本较高，难以承受。

基于上述痛点，我们在2022 年引入了 Hudi。Hudi 支持 ODS 的近实时更新和流式读取，解决了数据时效性的问题。但在实际使用中，Hudi 仍存在以下不足：

ODS 数据同步时写入效率低；
资源消耗较大，尤其是在进行 compaction 操作时；
数据质量问题较多，偶尔会出现数据丢失的情况。
为进一步优化，我们在 2023 年引入了 Paimon。

Paimon 的优势

Paimon 的引入，显著提升了 ODS 数据同步效率并降低了资源消耗。与 Hudi 相比，Paimon 在写入性能和查询性能上都有明显优势，具体表现如下：

Paimon 支持多种表模型（例如主键表、追加表、部分列更新模型和聚合表），能够灵活满足数仓构建需求；
提供多种changelog模式（如 Lookup 或 Full Compaction），可覆盖更多业务场景；
完善的生态系统，可通过 StarRocks 对 Paimon 表进行查询加速，为 ADS 层的分析和查询提供高效支持。

2 Hudi 转 Paimon 收益

今年一季度，我们成功将基于 Hudi 的流式数仓全面转化为基于 Paimon 的流式数仓。这一升级带来了显著收益：

资源节约：ODS 同步任务的资源消耗减少约 30%；
写入性能提升：写入效率提高了约 3 倍；
查询性能优化：尤其在点查场景中，得益于 Paimon 底层文件的有序性，查询性能显著提升。

目前，ODS 入湖任务已达 2000多个，Paimon 的存储总量接近 600TB。同时，我们将原有的 1000 多张 Hudi 表切换到 Paimon，实现了 Hudi 表的全面下线。

3 湖仓一体架构设计

我们整个存储架构底座基于联邦 HDFS 构建，入湖数据源主要包括 binlog 和服务器日志。

ODS 层：

binlog 和服务器日志的数据通过 Flink同步任务流式写入 Paimon，用于构建 ODS 层数据。在这一层完成数据清洗和初步处理后，利用 Flink 对 Paimon 表的数据进行进一步加工，构建 DWD 层。

DWD 层：

在 DWD 层，使用部分列更新模型，将 Paimon表数据打宽，并进一步使用 Paimon 的聚合表模型对明细宽表数据进行聚合，生成 DWS 层的数据。

DWS 层与 ADS 层：

DWS 层的数据可通过两种方式供 ADS 层使用：直接通过 StarRocks 查询 Paimon 外表，或将 Paimon 数据导入 StarRocks 本地表。无论是哪种方式，都能够满足分钟级延迟的高效数据查询与分析需求。

整个链路实现了流批一体的存储与计算，存储依托 Paimon，计算则交给 Flink引擎完成。此外，数仓各层都可通过多种查询引擎（如 Flink SQL、Spark SQL、Trino 和 StarRocks）灵活访问，提供了极大的查询灵活性和扩展性。

4 湖仓应用场景

在 ODS 层，binlog 入湖是核心场景，需要支持近实时的更新能力。Paimon 在这一场景下表现出色，其延迟主要取决于 checkpoint 的间隔配置。此外，binlog 入湖通常包含两部分数据：初始的全量同步和后续的增量同步。全量数据体量较大，因此需要存储组件具备高性能、低资源消耗的写入能力，而 Paimon 能很好地满足这一需求。我们在使用过程中，也会出现一些由于使用姿势不正确导致的 MySQL 数据与 Paimon 数据不一致的问题。排查下来，一般是两种原因：

比较键问题：多条相同主键数据的sequence field字段相同，或者更新数据的比较键小于插入数据的比较键；
任务没有从状态重启。

在 DWD 层，主要场景是对上游 ODS 层的 Paimon 表进行明细数据的打宽。在此过程中，建议使用 consumer 来流式读取数据，因为它可以记录读取进度，确保任务重启后能够从上次读取的位置继续。

由于 Paimon 读表是先读取全量数据，再读取增量数据，初次读取全量数据时可能会比较慢。为了提高效率，我们对流读取进行了分区和bucket的均衡，避免受到 bucket 数量的限制。特别是在初次读取时，可能会涉及多个分区。此外，在该场景下，我们还会使用 Paimon 的部分列更新功能，并将 Paimon 作为维表进行打宽操作。

在 DWS 层，Paimon 提供的表组件模型支持多种聚合函数，能够满足不同业务需求。但使用聚合表时需要注意：聚合依赖于 changelog，需要将Paimon源表changelog-producer指定为 full compact 或 lookup 模式，否则聚合数据可能不正确。对于回撤数据的处理，某些聚合函数不支持回撤，因此需要配置忽略回撤数据，否则任务可能会重启。

在 ADS 层，主要通过 StarRocks 查询 Paimon 外表，也可以通过物化视图加速查询，或将 Paimon 数据导入到 StarRocks 本地表中进行查询。

我们来看看一个湖仓具体的应用场景，要构建一个实时订单宽表，这个表包含多个维度表，如产品维度、城市维度、供应商维度等。除了主表，还有多个扩展表，如订单跟踪表、付款信息表和订单产品数量表。业务需求是将这些表进行打宽，构建日游订单的宽表，确保数据实时更新，以支持日常运营、动态补货及营销策略分析。

针对这一场景，传统解决方案通常使用 Flink 和多流 Join 来构建大宽表。该方案通过使用状态进行多个流的拼接，由于涉及数据打宽和聚合，状态也比较复杂。此外，订单的基表也需要聚合成聚合表，并且考虑到订单的预定周期和退款问题，状态的保留周期通常较长。

然而，基于这种方案存在几个挑战：

数据修正难度大：当扩展表的数据生成逻辑发生错误时，修正需要重置多个流，回滚到问题发生前的状态。
内存使用高：由于打宽和聚合操作依赖于状态，任务所需的内存非常大，导致稳定性下降。
难以扩展：当需要添加新表时，扩展操作复杂且困难。

相较之下，使用 Paimon 可以将多条流union，通过部分列更新模型，实现局部更新，能够更高效地构建日常更新的订单宽表。

优化后，多条流表的拼接不再发生在内存状态中，而是在存储层进行，这带来了以下优势：

整个任务的内存消耗较少，运行更加稳定。
无需担心复杂的状态保留周期。
数据修复简便：可以通过重置单链路的消费者轻松解决修复问题。
灵活扩展：新扩展表的加入变得非常方便，任务的可扩展性增强。

下面是具体SQL和算子 DAG 图。创建了一张Paimon大宽表，指定merge-engine为"partial-update"，使用 sequence group 来控制多个流中每条流的更新字段。订单主表与多个维表（包括 Hive 和 Paimon 的维表）join后，与多个扩展表union，最终生成一张订单大宽表。

StarRocks 如何加速湖仓查询？

数仓构建完成后，重点转向了下游 ADS 层的数据使用。在此环节，我们特别关注数据分析与查询的高效性，最终选择 StarRocks 作为核心查询引擎。

我们是在 2022 年为了解决当时使用的 OLAP 查询引擎的一些问题，正式引入了 StarRocks。此前，公司主要使用的两个 OLAP 引擎是 ClickHouse 和 GreenPlum，但各自存在明显局限性：

ClickHouse：在单表查询场景下表现优秀，但多表关联查询性能较差，无法满足复杂查询需求。

GreenPlum ：在面对高并发查询时表现出瓶颈，频繁发生死锁，严重影响系统稳定性。

截至目前，StarRocks 成为公司最主要的 OLAP 查询引擎。同程内部已部署了十余个 StarRocks 集群，涵盖多个版本（2.3、2.5 和 3.2）。整个集群拥有 5000+ 核计算资源，总存储容量达到 300TB+。

1 Paimon 外表

Paimon 外表的使用依托于 StarRocks 对外部 Catalog 抽象，通过实现 Paimon Catalog 的相关接口，用户可以直接通过 SQL 查询 Paimon外表。用户可以通过SQL创建指定类型为 Paimon的 Catalog，同时配置 warehouse 路径和 metastore.uris 地址。配置完成后，查询时只需在库表名前加上 Catalog 前缀即可。

Paimon 外表允许用户无需将数据导入 StarRocks，即可查询 Paimon 表，非常适合大部分湖仓分析场景。我们使用TPCH 10G数据集进行测试，发现 StarRocks 查询性能相较 Trino 提升了 4 到 10 倍。

2 Data Cache

在湖仓查询场景中，如果外表数据存储在远程 HDFS 上，大部分查询耗时通常集中在远程磁盘 I/O 和网络 I/O 上，尤其在频繁查询热点数据时，容易出现重复拉取远程数据的问题。

Data Cache 会将外部存储系统中的原始数据按块切分，并按需缓存到 StarRocks 本地节点，从而避免重复的数据拉取。缓存的命中率多少将直接决定了性能提升的幅度。对TPCH 10G数据集的查询耗时测试结果：

无缓存：查询耗时为数十秒；
缓存完全命中：查询耗时降至 0.几秒，较无缓存的情况下性能提升可达百倍。
不过，需要注意的是，缓存性能的提升在很大程度上取决于具体查询的缓存命中率。在理想情况下（缓存完全命中），性能提升非常显著，但在实际场景中，效果可能因数据分布和访问模式的不同而有所差异。

3 异步物化视图

在对大表进行复杂查询（如关联、聚合或 ETL 操作）时，查询耗时可能很久，此时可以使用异步物化视图来提升查询性能。异步物化视图存储的是基于基表和特定查询语句的预计算结果，可以理解为一种特殊的物理表，其查询效率非常高。

灵活支持多表：物化视图可以基于内表、外表或已有物化视图构建，支持多表关联。
异步刷新：支持自动异步刷新，也可通过 SQL 手动刷新数据。如果基表是分区表，还可以创建分区物化视图，仅刷新部分分区，从而节省资源。
自动改写：查询基表时，系统会自动判断是否可改写为物化视图查询，避免重复计算基表数据。

例如，用户可以创建一个按订单 ID 分组的物化视图，统计每个订单的商品总额，并设置按天刷新。在查询中，如果物化视图可用，StarRocks 会直接返回视图数据，大幅降低计算开销。

在数据仓库的典型链路中，数据通常会经历以下步骤：binlog 摄取后写入到 ODS 层的 Paimon 表，再逐步构建下游的 DWD 层表、DWS 层表，最终同步至 StarRocks。这种链路相对较长，通常耗时为分钟级，适合对延迟要求不高的场景。然而，对于一些需要秒级时延的业务场景，并且没有数仓需求的表，这样的链路显然不够高效。

为此，可以选择更简单的链路：通过 Flink 任务将 binlog 数据直接同步到 StarRocks 表中。

这种方式不仅链路简洁，可以实现秒级时延，同时保留了 StarRocks 表高效查询的优势，非常适合用于没有复杂依赖的独立表。

StarRocks 存算分离实践

1 存算分离背景

在前一部分，我们讨论了使用 StarRocks 加速湖仓查询的一些手段。随着同程旅行内部 Paimon 表的推广，其数据量增长迅猛，基于 StarRocks 查询 Paimon 表的需求也显著增加。这种情况下，系统对 StarRocks 的资源需求大幅提高。然而，传统的存算一体架构在资源扩展上存在一定限制：节点扩容不仅涉及较高的成本，还需要进行复杂的数据迁移，导致计算节点的扩展缺乏弹性。

除了 StarRocks 外表查询 Paimon 表的需求增加，内部还存在一些 Hive 表查询需求。在离线场景中，通常通过 Broker Load 方式将 Hive 数据导入到 StarRocks 内表，然后在内部的灵动分析平台上进行分析和报表展示。这种链路虽然满足了功能需求，但也存在一些不足：数据需存储两份（Hive 和 StarRocks），且需要额外的导入任务。

此外，在 Ad-hoc 查询场景中，也会使用 Presto 引擎对 Hive 数据进行快速取数。然而，Presto 在大规模数据查询场景中的性能表现相对较低。为了解决这些问题，我们引入了 StarRocks 的存算分离架构。

StarRocks 存算分离架构的核心在于数据存储与计算资源的解耦。数据存储在远程分布式存储上，可以是对象存储（如 S3）或 HDFS，而本地节点主要负责缓存热数据，以实现查询加速。

存算分离架构的集群由 FE 节点和 CN 节点组成。其中，CN 节点替代了存算一体架构中的 BE 节点，专注于计算任务的执行。从架构模式上看，存算分离的集群与存算一体的集群是独立的，现有存算一体集群无法直接升级为存算分离集群，必须重新搭建。

2 存算分离收益

在离线分析场景中，我们直接使用 StarRocks 查询 Hive 的外表，相较于原来先将Hive数据导入Starrocks，然后再去查Starrocks内表的流程，之前需要同时维护Hive 和 StarRocks 内表两份数据，并且依赖额外的离线导入任务，而现在只需保留一份数据存储，显著降低了存储和计算成本。尽管查询性能相比 StarRocks 的内表稍慢，但在满足业务需求的前提下，这种方式完全可行。

在即时查询场景中，我们将 StarRocks 引擎替换了 Presto 引擎，用于快速取数。在对 TPCH 100G数据集进行查询测试，StarRocks 的查询性能相比 Presto 提升了 2 到 5 倍，有效支撑了更高效的业务查询需求。

海外业务的链路与国内略有不同。海外链路采用 binlog 直接同步到 StarRocks 内表，并通过物化视图完成 ETL 操作，构建数仓分层。数据存储在 S3 上，显著降低了存储成本，同时脱离 Hadoop 生态，简化了系统依赖。这样的架构使得系统从零开始快速上线成为可能。

目前，海外业务中使用的 StarRocks 集群配置如下：

计算资源：约 200 核
数据表：500+
物化视图：50+
查询性能：TP99 在 10 秒以内

未来规划

版本升级与新特性应用

当前系统使用的是 Paimon 0.6 版本，计划在未来 1-2 个月内升级到 Paimon 0.9 版本。升级后，将应用 DV 表特性，进一步提升 Paimon 的查询效率。

湖仓应用场景拓展

实时场景：目前，湖仓架构已成功应用于机票和景区订单等实时业务场景。未来，计划与更多业务团队合作，拓展湖仓架构的应用范围。尽管 Paimon 相较于 Hive 提供了更好的性能，但其用户使用门槛较高。因此，我们将积极介入，为业务团队提供支持和指导，降低使用门槛。
离线场景：推动 Hive 向 Paimon 的转型应用，优化离线数据存储与分析效率。同时，着力完善 Paimon 的生态体系，包括包括表管理服务优化以及 Spark 版本升级（当前 Spark 版本不支持写入 Paimon，未来将通过版本升级解决这一问题）

StarRocks 功能扩展

智能化物化视图创建：根据查询需求，自动创建物化视图，减少人工干预，提升查询性能。
物化视图管理平台：提供可视化界面，便于查看物化视图列表、基表及依赖关系、刷新进度等关键信息。

统一查询引擎：

逐步下线 ClickHouse 和 Greenplum，实现统一的 StarRocks 查询引擎架构。

关于 StarRocks

Linux 基金会项目 StarRocks 是新一代极速全场景 MPP 数据库，遵循 Apache 2.0 开源协议。

面世三年来，StarRocks 致力于帮助企业构建极速统一的湖仓分析新范式，是实现数字化转型和降本增效的关键基础设施。目前，全球 450 家以上市值超过 70 亿元人民币的顶尖企业选择用 StarRocks 来构建新一代数据分析能力，这些企业包括腾讯、携程、平安银行、中原银行、中信建投、招商证券、大润发、百草味、顺丰、京东物流、TCL、OPPO 等。StarRocks 也已经和全球云计算领导者亚马逊云、阿里云、腾讯云等达成战略合作关系。

StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 9200，吸引了超过 450 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。