标签 Apache Gravitino 下的文章

Apache Gravitino Introduction.png

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：最底层的对象，表示具体的数据表

Gravitino 整体架构

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 的各项能力、各个集成组件的配置和使用方法，敬请关注。

下一步

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

每次在 Apache SeaTunnel 里配置非关系型数据库，看着那几百行还要手动定义的字段映射，是不是挺崩溃的？配置错一个字段，任务就报错，这种“体力活”真的该结束了。

最近 Apache SeaTunnel 社区的 Issue #10339 提案捅破了这层窗户纸：既然有 Apache Gravitino 这么强大的元数据服务，为什么不直接让它自动同步 Schema？这个提议一出，社区反响热烈，核心维护者们已经把它列入了年度 RoadMap。目前的讨论很务实，大家正盯着怎么让 Apache SeaTunnel 在提交作业时自动‘抓取’最新的元数据，好让大家彻底告别那种‘对着数据库手敲配置’的原始生活。

🫱 Issue 链接： https://github.com/apache/seatunnel/issues/10339

Issue 概述

先来看看提交这个 Issue 的作者是为什么想到这个点子的，以及他初步的核心设计概念。🔽

本 PR 实现了 Apache Gravitino 与 SeaTunnel 的集成，将其作为非关系型连接器的外部元数据服务。通过 Gravitino 的 REST API 自动获取表结构和元数据，SeaTunnel 用户无需再在连接器配置中手动定义冗长且复杂的 Schema 映射。

背景

目前，Apache SeaTunnel 中的许多非关系型连接器（如 Elasticsearch、向量数据库和数据湖引擎）要求用户在作业配置中显式定义完整的列 Schema。这导致了以下问题：

  • 配置繁琐且易错：字段映射内容冗长，极易发生人为错误。
  • 架构冗余：不同作业之间存在大量重复的 Schema 定义。
  • 数据不一致风险：实际存储层与 SeaTunnel 配置文件之间容易出现架构脱节。

变更内容

本 PR 增加了基于 Gravitino 的 Catalog 和 Schema 解析器，使 SeaTunnel 能够：

  • 通过 REST API 从 Gravitino 查询表定义。
  • 自动获取列名、数据类型及相关属性。
  • 直接根据 Gravitino 元数据构建 SeaTunnel 内部 Schema。
  • 针对受支持的连接器，取消强制手动定义 schema { fields { ... } } 的要求。

实现后，用户只需在作业配置中指定 Gravitino Catalog 和相关的表引用即可。

核心优势

  • 零手动映射：非关系型数据源实现 Schema 自动对齐。
  • 单一事实来源：确保表结构与中心化元数据仓库保持高度一致。
  • 提升可靠性：显著提高配置的准确性，降低长期维护成本。
  • 支持复杂类型：通过统一元数据，简化了对嵌套结构、JSON、向量等高级类型的处理。

执行范围

所有基于 Gravitino 的 Schema 解析和校验均在 SeaTunnel Engine 客户端完成（即在作业提交前）。这种设计确保了：

  • 在作业预检阶段即可发现无效或不兼容的 Schema。
  • 运行时的任务仅接收经过验证和标准化的 Schema，降低了执行失败的概率。

影响

这一更新极大地简化了非关系型连接器的作业设置。除了提升易用性，它还为整个 SeaTunnel 生态系统在统一架构管理、架构演进以及高级数据类型支持方面奠定了技术框架。

核心思路

针对 FTP、S3、ES、MongoDB 等半结构化与非结构化数据源，SeaTunnel 现支持通过 Gravitino REST API 自动解析表结构（Schema）。

需要注意的是，这并非要取代现有的显式配置，而是一项完全向前兼容的可选新机制。

解析优先级如下：

1. 显式配置（Inline Schema）永远优先

只要连接器配置中包含了 schema 代码块，SeaTunnel 就必须忽略 Gravitino，直接以显式定义的 Schema 为准。

FtpFile {
  path = "/tmp/seatunnel/sink/text"
  # ... 其他基础配置 ...
  
  # 只要这里定义了，就不会去查 Gravitino
  schema = {
    name = string
    age  = int
  }
}

2. 通过 env 全局配置 Gravitino（推荐模式）

SeaTunnel 已在引擎层面集成了 Gravitino Metalake。
在 env 中全局开启后，所有非关系型数据源都能直接通过名称引用 Schema。

env {
  metalake_enabled = true
  metalake_type    = "gravitino"
  metalake_url     = "http://localhost:8090/api/metalakes/metalake_name/catalogs/"
}

2.1 使用 schema_path 引用

FtpFile {
  # ... 基础配置 ...
  schema_path = "catalog_name.ykw.test_table"
}

2.2 使用 schema_url 引用

FtpFile {
  # ... 基础配置 ...
  schema_url = "http://localhost:8090/api/metalakes/laowang_test/.../tables/all_type"
}

3. 兜底逻辑：读取操作系统环境变量

如果在作业的 env 块中没有定义 Gravitino，SeaTunnel 会尝试从操作系统环境变量中读取以下配置：
metalake_enabled | metalake_type | metalake_url
其行为逻辑与第 2 节中的 env 配置完全一致。

