在近期的 Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共话实时湖仓 直播中，Apache Paimon PMC 成员/阿里云数据湖资深工程师叶俊豪带来了关于 Paimon 多模态数据湖的深度技术分享。

随着大模型训练对数据规模与多样性的要求不断提升，传统以批处理为中心的数据湖架构已难以满足 AI 工作负载对实时性、灵活性和成本效率的综合需求。特别是在推荐系统、AIGC 等典型场景中，工程师既要高频迭代结构化特征，又要高效管理图像、音频、视频等非结构化数据。面对这一挑战，Paimon 作为新一代流式数据湖存储引擎，正通过一系列底层创新，构建面向 AI 原生时代的统一数据基础设施。

一、结构化场景下的“列变更”困境

在推荐、广告等 AI 应用中，特征工程是一个持续演进的过程。例如，电商团队可能今天新增“用户近7日点击品类分布”，明天又加入“跨端行为一致性评分”。这种动态列变更导致“列爆炸”问题：表结构频繁扩展，而历史数据需与新特征对齐。

然而，已知的解决方案在此场景下仍然存在一些问题：

• 主键表 partial-update：虽支持按主键更新部分列，但其基于 LSM 树的实现会在写入频繁时产生大量小文件，查询性能急剧下降；Compaction 虽可合并文件，却带来数倍的临时存储开销。
• odps 存新特征值 + Join 拼接方案：将新特征写入独立表，查询时通过主键 Join 合并。看似避免了重写，但 Join 操作本身在 PB 级数据上开销巨大，且难以优化。
• Append 表 + MERGE INTO：SQL 语法简洁，但底层仍需重写整个数据文件。对于每天增量达 PB 级的训练集，全量重写不仅成本高昂，还显著拖慢特征上线周期。

这些方案本质上都未能解耦“列”的物理存储，导致灵活性与效率不可兼得。

二、Paimon 的列分离架构：以全局 Row ID 为核心

Paimon 提出了 列分离存储架构，其核心是引入 全局唯一且连续的 Row ID。每行数据在首次写入时被分配一个在整个表生命周期内不变的 ID，且每个数据文件内的 Row ID 是连续的，元数据会记录该文件的起始 Row ID。

这一设计带来两个关键能力：

1. 精准定位任意行：通过 Row ID 可直接定位到具体文件及偏移；
2. 跨文件自动关联：当查询涉及多个列时，系统能根据 Row ID 范围自动将分散在不同文件中的列数据在存储层合并。

例如，当新增“用户兴趣标签”列时，Paimon 仅需写入一个包含该列与对应 Row ID 的新文件，无需修改原始特征文件。查询时，引擎透明地将两组文件按 Row ID 对齐合并，无需 SQL 层 Join，也无需重写历史数据。这种机制将列变更的存储成本从 O(N) 降至 O(ΔN)，极大提升了特征迭代效率，同时节省了数十倍的存储空间。

三、迈向多模态：Blob 数据类型的三大突破

AI 训练不再局限于结构化特征。AIGC、多模态大模型等场景要求数据湖能高效处理图像、短视频、长音频等非结构化数据。这类数据具有两大特点：体积差异大（几 MB 到数十 GB）、访问稀疏（训练时通常只读取片段）。

传统列式格式（如 Parquet）将多模态数据与结构化字段混存，导致即使只查用户 ID，也需加载整个含视频的大文件，I/O 效率极低。

Paimon 引入 Blob 数据类型，实现三大突破：

1. 物理分离存储：Blob 列独立成文件，与结构化数据完全解耦。查询结构化字段时，Blob 文件完全不参与 I/O，避免资源浪费。
2. 多引擎统一抽象：无论使用 Spark、Flink、Java SDK 还是 Python 客户端，均可通过标准的 BYTES 或 BINARY 或 BLOB 类型定义 Blob 字段，接口一致，降低接入成本。
3. blob-as-descriptor 机制：针对超大非结构化数据（如十几GB的视频/日志文件），传统计算引擎（如Flink/Spark）无法将其全量加载到内存中处理。为此，系统引入了 blob-as-descriptor 机制——它是一种协议，通过记录数据在外部存储（如OSS）中的位置、文件路径、起始偏移和长度等元信息，将实际数据读取任务交给下游系统按需流式加载。这样避免了内存溢出，实现了大文件高效入湖。

