Apache Paimon C++ ：从阿里数据湖走向开源社区

Apache Paimon C++ v0.3.0 正式发布。作为 Apache 基金会下的首个正式版本，这标志着源自阿里内部数据湖需求的 Paimon C++ 项目，正式以社区化模式面向全球引擎与开发者开放。

回溯至 2024 年 1 月，阿里巴巴集团确立 Apache Paimon 为统一数据湖表格式。然而，集团内部广泛使用的 ODPS、StarRocks、Native Flink 及 Native Spark 等均为 C++ Native 引擎。这些引擎亟需一套不依赖 JVM、能完整解析 Paimon 表语义并充分发挥 Native 性能的读写库，而非简单的文件读取器。

为此，由阿里巴巴智能引擎团队主导的 Paimon C++ 应运而生。该团队长期服务于淘宝、高德、菜鸟等核心业务。项目并未简单移植 Java 实现，而是基于对多引擎执行模型与真实负载的系统性调研，设计了一套以 Arrow 批式数据交换为基础、支持深度插件化定制的 Native Paimon C++ SDK。

历经近两年生产验证，Paimon C++ 已在阿里数据湖稳定支撑数 EB 数据。自 2025 年 12 月在 GitHub 开源以来，吸引了蚂蚁、字节、云器等团队共建。此次 v0.3.0 进入 Apache 社区，开启了新的里程碑。

01

在进军 Apache 社区前，Paimon C++ 已在多种引擎、产品及业务场景中完成接入与实践：

• 大规模生产使用：Native Spark（Gluten + Velox）、StarRocks、Native Flink 已在生产环境大规模应用其读写能力；
• 开源社区接入：已形成 DuckDB 社区扩展、字节跳动 Bolt、Apache Doris 等生态接入；
• 云上产品接入：StarRocks、Milvus、DuckDB、Spark 和 Hologres 等云产品正在接入或使用；
• 内部业务验证：蚂蚁集团（Spark、OceanBase、Explorer）、字节跳动 TokaDB、云器等内部业务已开展使用；
• 即将接入：下一步将启动 ClickHouse Native 接入，进一步覆盖高性能 OLAP 查询场景。

面对执行框架、数据格式及内存管理等差异巨大的接入场景，Paimon C++ 旨在让各引擎在保留自身性能优势的同时，共享统一的 Paimon 表语义。

集团统一采用 Paimon 后，Native 引擎面临的首要挑战是如何正确、高效地访问 Paimon 表。直接读取对象存储中的 Parquet 或 ORC 文件远不足够，因为 Paimon 表的有效数据是由 Schema、Snapshot、Manifest、Partition、Bucket、索引及更新合并规则共同确定的复杂集合。引擎必须正确处理：

• 当前 Snapshot 对应的数据文件集合；
• Append 表与主键表各自的读取、更新与合并语义；
• Merge-on-Read、Deletion Vector 和 Compaction 的结果生成机制；
• 统计信息、文件索引和全局索引的数据裁剪逻辑；
• 写入结果与 Paimon 表版本及格式协议的兼容性。

若每个引擎单独实现一套 Reader/Writer，不仅建设成本高，且难以保证格式兼容性与长期维护性；若所有数据绕回 JVM 处理，则无法发挥 Native 引擎在向量化执行与 I/O 优化上的既有优势。

因此，Paimon C++ 确立了“完整理解 Paimon 表语义”的目标：计算引擎继续负责分布式调度与算子执行，而 Paimon C++ 专注于 Scan、Read、Write、Commit、Compaction 及相关格式与表语义的处理。

Paimon C++ 专为 Native 引擎执行方式设计，而非 Java 实现的简单迁移。基于对不同引擎场景的调研，一套适配 C++ 生态的湖表 SDK 需满足以下四类诉求：

直接适配向量化执行

分析型引擎普遍以列式 Batch 为单位计算。Paimon C++ 采用 Arrow C Data Interface 作为主要数据交换边界，读取与写入均直接通过 Arrow Batch 进行。这种设计减少了逐行对象转换与不必要的数据复制，自然衔接向量化算子与并行执行。同时，该接口避免了将 SDK 绑定到特定 Arrow C++ 版本，降低了 ABI 冲突与集成成本。

保留引擎已有的性能能力

