每天认识一个组件：元数据湖 Apache Gravitino

一、为什么需要 Gravitino

过去很多大数据平台以 Hive Metastore 为中心，Spark、Hive、Presto/Trino 等引擎围绕表、库、分区等结构化元数据工作。这个模式在单一数据湖或少数几个引擎中足够有效，但当平台同时接入 Hive、Iceberg、Hudi、Paimon、JDBC 数据库、Kafka、对象存储、机器学习模型时，元数据管理会迅速碎片化。

典型问题包括：

• 每个系统都有自己的 catalog、权限模型、命名空间和管理接口。
• Spark、Trino、Flink 等引擎各自对接不同元数据源，平台团队需要维护多套连接、权限和审计逻辑。
• 数据资产不再只是表，还包括文件集、消息主题、模型、函数、视图、策略、作业等。
• 多云、多地域架构下，元数据需要跨区域共享，但又不能简单复制一份"看起来统一、实际不同步"的副本。

Gravitino 给出的思路不是再做一个只负责"采集展示"的数据目录，而是通过连接器直接管理底层系统中的元数据。Gravitino 与传统需要主动或被动采集元数据的系统不同，它通过连接器连接不同元数据源，在 Gravitino 中的变更会直接反映到底层系统，反之亦然 。

二、Gravitino 是什么

Apache Gravitino 是一个 federated metadata lake，它直接管理分布在不同来源、类型和地域中的元数据，并为数据与 AI 资产提供统一访问能力。它是高性能、地理分布式、联邦式元数据湖，面向 data and AI assets 提供统一元数据访问。

关键词	含义	备注
Federated	不把所有元数据都搬到一个孤岛中，而是通过 connector 管理不同底层系统	减少重复同步和一致性问题
Metadata lake	用统一模型组织多类型元数据资产	让表、文件、Topic、模型等资产进入同一治理视图
Geo-distributed	支持跨区域、跨云的元数据访问与共享能力	适合多云、多地域数据平台

Gravitino 的目标包括：为多地域数据提供 SSOT，即 Single Source of Truth；统一管理 Data + AI 资产；集中化安全治理；内建数据管理与数据访问管理能力 。

理解 Gravitino 的第一步，是理解它的对象层级，主要元数据对象包括 Metalake、Catalog、Schema、Table、Fileset、Model、Topic 等。

Gravitino 对象层级

Metalake
└── Catalog
    └── Schema
        ├── Table
        ├── View
        ├── Topic
        ├── Fileset
        ├── Model
        └── Function

对象	解释
Metalake	元数据的顶层容器或租户，通常一个团队或组织可以拥有一个 metalake
Catalog	某类元数据源的集合，每个 catalog 通过对应 connector 连接底层系统
Schema	第二层命名空间，在关系型/湖仓系统中通常对应 database 或 schema
Table	关系型元数据源中的表对象
Fileset	文件系统中文件和目录集合的逻辑元数据对象
Topic	消息队列系统中的主题对象，例如 Kafka topic
Model	模型元数据对象
Function	用户自定义函数对象
View	逻辑视图对象，1.3.0 中视图管理是重点增强能力之一

如果类比传统 Hive Metastore，可以粗略理解为：

Hive Metastore:
Database -> Table -> Partition

Gravitino:
Metalake -> Catalog -> Schema -> Table / View / Fileset / Topic / Model / Function

这种模型的关键价值在于，它不再假设所有资产都是"表"。对于现代数据平台，PDF、日志目录、Kafka Topic、ML 模型、Iceberg 表、MySQL 表都可能是被治理和被访问的资产。

三、架构原理

Gravitino 架构分为 Functionality Layer、Interface Layer、Core Object Model、Connection Layer 四层。

这个架构里最重要的是"统一抽象"和"连接器下沉"。上层用户、平台服务和计算引擎面对的是统一 API 与统一对象模型；下层 Gravitino 通过不同 connector 适配 Hive、MySQL、PostgreSQL、Iceberg、Paimon、Kafka、Fileset、Model 等元数据源 。

Gravitino 的直接管理方式也影响了平台设计。很多传统数据目录系统更偏"索引与展示"，需要扫描、同步或采集元数据；Gravitino 更像一个带治理能力的"元数据控制面"，通过 catalog connector 把管理动作传递到底层系统。这意味着它适合放在数据平台的元数据访问路径上，而不仅是旁路的资产搜索系统。

四、功能特性

4.1.统一元数据管理

Gravitino 抽象了不同类型元数据的统一模型和 API，它可以用关系型元数据模型管理 Hive、MySQL、PostgreSQL 等表数据，也可以用文件元数据模型管理 HDFS、S3 等非结构化数据 。

Gravitino 支持的 catalog 类型包括 Hive、Iceberg、Hudi、Paimon、MySQL、PostgreSQL、Doris、StarRocks、Fileset、Kafka、Model 等；部分 contributed catalog 如 OceanBase、ClickHouse 自 1.2.0 起不在标准发行包和 Docker 镜像内，需要自行构建包含 catalogs-contrib 的包 。

统一管理的资产类型示意

+-------------+-----------------------------+
| 类型        | 示例                         |
+-------------+-----------------------------+
| 表资产      | Hive / Iceberg / Hudi / JDBC |
| 文件资产    | HDFS / S3 Fileset            |
| 消息资产    | Kafka Topic                  |
| 模型资产    | Model Metadata               |
| 函数资产    | UDF / Function               |
| 视图资产    | Hive / Iceberg / Paimon View |
+-------------+-----------------------------+

4.2.多引擎支持