四、生产验证与未来演进

当前，Paimon Blob 已在淘宝、天猫等核心业务中实现大规模落地，每天有近 10PB 的多模态数据（如视频、音频、图像）通过 Blob Descriptor 协议高效写入 Paimon 湖，避免了 Flink 或 Spark 将大文件全量加载到内存的问题。然而，在实际使用中仍面临三大关键挑战：

• 数据重复与删除问题，用户常因多次上传相同内容导致大量冗余（预估约 1PB/天的重复数据），亟需高效的去重与删除机制；
• 小文件碎片化问题，频繁的小规模写入产生海量微小 Blob 文件，严重影响读取性能和存储效率；
• 点查召回延迟高，缺乏对主键（如 UID）或向量特征的快速索引支持，难以满足毫秒级实时查询需求。

针对上述问题，团队已规划清晰的演进路径。

• 点查性能优化方面，推进热 ID 下推能力，并构建统一的全局索引框架，同时支持标量索引（如字符串、数值）和向量索引（用于 AI 召回），其中基础版标量索引预计本月在开源 Master 分支可用。

• 多模态数据管理方面，启动两项核心功能：

  • 一是基于 Deletion Vector + 占位符 的逻辑删除方案，在 Compaction 阶段安全清理重复或无效数据；
  • 二是开发 Blob Compaction 机制，自动合并小文件以提升读性能和存储密度。

此外，团队还前瞻性地提出跨表 Blob 复用的构想——多个表引用同一视频时仅存储一份物理数据，虽因涉及多表状态同步与一致性保障而技术难度较高，但已列入长期优化方向。整体目标是打造一个高效、紧凑、可快速检索的多模态数据湖底座，支撑未来 AIGC 与智能推荐等场景的规模化应用。

结语

Paimon 的技术演进，从结构化场景的列分离，到多模态数据的 Blob 抽象，每一项创新都源于真实业务痛点，并反哺于工程效率的提升。它不再只是“存储数据的地方”，而是成为 AI 原生时代的数据操作系统——高效、灵活、智能。

Paimon 将长期、持续且大力投入全模态数据湖建设，全面支持图像、音视频等非结构化数据的高效入湖、去重、合并与毫秒级点查。通过 Deletion Vector、Compaction 优化和全局索引等能力，Paimon 正构建面向 AI 时代的统一数据底座。作为开放湖表格式。

阿里云DLF 在云上提供全托管的Paimon存储服务，支持Paimon的智能存储优化与冷热分层。同时，DLF提供安全、开放、支持全模态数据的一体化Lakehouse管理平台，深度融入兼容其他例如 Iceberg、Lance 等主流格式，无缝对接 Flink、Spark 等计算引擎，，为 AIGC 与多模态智能应用提供高性能、低成本、易治理的数据基础设施。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

在数据驱动的 AI 时代，基础设施的价值，最终要体现在对业务效率的实质性推动上。 Paimon 的实践，正为整个行业提供一条通往高效、统一、智能数据湖的新路径。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

EMR Serverless StarRocks：2025年9月登顶全球TPC-H 10TB 性能和性价比榜单，性能比传统 OLAP 引擎提升 3-5 倍，100%兼容开源StarRocks，欢迎免费测试 >> https://free.aliyun.com/?searchKey=StarRocks

前往阿里云EMR官网开通 Serverless StarRocks试用并分享体验反馈，晒图可以领取精美礼品：https://x.sm.cn/EDWpX6I

更多内容

活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！

了解试用详情：https://free.aliyun.com/?productCode=sc