不同引擎在文件读取、缓存、内存管理及任务调度上已有深厚积累。Paimon C++ 设计了面向 Native 引擎的插件化扩展机制，允许引擎接入自定义组件：

• Format Reader/Writer：复用已有的 ORC、Parquet 等格式实现；
• FileSystem：复用现有的对象存储访问、缓存和限流能力；
• MemoryPool：接入引擎自身的内存统计、限额和回收体系；
• Executor：复用引擎内部的线程池与任务调度能力；
• Indexer：支持引擎按需定制索引实现。

例如，StarRocks 接入时复用了内部带 Block Cache 的文件系统，延续了原有缓存与 I/O 优化优势；字节跳动 Bolt 通过实现 Parquet 插件，保留了其精心优化的格式读取能力。此外，引擎还可注入自有 MemoryPool，统一观测资源使用并与内部调度策略协同。

同时提供高效的默认实现

在开放定制能力的同时，Paimon C++ 也提供了一套高效的默认实现，涵盖 ORC、Parquet、Avro 等格式插件，Local、Jindo、S3 等文件系统，以及默认 MemoryPool、Executor、元数据缓存和各类全局索引。引擎既可开箱即用，也可仅替换关键组件，在通用性与专属性能间灵活选择。

与 Apache Paimon 保持格式和协议兼容

Paimon C++ 原生实现 Paimon 表语义，并严格保持与 Apache Paimon Java 版本在 Manifest、Data Split、Commit Message 等关键数据结构上的兼容。这确保了不同语言和引擎可共享同一张 Paimon 表，无需维护割裂的格式分支。

Paimon C++ 的核心能力可归纳为五点：

将完整 Paimon 表语义带入 C++ 生态
作为覆盖 Scan、Read、Write、Commit、Compaction 等操作的表级 SDK，全面支持 Append 表、主键表及 Merge-on-Read、Deletion Vector 等关键语义。

设计基于 Arrow 的 Native 批式数据通路
通过 Arrow C Data Interface 交换列式 Batch，使 Paimon 数据直接进入 Native 引擎的向量化执行链路，消除逐行转换与跨语言交互开销。

建立可深度定制的插件化架构
FileFormat、FileSystem、MemoryPool 和 Executor 均可由引擎定制。引擎可复用经过验证的基础设施，同时由 Paimon C++ 统一维护表格式、协议及一致性语义。

围绕 Native 读写链路进行系统优化
针对 Native 链路进行了多项系统优化，包括读取侧的文件预取、Pipeline、多线程解码、异步 Row-to-Batch 和查询短路，以及写入侧通过分层 Spill Merge 减少临时文件重复读取和归并读放大。

从真实 Workload 出发扩展 Paimon 的能力边界
除传统分析外，还支持 Data Evolution、多模态数据和 Global Index，探索时序、动态 JSON、Free-schema 和实时数据等场景，推动成熟能力进入 Apache Paimon 标准。

Scan 与 Read：让计划和执行自然分离

Paimon C++ 将读取拆分为两个阶段：

• Scan：读取 Snapshot 和 Manifest，根据 Partition、Bucket、统计信息和索引裁剪无关文件，生成可序列化的 Split；
• Read：在不同 Worker 上并行读取 Split，执行列裁剪、谓词下推、Page Filtering、预取和缓存，最终返回 Arrow Batch。

Coordinator 集中生成查询计划，Reader Task 在各节点并行执行。Split 可跨进程和语言传递，数据通过 Arrow 批式进入后续计算。

Write 与 Commit：保留引擎的分布式执行模型

写入侧采用适合分布式引擎的两阶段模型：

• Write：Worker 接收 Arrow Batch，完成数据组织与文件写入，生成 Commit Message；
• Commit：Coordinator 收集各 Worker 的 Commit Message，由 Paimon C++ 处理 Manifest、统计信息、冲突检查和 Snapshot 提交。

引擎负责调度与数据交换，Paimon C++ 保障表版本、文件格式及提交语义的正确性。

目前，Paimon C++ 已支持 Append 表和主键表的读写，涵盖 Merge-on-Read、Deletion Vector 和 Compaction 等能力。

随着 AI Agent 应用的兴起，数据检索模式正发生变化：一次检索可能融合向量相似度、全文关键词及标量过滤，并返回文本、结构化字段或多模态数据。在 Data Evolution 表模式下，Paimon 为每行数据分配全局 Row ID，并通过 Row Tracking 保持稳定的行级定位。这使得同一张 Paimon 表可统一管理：

