作者：
范振: 阿里云计算平台开源 OLAP 负责人，StarRocks 社区 Champion
翁才智: 阿里云技术专家，Apache Paimon PMC Member
导读：阿里集团在推进湖仓一体化建设过程中，依托 StarRocks 强大的 OLAP 查询能力与 Paimon 的高效数据入湖特性，实现了流批一体、存储成本大幅下降、查询性能数倍提升的显著成效：
A+ 业务借助 Paimon 的准实时入湖，显著降低了存储成本，并引入 StarRocks 提升查询性能。升级后，数据时效提前60分钟，开发效率提升50%；JSON列化存储减少50%，查询性能提升最高达10倍；OLAP分析中，非JOIN查询快1倍，JOIN查询快5倍。
饿了么升级为准实时Lakehouse架构后，在时效性仅损失1-5分钟的前提下，实现Flink资源缩减、StarRocks查询性能提升（仅5%性能损失），存储成本降低90%。
阿里集团数据湖项目背景
在过去的十几年中，Hadoop 体系一直是大数据领域的主流架构。无论是大型企业还是中小型企业，大家普遍采用的都是基于 Hadoop 和 Lambda 的架构。具体来说，在离线处理方面，Hive 和 Spark 是主要的工具；而在实时处理领域，Flink 已经成为一种事实标准。在 OLAP 领域，过去几年呈现出百家争鸣的局面，但最近两三年，StarRocks 的市场份额显著增加。
Hadoop 和 Lambda 架构为各公司带来了巨大的商业成功，无论是在数据处理量上，还是在替代传统数据库方面，都发挥了重要作用。以阿里集团为例，其整体架构与行业主流类似，但采用了自研体系，包括 MaxCompute 用于离线处理，以及 Flink 用于实时处理。此外，阿里还推出了 MaxCompute 和 Hologres 等产品，进一步完善了其大数据体系。
然而，Hadoop 和 Lambda 架构也面临着一些挑战，例如需要维护两套架构，存在代码重复编写、数据冗余、开发口径不统一以及数据孤岛等问题。为了应对这些挑战，近年来我们观察到行业趋势主要体现在以下三个方面：
Lakehouse 架构的兴起：Lakehouse 作为一种融合了数据湖和数据仓库优势的架构，已经成为行业共识。无论是北美还是国内，Lakehouse 架构的接受度都非常高。
开源与社区的力量：开源社区逐渐成为数据领域的主流方向，许多开源公司不断进化，StarRocks 就是其中的佼佼者。
AI 与 BI 的融合：AI 技术在近年来形成了浪潮，AI 与 BI 系统的融合，特别是在元数据打通和开放性方面，已经成为架构升级的必然需求。
基于这些趋势，阿里集团进行了深入思考，希望对整体数据架构进行升级，以实现以下目标：
流批统一：通过一套代码和统一的架构，简化运营成本，提升开发效率。
统一存储：寻找低成本的存储解决方案，降低数据存储成本。
高性能分析：在不牺牲业务体验的前提下，选择一款优秀的 OLAP 引擎或 Lakehouse 引擎，推动架构升级。
数据统一：实现结构化与非结构化数据的统一，为 AI 与 BI 的融合提供支持，确保“Data for AI”和“AI for Data”在阿里集团顺利落地。
全面升级为 Lakehouse 架构
阿里集团的整体目标与阿里云的目标有着高度的一致性。在2024年的云栖大会上，阿里云推出了名为 OpenLake 的架构。这一架构旨在通过低成本、高可靠的存储解决方案（如阿里云 OSS）构建数据湖。在数据湖格式方面，目前行业内逐渐形成了以 Delta Lake、Hudi 和 Iceberg 为代表的“数据湖三剑客”，以及新兴的 Paimon 等优秀技术。这些技术致力于将传统数据库中的事务特性（如 MVCC、Time Travel 和 Schema Evolution）引入数据湖。
在元数据管理层面，阿里云推出了DLF （Data Lake Formation），而开源社区则有 Polaris、Databricks 推出的 Unity Catalog 等解决方案。这些工具旨在实现 AI 与 BI 的统一管理，为数据湖提供强大的元数据支持。
在计算引擎方面，目前没有一种“万能”的计算引擎，每种引擎都有其适用场景。无论是大数据处理还是 AI 搜索，都存在众多开源和闭源的引擎选择。阿里集团参考阿里云的 OpenLake 体系，进行了自身的架构升级，并且对各种湖格式和 Lakehouse 引擎进行了深入调研。
Why Paimon？
最适合流/批/OLAP 统一的湖格式
在数据湖格式的选择上，业界已经形成了广为人知的“数据湖三剑客”：Delta Lake、Hudi 和 Iceberg。在过去几年的竞争中，这些格式各有优劣，有的逐渐脱颖而出，而有的则在慢慢消退。然而，根据我们的观察，在与 Flink 对接以构建 Streaming Lakehouse 的场景中，这三种格式在设计上都存在一些底层缺陷。
众所周知，构建实时数据库或实时数仓的核心架构通常是 LSM（Log-Structured Merge）架构。这种架构是实时处理的基石。然而，无论是 Iceberg 还是 Delta Lake，它们本质上用的不是这一套的设计思想，这导致它们在支持实时处理和与 Flink 对接时存在诸多不足。
从阿里集团的观察来看，Iceberg 和 Paimon 将成为最具潜力的两种数据湖格式。在北美，像 Snowflake 和Databricks 这样的行业巨头已经将 Iceberg 作为首选支持的数据湖格式，其他格式则被放在次要位置。在国内，由于 Flink 已经成为流处理的事实标准，并且是流批一体的重要引擎，我们预计 Paimon 将成为国内数据湖格式，尤其是 Streaming Lakehouse 场景中最理想的选择。
在最近的 Flink Forward Asia（FFA）大会上，Paimon 推出了1.0版本。这个版本非常可靠，已经可以作为大规模商用的版本。
Paimon 的诞生背景与优势
随着互联网发展，大数据时代来临。用户使用企业产品时会产生大量行为日志，如点击、购买等。高效存储和处理这些日志，以供下游业务部门分析并据此调整策略，是大数据架构的关键任务。
离线数仓是典型的大数据架构，通过定时调度处理上一时间段数据，具有架构简单、适用范围广、中间结果便于查询等优点，且夜间运行可提升集群利用率。但其痛点是延迟高，通常每小时或每天调度一次，无法满足对实时性要求高的业务，如电商大促或异常行为监测。此外，离线数仓更新成本高，需读取原分区数据与新变更合并后覆盖原分区。
流计算引擎的出现催生了实时数仓，其通过消息队列作为中间存储，解决了离线数仓的延迟问题，但消息队列中的中间结果难以查询，增加了数据复用和问题排查的难度。流计算过程中的状态计算成本较高，如 Flink 的 Flink State 功能虽支持毫秒级延迟查询，但需将数据存储在本地高速磁盘，数据量大时会增加计算和存储成本。且在物流等数据有效周期长的业务场景中，很难在短时间内让数据过期，需在成本与正确性间权衡。
从准确性、低成本和时效性三个维度看，离线数仓和实时数仓各有优劣，目前企业大多以离线数仓为主，部分重要业务采用实时链路，形成 Lambda 架构，但同时维护两条链路会增加成本。因此，探索一种既能保留现有架构又能兼具两者优势的折中方案，是 Paimon 的目标。
流式湖仓架构
Paimon 是一种流批一体的数据湖格式，支持实时更新、海量追加、高效查询和数据管理四大核心能力。在更新能力方面，Paimon 的主键表支持大规模更新写入，并且具备出色的更新性能，这得益于其创新性地引入了 LSM Tree 数据结构来处理更新操作。此外，在更新数据时，Paimon 允许用户选择多种更新方式，如打宽、聚合或覆盖等，并且能够生成完整的变更日志，便于下游进行流式消费。
最重要的是，所有变更都能在分钟级延迟内完成，满足了众多业务对时效性的需求。在追加能力方面，Paimon 的非主键表支持大规模流处理和批处理，并且能够自动进行小文件合并，这不仅降低了存储集群的运维压力，还进一步提升了读写效率。在查询能力方面，Paimon 支持了包含 Z-order、索引、Deletion Vector 等多种优化技术，结合 StarRocks 等引擎，可以实现高效的 OLAP 查询。
在数据管理方面，Paimon 的系统表支持查询分区、分桶、文件等元数据信息，并且支持分支管理和时间旅行等功能，方便用户查询不同版本的数据。
这些能力对用户意味着什么？对于离线数仓用户而言，如果采用 Paimon 作为中间存储，无需更改计算链路，即可获得低成本的更新能力，同时保留中间层数据的可复用性。如果后续对时效性有更高要求，也可以借助实时计算引擎，让数据在数仓中以分钟级延迟流动起来。此外，用户还可以将常见的 ETL 操作（如打宽、聚合）下推到 Paimon 中，以降低计算成本。
最后，由于计算结果由 Paimon 统一存储，用户无需维护两套存储链路，从而降低了维护成本。通过这一过程，我们构建了一套以 Paimon 为存储核心的流式湖仓架构。
飞速发展的生态与用户采纳
Paimon 除了以上核心功能之外，还具备非常丰富的生态体系。在核心存储方面，Paimon 支持包括 ORC、Parquet 和 Avro 等常见的大数据文件格式，同时也支持 HDFS、阿里云 OSS 以及 AWS S3 等常见的分布式存储。在数据源方面，Paimon 支持包括 MySQL、Kafka 在内的常见数据源的数据摄入。在数据消费方面，Paimon 实现了引擎的平权发展，无论是 Flink、Spark 这样的流批计算引擎，还是 StarRocks、Trino 这样的查询引擎，都能方便地读取 Paimon 的数据。此外，Paimon 最近也在尝试解锁包括 Rust、Python 在内的多语言支持，希望在机器学习等更多场景中进行进一步探索。
作为新兴的数据湖项目，Paimon 发展迅速。过去两年，社区专注于核心功能研发与项目孵化。 2024年，Paimon 在应用层面取得重大突破：在阿里集团内部的 Alake 数据湖项目中，将统一集团数据湖存储；阿里云的 OpenLake 项目也将围绕 Paimon 构建高效流式湖仓产品线。此外，Paimon 还广泛应用于字节跳动、同城旅行、快手、网易等众多企业，助力其实现更实时、更开放、低成本的数据管理。
Why StarRocks？
查询 Paimon 湖格式性能最好的开源引擎
在探讨完 Paimon 的优势后，接下来需要选择一款 Lakehouse 引擎，以优化 Paimon 的查询性能。我们的结论是：StarRocks 是最适合 Paimon 湖格式的 Lakehouse 开源引擎。以下是我从几个方面对这一结论的思考：
性能卓越
StarRocks 是目前性能最好的开源引擎之一。阿里云团队在 StarRocks 数据湖查询方面投入了大量资源，最初支持了 Hive 引擎，随后扩展到 Hudi 和 Iceberg，并与社区共建了许多特性。
在 Hive 引擎方面，我们经常收到客户和社区用户的反馈，包括阿里云的许多客户。在 Benchmark 测试中， StarRocks 的性能比 Trino 快约4倍，而在实际生产业务中，性能提升通常在3到6倍之间。这主要取决于算子的复杂度和 I/O 访问量。在 Paimon 中，我们甚至看到了13倍的性能提升，这一数字非常惊人。
技术优势
Paimon 继承了StarRocks 在查询 DLA 方面的所有优势，这些优势可以总结为以下几点：
更优的查询计划器：包括 CBO（Cost-Based Optimizer）和对 SDK 元数据的缓存策略，如 table、partition 和 manifest 等，以确保查询计划的最优性。
C++ 编写与向量化：StarRocks 使用 C++ 编写，并全面实现了向量化，包括向量化算子、Parquet Reader 和ORC Reader 等，这使得其在性能上优于 Trino。
针对 OSS 的优化：我们对 OSS 进行了大量专业优化，这些优化不仅适用于通用场景，还针对 Paimon 进行了许多专有优化，如支持 Paimon 的 DV 表、缓存元数据和索引等。
从动态角度看，引擎的发展是循序渐进的。目前，StarRocks 对 Paimon 的支持表现出色，很多优势源于 StarRocks 利用了 Paimon 的独特特性，例如 Paimon Deletion Vector 以及 Manifest Cache 等。如果 Trino 能够补齐这些短板，其性能也将显著提升，但最终 StarRocks vs Trino 仍然有望达到 3~5 倍的性能提升。
存算分离架构统一查询内表和外表
我们非常看重一套架构能够支持两种格式。在 StarRocks 中，我们把存算分离中的表称为内表，把 Paimon 或 Iceberg 这样的表称为外表（湖表）。我们使用存算分离统一架构来支持查询内表和外表。阿里云 EMR Severless StarRocks 正是基于此架构提供的服务。
这种架构有以下几个优点：
灵活的物化视图：社区持续推出功能日益丰富的物化视图。这一领域竞争激烈，要实现卓越表现仍需大量工作。
灵活的多表联邦查询：支持灵活的多表联邦查询，一个 SQL 中可能包含 Paimon 表和内表，但它们都统一在 OSS 格式上。
灵活的弹性和隔离：这是存算分离的天然优势。在存算一体架构中，扩容需进行数据平衡和搬移，操作复杂且耗时；而在存算分离架构中，扩容仅需调整元数据，过程轻量且可实现多种调度策略。
统一的缓存管理：鉴于 Paimon 是外表，StarRocks 内表在 OSS 上也是远程表访问，统一的缓存管理十分必要。通过一套架构和缓存管理，实现读取 Paimon 和内表的最快速度。当前现状是，尽管我们希望用 Paimon 构建整个湖仓，但部分业务因快速发展需求，需借助内表的垂直领域特性，如直接从 Flink CDC 消费 Kafka 并利用 StarRocks 的特性。此外，Paimon 目前缺失对半结构化数据（如 JSON）的处理能力，而集团中有大量埋点 JSON 数据需分析，需通过 Flat JSON 导入内表进行优化，以达到理想效果。
强大的社区力量
阿里集团与阿里云合作紧密，阿里云在 StarRocks 上投入已久，我们的团队在社区中深耕多年，对 StarRocks 内核引擎了如指掌，积累了丰富经验。从人力协作和成本角度看，这点至关重要。
更重要的是，我们背后有强大的社区支持。无论是在海外还是国内，社区对 Lakehouse 的发展，尤其是对 Iceberg 和 Paimon 的坚定支持与规划，是我们极为看重的。这也是我们选择的技术发展路线和未来投资方向。因此，我们坚信 StarRocks 是值得长期技术投入的社区。阿里集团的团队也将在2025年继续与社区紧密合作，共同推动发展。
StarRocks x Paimon 在阿里集团的业务应用
A+流量分析
最后，分享两个实际的业务案例。
首先是阿里集团的 A+ 业务，这是阿里所有 APP 的流量域，涉及众多业务方，数据规模庞大。改造前，A+ 业务采用典型的 Lambda 架构，离线使用 MaxCompute 处理，实时则构建了独立链路，继承了 Lambda 架构的优缺点，如开发效率低、实时性不足等。
改造后，我们将架构从 Lambda 转变为准实时架构，离线链路升级为准实时链路。这一转变对 A+ 流量域来说已经足够，实现了显著的成本节约，并大幅提升数据时效性。
A+ 业务是一个典型的数仓架构，包括 ODS、DWD、DWS、ADS 等层次。StarRocks 在这一体系中直接查询 Paimon 的 ADS 层和 DWS 层，这是 StarRocks 直接访问湖表的链路。
另一条链路涉及 JSON 类型流量埋点，数据量极大，Paimon 中难以有效查询，时效性较低。我们通过 StarRocks 3.3 版本后推出的 Flat JSON 特性（与社区共同打磨的成果）来解决这一问题。Flat JSON 在阿里集团已有大规模应用，通过对 JSON 列进行解析和优化，查询性能提升了十倍以上。
总体而言，通过 Paimon 的准实时入湖，我们大幅降低了存储成本，并引入了 StarRocks。在可接受的时效性范围内，OLAP 数据导入的性能虽有小幅下降，但业务价值大幅提升。以下是架构升级所带来的具体收益：
流批一体：数据时效提前60分钟；开发效率提升50%；业务获取分钟数据门槛降低
Flat JSON：JSON 列化后存储减少50%；JSON 列化导入百亿分钟级；查询性能提升10倍
OLAP 分析：非 JOIN 类场景快1倍；JOIN 类查询快5倍
饿了么
饿了么最初采用 Lambda 架构构建，离线部分使用 MaxCompute 处理，实时部分经历了两个阶段：第一阶段是实时数仓1.0，采用 Flink+Kafka 的 Kappa 架构；第二阶段升级为实时数仓2.0，使用 Flink+Hologres 构建。然而，这种架构继承了 Lambda 架构的痛点，如开发效率低、存储成本高。由于使用 SSD 存储两份冗余数据，成本极高。此外，Kappa 架构中无法直接查询 Kafka 数据，导致数据未被充分利用。
升级为准实时 Lakehouse 架构后，收益显著。业务在时效性上仅损失1到5分钟，但获得了以下收益：Flink 资源减少、StarRocks 查询性能提升，查询性能损失仅为5%，而存储成本减少了90%。
在选择数据格式时，饿了么经过大量调研，对比了 Paimon 和 Hudi。Paimon 在时效性上比 Hudi 提高了两倍，因为它与 Flink 的结合更为紧密。
未来展望
最后，我们来看一下阿里集团后续的规划与展望。如之前所述，阿里集团正在推进 Alake 战役，其核心目标是全面升级 Lakehouse 架构。我们将以 Paimon 为底座，并结合 OpenLake，计划引入更多计算引擎，以实现业务接入的灵活性和多样性，为每个业务选择最适合的计算引擎和链路。底层则计划统一采用 Paimon 的湖格式。
在2025年，我们将大规模推进业务接入，探索更多使用方式，并积极与业界分享经验，同时也会为社区做出更多贡献。