在近期的 Streaming Lakehouse Meetup · Online EP.2｜Paimon × StarRocks 共话实时湖仓 直播中，Apache Paimon PMC 成员/阿里云数据湖资深工程师叶俊豪带来了关于 Paimon 多模态数据湖的深度技术分享。

随着大模型训练对数据规模与多样性的要求不断提升，传统以批处理为中心的数据湖架构已难以满足 AI 工作负载对实时性、灵活性和成本效率的综合需求。特别是在推荐系统、AIGC 等典型场景中，工程师既要高频迭代结构化特征，又要高效管理图像、音频、视频等非结构化数据。面对这一挑战，Paimon 作为新一代流式数据湖存储引擎，正通过一系列底层创新，构建面向 AI 原生时代的统一数据基础设施。

一、结构化场景下的“列变更”困境

在推荐、广告等 AI 应用中，特征工程是一个持续演进的过程。例如，电商团队可能今天新增“用户近7日点击品类分布”，明天又加入“跨端行为一致性评分”。这种动态列变更导致“列爆炸”问题：表结构频繁扩展，而历史数据需与新特征对齐。

然而，已知的解决方案在此场景下仍然存在一些问题：

• 主键表 partial-update：虽支持按主键更新部分列，但其基于 LSM 树的实现会在写入频繁时产生大量小文件，查询性能急剧下降；Compaction 虽可合并文件，却带来数倍的临时存储开销。
• odps 存新特征值 + Join 拼接方案：将新特征写入独立表，查询时通过主键 Join 合并。看似避免了重写，但 Join 操作本身在 PB 级数据上开销巨大，且难以优化。
• Append 表 + MERGE INTO：SQL 语法简洁，但底层仍需重写整个数据文件。对于每天增量达 PB 级的训练集，全量重写不仅成本高昂，还显著拖慢特征上线周期。

这些方案本质上都未能解耦“列”的物理存储，导致灵活性与效率不可兼得。

二、Paimon 的列分离架构：以全局 Row ID 为核心

Paimon 提出了 列分离存储架构，其核心是引入 全局唯一且连续的 Row ID。每行数据在首次写入时被分配一个在整个表生命周期内不变的 ID，且每个数据文件内的 Row ID 是连续的，元数据会记录该文件的起始 Row ID。

这一设计带来两个关键能力：

1. 精准定位任意行：通过 Row ID 可直接定位到具体文件及偏移；
2. 跨文件自动关联：当查询涉及多个列时，系统能根据 Row ID 范围自动将分散在不同文件中的列数据在存储层合并。

例如，当新增“用户兴趣标签”列时，Paimon 仅需写入一个包含该列与对应 Row ID 的新文件，无需修改原始特征文件。查询时，引擎透明地将两组文件按 Row ID 对齐合并，无需 SQL 层 Join，也无需重写历史数据。这种机制将列变更的存储成本从 O(N) 降至 O(ΔN)，极大提升了特征迭代效率，同时节省了数十倍的存储空间。

三、迈向多模态：Blob 数据类型的三大突破

AI 训练不再局限于结构化特征。AIGC、多模态大模型等场景要求数据湖能高效处理图像、短视频、长音频等非结构化数据。这类数据具有两大特点：体积差异大（几 MB 到数十 GB）、访问稀疏（训练时通常只读取片段）。

传统列式格式（如 Parquet）将多模态数据与结构化字段混存，导致即使只查用户 ID，也需加载整个含视频的大文件，I/O 效率极低。

Paimon 引入 Blob 数据类型，实现三大突破：