• 结构化数据；
• 文本与文档；
• Embedding 向量；
• 图片、音频、视频等 Binary/Blob 多模态数据。

查询模式扩展为“全局索引召回 + Row ID 精准点查”：

1. Global Index 根据条件召回候选 Row ID 及 Score；
2. Paimon C++ 结合 Snapshot、Manifest 生成 IndexedSplit；
3. Reader 根据 Row ID 精确读取所需字段或 Blob 数据。

Paimon C++ 当前提供基于 BTree 的标量查找、基于 Lucene/Tantivy 的全文检索、基于 Lumina 的向量检索，以及参与 Scan/Read 裁剪的各类文件索引。

该模式实现了“一份数据入湖，全部数据可检索”，避免了将结构化、文本、向量和多模态数据复制到多套系统带来的 consistency、成本与运维问题。

Paimon C++ 的价值不仅在于去除 JVM 和跨语言转换，更在于围绕 I/O、解码、数据复制及主键合并的系统级优化。

写入：降低 PK Spill Merge 的读写放大

主键表写入涉及排序与归并。当内存 Buffer 超限时，中间结果需 Spill 到临时文件。传统平铺式 Spill List 在后续归并中可能反复读取旧 Run，导致读放大。Paimon C++ 采用分层 Spill Merge，仅归并达到 Fan-in 阈值的当前层级，有效减少旧 Run 的重复读取，控制单次归并规模，在数据规模增大时保持稳定性。

读取链路的主要优化

1. 并行文件预取：同一文件可按 Row Range 分配给多个 Reader 并行 I/O 与解码；Reader 线程内部通过 Pipeline 重叠读取与解码过程，降低延迟。
2. 异步 PK Row-to-Batch：Sort Merge 生产端与 Arrow Batch 转换消费端通过有界队列解耦，消费端支持多线程转换 KeyValue 到 Arrow Batch。
3. COUNT(*) Short Circuit：针对 Append、PK+DV 及 PK MOR 场景，直接基于元数据或合并结果计数，避免构造完整 Value Batch 及不必要的框架转换开销。

此外，Scan 阶段利用多维度的裁剪策略，Read 阶段继续执行列裁剪、谓词下推等操作，从源头减少数据读取量。

以下数据来自 Alibaba 集团生产环境，对比了相关引擎切换至 Paimon C++ 前后的端到端性能。实际效果受数据分布、硬件配置等因素影响。

Native Spark：Gluten + Velox

测试对象为 PK Merge-on-Read 表，数据规模 119.32 GB，约 70 个文件存在主键重叠。

StarRocks Native Reader

测试环境为单 BE、8 Core / 32 GB，对比 StarRocks 引擎切换 Paimon C++ 前后的端到端查询性能。

结果表明，Paimon C++ 的价值源于对 Paimon 表语义的完整 Native 实现，以及在文件读取、主键合并和 Arrow 批式转换上的系统优化。随着数据规模扩大，其性能收益将更加显著。

从阿里内部业务到 Apache 社区，Paimon C++ 的核心目标始终如一：让 Native 引擎在不牺牲性能的前提下，完整、稳定地接入 Paimon 生态。未来，社区将同步推进两条主线：一是紧跟 Apache Paimon 主线，完善 Native Scan/Read/Write/Commit、REST Catalog 及 Changelog 等能力；二是基于真实需求，持续探索 AI、多模态、时序等前沿场景，将成熟经验沉淀为社区标准。

诚邀来自查询引擎、数据湖、AI Infra 等领域的开发者关注、试用并共建，共同完善 Apache Paimon 的开放生态！

相关链接

Apache Paimon C++ 官方仓库：https://github.com/apache/paimon-cpp

GitHub Release Note：https://github.com/apache/paimon-cpp/releases/tag/v0.3.0

使用文档：https://paimon.apache.org/docs/cpp/

Apache Paimon 官方网站：https://paimon.apache.org

Apache Paimon GitHub：https://github.com/apache/paimon

欢迎加入 Apache Paimon C++ 钉钉交流群，与社区开发者交流经验、讨论技术并参与共建。

使用钉钉扫描二维码，即可加入群聊