Gravitino 支持不同查询引擎访问元数据，它支持 Trino，并已扩展到 Apache Spark、Apache Flink、Daft 等引擎，后续也会继续增强多引擎支持 。

多引擎共存是现实：Spark 负责 ETL，Flink 负责实时，Trino 负责交互式分析，Python/Daft 负责数据科学。如果每个引擎各接一套 catalog，平台治理会变成 N 套元数据接入与权限配置；Gravitino 的价值是把这些引擎尽量拉到统一元数据面之上。

4.3.统一访问控制

Gravitino 提供跨多个数据源的统一访问控制，让用户通过单一接口管理数据库、消息队列、对象存储等系统中的权限。它采用 RBAC 与 DAC 两类互补模型：RBAC 将权限分配给角色，再将角色分配给用户或用户组；DAC 则让每个元数据对象拥有 owner，由 owner 管理对象访问。

Gravitino 权限模型简图

User / Group
     |
     v
   Role
     |
     v
Privilege
     |
     v
Securable Object
(Metalake / Catalog / Schema / Table / Topic / Fileset / Model ...)

Gravitino 只在其支持将权限传递到底层授权插件的 securable object 上支持授权，它的权限粒度覆盖 catalog、schema、table、view、topic、fileset、model、function、tag、policy、job template 等对象。例如，表权限包括 CREATE_TABLE、MODIFY_TABLE、SELECT_TABLE；文件集权限包括 CREATE_FILESET、WRITE_FILESET、READ_FILESET；Topic 权限包括 CREATE_TOPIC、PRODUCE_TOPIC、CONSUME_TOPIC 。

4.4.标签与治理

Gravitino 引入 tag system，用于对元数据对象分类和组织；可打标签的对象包括CATALOG、SCHEMA、TABLE、FILESET、TOPIC、MODEL、COLUMN等。tag 具有继承性：列出某个对象的 tag 时，也会列出其父对象的 tag；多层 schema 的中间父 schema 也参与继承。

Tag 继承示意

Catalog: lakehouse       [pii-domain]
└── Schema: ods          [raw-data]
    └── Table: users     [sensitive]
        └── Column: id_card

查询 Table users 的标签时，可能看到：
- pii-domain  来自 Catalog
- raw-data    来自 Schema
- sensitive   来自 Table

这类能力适合支撑数据分级分类、成本域划分、业务域治理、敏感数据标记等场景，不过当前 tag system 是基础实现，部分高级能力会在未来版本继续加入。

4.5.Iceberg REST Catalog

Gravitino 提供 Iceberg REST Catalog Service，它实现了 Apache Iceberg REST API 规范，访问端点形如http://$ip:$port/iceberg/。

Gravitino Iceberg REST server 与 Gravitino server：前者接口遵循 Iceberg REST API spec，只管理 Iceberg table；后者提供 Gravitino unified interfaces，可管理 JDBC、Hive、Iceberg、Hudi、Paimon 等类型。

Gravitino Server vs Iceberg REST Server

+-----------------------------+------------------------------+
| Gravitino Server            | Iceberg REST Server           |
+-----------------------------+------------------------------+
| Gravitino Unified API       | Iceberg REST API Spec         |
| 管理多类 catalog/table       | 仅面向 Iceberg 表             |
| 统一对象模型与治理能力       | 面向 Iceberg 客户端兼容       |
+-----------------------------+------------------------------+

五、适用场景

• 多引擎湖仓平台：如果一个团队同时使用 Spark、Trino、Flink 访问同一批或多批湖仓数据，Gravitino 可以作为统一 catalog 管理入口。
• 多数据源统一治理：当企业数据分布在 Hive、Iceberg、MySQL、PostgreSQL、Kafka、对象存储等系统中时，Gravitino 的 unified metadata management 能把多源元数据纳入同一模型和 API。
• 多云与跨地域：Gravitino 的 geo-distribution 支持重点体现在 Iceberg REST Catalog 场景：不同 Gravitino 实例可运行在不同区域或云中，本地 IRC catalog 可以代理请求到远端 IRC catalog，让用户获得跨区域或跨云的元数据全局视图。
• AI 与 RAG 数据资产管理：Gravitino 的目标包含统一 data and AI assets，不只是传统大数据 catalog，也在向 AI 应用的数据上下文层靠近。

六、部署与使用

二进制典型部署步骤：

# 1. 下载并解压 gravitino-<version>-bin.tar.gz

# 2. 配置服务
vim conf/gravitino.conf
vim conf/gravitino-env.sh
vim conf/log4j2.properties

# 3. 如需配置 catalog
vim catalogs/hive/conf/hive.conf

# 4. 启动服务
./bin/gravitino.sh start

# 5. 验证
curl -v -X GET \
  -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  http://localhost:8090/api/version

七、优势与局限

优势：

• 统一对象模型：用 Metalake、Catalog、Schema 等模型组织多源元数据。
• 联邦式管理：通过 connector 直接管理底层系统，降低采集型目录的一致性问题。
• 多引擎接入：支持 Trino、Spark、Flink、Daft 等引擎接入路径。
• 治理扩展：提供访问控制、标签、审计、策略、作业、Iceberg REST 等能力。

局限：

• connector 差异：不同 catalog 的能力覆盖、权限下推和兼容性并不完全一致。
• 版本演进快：新版本新功能迭代较多，生产升级需要仔细看 release notes。
• 运维复杂度：多源、多引擎、多云场景下，Gravitino 本身会成为关键控制面。

如果你的平台只有一个 Hive Metastore 和少量 Spark 作业，Gravitino 的收益可能不明显；但如果你已经进入多引擎、多 catalog、多云、多资产类型的阶段，它提供的统一元数据层会明显降低平台治理复杂度。