1. 物理分离存储：Blob 列独立成文件，与结构化数据完全解耦。查询结构化字段时，Blob 文件完全不参与 I/O，避免资源浪费。
2. 多引擎统一抽象：无论使用 Spark、Flink、Java SDK 还是 Python 客户端，均可通过标准的 BYTES 或 BINARY 或 BLOB 类型定义 Blob 字段，接口一致，降低接入成本。
3. blob-as-descriptor 机制：针对超大非结构化数据（如十几GB的视频/日志文件），传统计算引擎（如Flink/Spark）无法将其全量加载到内存中处理。为此，系统引入了 blob-as-descriptor 机制——它是一种协议，通过记录数据在外部存储（如OSS）中的位置、文件路径、起始偏移和长度等元信息，将实际数据读取任务交给下游系统按需流式加载。这样避免了内存溢出，实现了大文件高效入湖。

四、生产验证与未来演进

当前，Paimon Blob 已在淘宝、天猫等核心业务中实现大规模落地，每天有近 10PB 的多模态数据（如视频、音频、图像）通过 Blob Descriptor 协议高效写入 Paimon 湖，避免了 Flink 或 Spark 将大文件全量加载到内存的问题。然而，在实际使用中仍面临三大关键挑战：

• 数据重复与删除问题，用户常因多次上传相同内容导致大量冗余（预估约 1PB/天的重复数据），亟需高效的去重与删除机制；
• 小文件碎片化问题，频繁的小规模写入产生海量微小 Blob 文件，严重影响读取性能和存储效率；
• 点查召回延迟高，缺乏对主键（如 UID）或向量特征的快速索引支持，难以满足毫秒级实时查询需求。

针对上述问题，团队已规划清晰的演进路径。

• 点查性能优化方面，推进热 ID 下推能力，并构建统一的全局索引框架，同时支持标量索引（如字符串、数值）和向量索引（用于 AI 召回），其中基础版标量索引预计本月在开源 Master 分支可用。

• 多模态数据管理方面，启动两项核心功能：

  • 一是基于 Deletion Vector + 占位符 的逻辑删除方案，在 Compaction 阶段安全清理重复或无效数据；
  • 二是开发 Blob Compaction 机制，自动合并小文件以提升读性能和存储密度。

此外，团队还前瞻性地提出跨表 Blob 复用的构想——多个表引用同一视频时仅存储一份物理数据，虽因涉及多表状态同步与一致性保障而技术难度较高，但已列入长期优化方向。整体目标是打造一个高效、紧凑、可快速检索的多模态数据湖底座，支撑未来 AIGC 与智能推荐等场景的规模化应用。

结语

Paimon 的技术演进，从结构化场景的列分离，到多模态数据的 Blob 抽象，每一项创新都源于真实业务痛点，并反哺于工程效率的提升。它不再只是“存储数据的地方”，而是成为 AI 原生时代的数据操作系统——高效、灵活、智能。

Paimon 将长期、持续且大力投入全模态数据湖建设，全面支持图像、音视频等非结构化数据的高效入湖、去重、合并与毫秒级点查。通过 Deletion Vector、Compaction 优化和全局索引等能力，Paimon 正构建面向 AI 时代的统一数据底座。作为开放湖表格式。

阿里云DLF 在云上提供全托管的Paimon存储服务，支持Paimon的智能存储优化与冷热分层。同时，DLF提供安全、开放、支持全模态数据的一体化Lakehouse管理平台，深度融入兼容其他例如 Iceberg、Lance 等主流格式，无缝对接 Flink、Spark 等计算引擎，，为 AIGC 与多模态智能应用提供高性能、低成本、易治理的数据基础设施。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

在数据驱动的 AI 时代，基础设施的价值，最终要体现在对业务效率的实质性推动上。 Paimon 的实践，正为整个行业提供一条通往高效、统一、智能数据湖的新路径。

阿里云DLF提供商业版Paimon服务，新用户免费试用100GB存储，1000CUH，点击领取https://free.aliyun.com/?productCode=dlf

EMR Serverless StarRocks：2025年9月登顶全球TPC-H 10TB 性能和性价比榜单，性能比传统 OLAP 引擎提升 3-5 倍，100%兼容开源StarRocks，欢迎免费测试 >> https://free.aliyun.com/?searchKey=StarRocks