4. 在连接器层级单独配置 Gravitino

如果全局没有配置元数据中心，也可以在具体的连接器（Connector）内部直接定义 Gravitino。

4.1 直接使用 schema_url

FtpFile {
  # ... 基础配置 ...
  metalake_type = "gravitino"
  schema_url = "http://localhost:8090/api/.../tables/all_type"
}

4.2 组合使用 metalake_url 与 schema_path

FtpFile {
  # ... 基础配置 ...
  metalake_type = "gravitino"
  metalake_url  = "http://localhost:8090/api/metalakes/metalake_name/catalogs/"
  schema_path   = "catalog_name.ykw.test_table"
}

5. 探测器定位 (Find detector)

系统会根据 metalake_type 自动匹配并加载对应的 REST API HTTP 探测器。

6. 映射与构建 CatalogTable

探测器调用拼接好的 URL 获取响应体（ResponseBody），随后将其交给映射器（Mapper）进行类型匹配，最终完成 CatalogTable 的构建。

7. 流程图如下

Issue 进展

目前，Apache SeaTunnel 项目核心贡献者对此提议给出了正面评价，并将其添加到 Apache SeaTunnel Roadmap 中。

Apache SeaTunnel PMC Member 对这个提议提出一些疑问，比如这种集成属于哪一层级，对多引擎兼容性的考量，类型转换的准确性等，并根据社区设计规范，要求发起者提交一份正式的设计文档（Design Document）。提交者的回复非常具有建设性，他通过 “客户端预处理”和“抽象 Catalog 接口” 这两个核心设计点，有效地回应了社区对于系统耦合度和运行稳定性的担忧。

目前，这个讨论的回到了该 Issue 的提交者手中，社区正在等待他提交那份正式的 Design Document。

可以看到，这个方案要是落地，咱以后写任务可能就一两行配置的事儿。目前设计稿正在打磨中，非常需要大家去评论区吐吐槽、提提建议，毕竟这个功能好不好用，咱们一线开发者最清楚。走，去 GitHub 围观一下，说不定你的一个提议就能决定下一个版本的样子！🔽
https://github.com/apache/seatunnel/issues/10339

以下内容来源于DataforAI社区，作者Data for AI

当 AI 遇见数据：一场面向工程实践的技术交流

大模型并没有直接带来 AI 应用的成熟。真正决定 AI 能否规模化落地的，正在从模型本身，转移到数据、上下文与基础设施。

与此同时，数据基础设施也正经历一轮深刻演进：从传统的数据湖仓，到多模态数据管理；从 SQL 查询引擎，到面向 AI 的数据解析与治理能力。这些变化，正在重新定义我们构建 AI 应用的方式。

1 月 24 日（周六）下午 ，Data for AI 社区 将携手 ALC Beijing (Apache Local Community Beijing) 举办 Data for AI Meetup Beijing，邀请来自产业、开源社区与学术界的一线实践者，围绕 AI 时代的数据基础设施演进 展开深入交流。

本次 Meetup 汇聚了来自 字节跳动火山引擎 / Daft 社区、OceanBase社区、北京大学、Datastrato / Apache Gravitino 社区、Zilliz / Milvus 社区的技术专家，深度剖析 AI 时代数据基础设施的技术演进路径。

📍 本次 Meetup 核心看点

  • 多模态数据处理引擎实践：

    Daft 在 AI 数据预处理与训练加载中的工程经验

  • AI 原生元数据平台：

    Apache Gravitino 1.1.0 的关键能力与治理实践

  • Agent 数据基座设计：

    记忆、检索与数据统一的工程解法

  • Data-centric AI 方法论：

    面向大模型的数据准备与质量体系

  • 混合检索实践：

    向量 + 全文检索在真实业务中的优化路径

  • 开源探索：

    Skill 驱动的上下文工程平台化可能性

  • 圆桌讨论：

    下一代面向 AI 应用的数据基础设施如何设计与落地

多模态数据处理的新范式

AI 训练对数据处理提出了全新挑战。火山引擎 AI 数据湖服务架构师 琚克俭 将分享 Daft 在多模态数据处理上的工程实践，聚焦图像、视频、文本等异构数据在统一处理、预处理与训练加载阶段的性能与架构挑战。

这一分享直面当前 AI 工程的核心痛点：传统数据引擎已难以支撑多模态 AI 工作负载，而 Daft 通过全新的架构设计，在数据预处理和训练加载环节实现了显著的性能提升。

元数据治理进入 AI 原生时代

Datastrato VP of Engineering 史少锋 将深度解析 Apache Gravitino 1.1.0 的核心升级，包括 Lance REST 支持、Generic Lakehouse Catalog、Iceberg 安全增强等关键特性。

当 AI 团队需要在多个集群间管理训练数据、推理数据和模型元数据时，传统的元数据工具往往各自为政。Apache Gravitino 1.1.0 通过统一的元数据治理架构，让跨引擎、跨存储的数据协同变得标准化、可管理，大幅降低 AI 工程中的数据协同成本。