前往阿里云EMR官网开通 Serverless StarRocks试用并分享体验反馈，晒图可以领取精美礼品：https://x.sm.cn/EDWpX6I

更多内容

活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink，体验新一代实时计算平台的强大能力！

了解试用详情：https://free.aliyun.com/?productCode=sc

Apache Gravitino 概要介绍

作者: shaofeng shi
最后更新: [2025-12-29]

背景

在大数据时代，企业往往需要管理来自多云多域、异构数据源的元数据，如 Apache Hive、MySQL、PostgreSQL、Iceberg、Lance、S3、GCS 等； 此外，随着 AI 模型训练和推理的大量应用，海量的多模态数据、模型元数据等也需要一种方案进行管理。传统的做法是为每个数据源单独管理元数据，这不仅增加了运维复杂度，还容易造成数据孤岛。Apache Gravitino 作为一个高性能、支持地理分布式的联邦元数据湖，为我们提供了统一管理多源元数据的解决方案。

Gravitino 最初是由 Datastrato 公司发起并创立，在2023年开源，2024年捐赠给 Apache 孵化器，在2025年5月从 Apache 孵化器毕业，成为 Apache Top Level Project。目前已经在小米、腾讯、知乎、Uber、Pinterest 等企业落地生产环境。

什么是 Apache Gravitino？

Apache Gravitino 是一个高性能、地理分布式、联邦化的元数据湖管理系统，为用户提供统一的数据和AI资产管理平台，它能够：

• 统一元数据管理：为不同类型的数据源提供统一的元数据模型和API
• 直接元数据管理：直接管理底层系统，变更会实时反映到源系统
• 多引擎支持：支持Trino、Spark、Flink等多种查询引擎
• 地理分布式部署：支持跨区域、跨云的部署架构
• AI资产管理：不仅管理数据资产，还支持AI/ML模型的元数据管理

核心概念包括：

• Metalake：元数据的容器/租户，通常一个组织对应一个metalake
• Catalog：来自特定元数据源的元数据集合
• Schema：第二级命名空间，对应数据库中的schema概念
• Table：最底层的对象，表示具体的数据表

Apache Gravitino 核心特性概述

统一元数据管理

Gravitino 提供了一个统一的元数据管理层，支持多种数据源的集成：

支持的数据源类型：

• 关系型数据库：MySQL、PostgreSQL、OceanBase、Apache Doris、StarRocks 等
• 大数据存储：Apache Hive、Apache Iceberg、Apache Hudi、Apache Paimon、Delta Lake（开发中）
• 消息队列：Apache Kafka
• 文件系统：HDFS、S3、GCS、Azure Blob Storage、阿里云 OSS
• AI/ML 数据格式：Lance（专为AI/ML工作负载设计的列式数据格式）

REST API 服务

Gravitino 提供了丰富的 REST API 服务，支持不同数据格式的标准化访问：

Gravitino 核心 REST API

• 完整的元数据管理 RESTful API 接口
• 支持 Metalake、Catalog、Schema、Table 等所有元数据对象的 CRUD 操作
• 支持用户、组、角色和权限管理的完整 API
• 提供标签、策略、模型等高级功能的 API 接口
• 支持多种认证方式（Simple、OAuth2、Kerberos）

Iceberg REST 服务

• 遵循 Apache Iceberg REST API 规范
• 支持多种后端存储（Hive、JDBC、自定义后端）
• 提供完整的表管理和查询能力
• 支持多种存储系统（S3、HDFS、GCS、Azure等）

Lance REST 服务

• 实现 Lance REST API 规范
• 专为 AI/ML 工作负载优化
• 支持高效的向量数据存储和检索
• 提供命名空间和表管理功能

元数据实时获取和修改

Gravitino 采用直接元数据管理模式，确保数据的实时性和一致性：

• 实时同步：对元数据的变更会立即反映到底层数据源
• 双向同步：支持从 Gravitino 到数据源，以及从数据源到 Gravitino 的元数据同步
• 事务支持：保证元数据操作的原子性和一致性
• 版本管理：支持元数据的版本控制和历史追踪

统一访问控制

Gravitino 实现了跨多数据源的统一权限管理：

核心特性：

• 基于角色的访问控制（RBAC）：支持用户、组、角色的灵活权限管理
• 所有权模型：每个元数据对象都有明确的所有者
• 权限继承：支持层次化的权限继承机制
• 细粒度控制：从 Metalake 到具体表的多层级权限控制

支持的权限类型：

• 用户和组管理权限
• 目录和模式创建权限
• 表、topic、fileset的读写权限
• 模型注册和版本管理权限
• 标签和策略应用权限

统一数据血缘

基于 OpenLineage 标准，Gravitino 提供了完整的数据血缘追踪能力：

• 自动血缘收集：通过 Spark 插件自动收集数据血缘信息
• 统一标识符：将不同数据源的标识符转换为 Gravitino 统一标识符
• 多数据源支持：支持 Hive、Iceberg、JDBC、文件系统等多种数据源的血缘追踪

高可用性和扩展性

部署模式：

• 单机部署：适合开发和测试环境
• 集群部署：支持高可用和负载均衡
• Kubernetes 部署：支持容器化部署和自动扩缩容
• Docker 支持：提供官方 Docker 镜像

存储后端：

• 支持多种元数据存储后端（MySQL、PostgreSQL等）
• 支持分布式存储系统

安全特性

认证方式：

• Simple 认证（用户名/密码）
• OAuth2 认证
• Kerberos 认证（针对 Hive 后端）

凭证管理：

• 支持云存储凭证代理（S3、GCS、Azure等）
• 动态凭证刷新
• 安全的凭证传递机制

Apache Gravitino 的集成能力

Gravitino 与主流计算引擎和数据处理框架深度集成，为用户提供统一的数据访问体验。

计算引擎集成

Apache Spark

• 通过 Gravitino Spark Connector 实现无缝集成
• 支持 Spark SQL 和 DataFrame API
• 自动数据血缘收集和追踪
• 支持多种数据源的统一访问

Trino

• 通过 Gravitino Trino Connector 服务集成
• 支持跨数据源的联邦查询
• 高性能的分析查询能力

Apache Flink

• 通过 Gravitino Flink Connector 服务集成
• 支持流批一体化数据处理
• 实时数据处理和分析

Python 生态集成

PyIceberg

• 支持 Python 环境下的 Iceberg 表访问
• 与 Gravitino Iceberg REST 服务集成
• 支持数据科学和机器学习工作流
• 提供 Pandas 兼容的数据接口

Daft

• 现代化的分布式数据处理框架
• 专为 AI/ML 工作负载优化
• 支持多模态数据处理
• 与 Gravitino 元数据管理集成

云原生集成

Kubernetes

• 支持 Kubernetes 原生部署
• 提供 Helm Charts 和 Operator
• 支持自动扩缩容和故障恢复
• 集成云原生监控和日志系统

API 和 SDK

REST API

• 完整的 RESTful API 接口
• 支持所有元数据管理操作
• 标准化的 HTTP 接口
• 支持多种认证方式

Java SDK

• 原生 Java 客户端库
• 类型安全的 API 接口
• 支持连接池和重试机制
• 完整的异常处理

Python SDK

• Python 客户端库
• 支持异步操作
• 与 Jupyter Notebook 集成
• 支持数据科学工作流

这些集成能力使得 Gravitino 能够无缝融入现有的数据基础设施，为用户提供统一、高效的数据管理体验。后续文章将详细介绍 Gravitino 的各项能力、各个集成组件的配置和使用方法，敬请关注。

下一步

• 敬请期待后续的一系列文章
• 关注和 star Apache Gravitino 代码库

Apache Gravitino正在快速发展中，本文基于最新版本编写。如遇到问题，建议查阅官方文档或在GitHub上提交issue。