上下文工程：Agent 落地的数据基座

OceanBase 技术专家 汤庆 将深度解析当下最热的「上下文工程」话题。他指出，企业级 Agent 面临三大核心挑战：如何让 Agent 拥有可靠的「记忆」（记忆管理）、如何让 Agent「理解」复杂文档（知识检索），以及如何统一处理向量、文本、结构化数据（数据统一）。

这三款 AI 产品的协同设计给出了答案：PowerMem 基于艾宾浩斯遗忘曲线构建智能记忆系统并支持多智能体隔离，PowerRAG 提供多引擎 OCR 与向量 + 全文的混合检索能力，seekdb 则作为 AI 原生数据库统一管理多模态数据并兼容 MySQL 生态。这套方案的核心价值在于：用数据架构的确定性，对抗 Agent 行为的不确定性。

面向大模型时代的 Data-centric AI 基础设施

北京大学助理教授 张文涛 将从学术与工程结合的视角，系统阐述 AI 从「模型为中心」到「数据为中心」的范式转变。当大模型能力趋同，数据质量正在成为决定模型性能的关键变量。

张文涛团队主导开发的 DataFlow 数据准备系统已在大模型预训练、企业知识库构建等场景得到验证。本次分享将深入解析 LLM 数据工程的完整流程：如何获取数据（爬取、解析、合成、标注），如何处理数据（过滤、改写、配比），以及如何评估数据质量。这套开源工具链与方法论，正在为 AI 开发者降低数据工程的门槛。

从向量检索到混合查询：Context Engineering 实践

Zilliz 资深解决方案架构师 刘汉卿 将系统回顾从 Prompt Engineering 到 Context Engineering 的演进路径。随着 RAG 技术从单一向量检索发展到 GraphRAG 与全文检索的混合查询阶段，检索系统已经从「找到相似内容」进化到「理解查询意图并精准召回」。

在这个演进过程中，一个关键趋势是：用向量计算代替多轮LLM推理，通过检索层的优化来提升 AI 应用的性能与稳定性。刘汉卿将结合企业知识库、推荐系统、智能助理等场景，分享混合查询的工作流搭建经验，以及在金融、医疗、法律、教育等行业的实际落地案例。

上下文工程的平台化探索

独立开源开发者 袁怿（Sam Yuan）将从前瞻视角探讨 2026 年上下文工程的技术趋势。如果说 2025 是 Agent 元年，那么随着上下文工程的快速演进，一个关键问题正在浮现：上下文能力是否应该从「各自实现」走向「横向平台化」？

袁怿将上下文工程拆解为三个维度：工具调用（空间维度）、RAG（信息密度维度）与 Memory（时间维度）。他将以最近进入 AAIF 的 Skill 机制为切入点，对比 Skill 与传统 Function Call 的本质差异，并结合他在开源社区贡献的 StructuredContextLanguage 项目，展示以渐进式加载为代表的平台化思路——让 AgentOS 像操作系统管理进程一样，统一管理上下文资源。

圆桌论坛：下一代面向 AI 应用的 Data Infra 的设计和落地

从多模态数据处理到 AI 原生元数据平台，从上下文工程到混合检索系统——本次 Meetup 的所有分享指向同一个命题：在 Agent 时代，数据不再只是「被调用的资源」，而正在成为被理解、被约束、被治理的核心能力。

越来越多团队在实践中遇到相似挑战：Agent 需要访问的数据分散在不同系统中，权限、语义与上下文边界不清；模型可以生成「看似合理」的请求，却难以保证结果的安全性与一致性。这些问题往往无法通过 Prompt 或单点优化解决。

我们特邀到前 Apple 数据与机器学习平台负责人 谭涛（Kwaai AI Lab 顾问）、Datastrato 创始人 CEO 堵俊平、北京大学助理教授 张文涛 三位圆桌嘉宾，围绕三个核心问题展开讨论：

  • 意图与执行解耦：如何让 Agent 的数据请求既灵活又可控？
  • 访问规则原生化：能否在系统层面保证数据访问的安全性与一致性？
  • 上下文边界管理：如何让 Agent Builder 在不理解底层架构的前提下获取「该拿的数据」？

这些讨论并不立马给出最终答案，而是帮助我们勾勒下一代面向 AI 应用的数据基础设施轮廓——一个更开放、更可治理、也更适合 Agent 时代的技术底座。

活动信息

时间：

2026 年 1 月 24 日（周六）13:10 – 18:00

地点：

北京 · 原点学堂（东升大厦 A 座 10 层）（不提供线上直播）

立即报名：

👉 访问链接：https://www.huodongxing.com/event/3843480320400

⚠ 名额有限，需审核通过（请详实填写报名信息，并通过主理人的微信添加请求，确认审核状态）

这是一场面向 AI & Data 工程实践者的技术深度交流。

无论你是正在构建企业级 Agent 系统的架构师，

还是关注 Data-centric AI 的研发工程师，

都能在这里找到有价值的技术洞察和落地经验。

Community Over Code，期待与你在北京相聚。

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么


​