[元数据湖/Metalake] Apache Gravitino：高性能、跨地域、联邦化的开源数据目录与元数据湖

0 序

由 Datastrato 发起、已毕业为 Apache 顶级项目的【开源元数据湖】（Metadata Lake），通过一套统一模型与 API 直接管理分散在异构数据源、跨区域/云上的数据与 AI 资产元数据，并提供【一站式数据治理】。

https://datastrato.ai

关系型模型的相关核心概念/模块(postgresql为例)： metalake - catalog(database级) - schema - table - TableProperty/TableIndex/Column

1 概述

产品介绍

产品定位：Apache Gravitino 是一个高性能、跨地域（geo-distributed）、联邦化（federated）的【元数据湖】。它把来自不同数据源（文件系统、关系型数据库、事件流、数据湖表格式、机器学习模型等）的元数据直接管理起来，为用户和计算引擎提供统一的元数据访问，实现多源、多区域、多云的数据资产统一纳管。
诞生的背景与原因：
- 现代数据栈呈现"多源、多云、多引擎"碎片化局面——Hive、Iceberg、Paimon、Hudi 等表格式，MySQL、PostgreSQL、Doris 等数据库，Kafka 等消息系统，以及 HDFS/S3 等文件系统各自维护独立元数据，缺乏统一视图与统一治理。
- 传统元数据系统通常需要"主动或被动采集"底层元数据，存在一致性滞后。
- Gravitino 提出第三条路径：直接在数据所在处治理（Govern at the Source）——用连接器（Connector）直接读写底层系统的元数据，两边实时双向同步，不拷贝数据、不夺走数据所有权。
核心解决的问题：
- 多源元数据缺乏统一模型与统一访问 API；
- 跨地域/多云架构下元数据无法互通，缺少全局视图；
- 数据治理（权限、审计、发现）散落在各系统中，无法集中统一；
- 多引擎（Trino/Spark/Flink 等）接入每种元数据时需改造 SQL 方言、重复集成。
URLs：
- 官网：https://gravitino.apache.org
- 文档：https://gravitino.apache.org/docs/latest
- GitHub：https://github.com/apache/gravitino
- 邮件列表：dev@gravitino.apache.org

发展历程

时间	里程碑
2023-04	由 Datastrato（创始人 Jerry Shao 等，前 LinkedIn / 大数据领域资深专家）发起并开源，定位开源元数据湖
2024 Q1	发布 0.4.0（分区、UI 改进、Kerberos、查询优化）、0.5.0（非表数据目录、消息数据目录、Spark 引擎集成）；落地用户/权限框架
2024-04	进入 Apache 软件基金会（ASF）孵化（incubating）
2024 Q2–Q3	0.6.0（原生存储/HMS 兼容、Apache Ranger 权限集成）、0.6.1；发布 Flink 连接器，支持元数据打标签；社区集成 MySQL、Python API、Doris、Kafka、Paimon 等
2024 Q4	0.7.0：强化云支持，引入 FUSE/CSI、云存储安全凭证分发、审计框架
2025 Q1	0.8.0：引入 Model Catalog（AI/ML 元数据）、Fileset FUSE、安全凭证分发；新增 Flink–Iceberg、Flink–Paimon、Spark–Paimon 连接器
2025 Q2	0.9.0；2025-06-03 从孵化器毕业，正式成为 Apache 顶级项目（TLP）
2025 Q3	0.9.1；发布 1.0.0（首个稳定大版本）；引入元数据驱动 Action 系统、统一跨目录/引擎访问控制、增强模型元数据
2025 Q4	1.0.1（稳定性改进）、部署镜像切换 Eclipse Temurin
2026 初	1.1.0（含 Lance REST 服务，支持向量数据集）、1.1.1（补丁）
2026-03	1.2.0：从"被动元数据目录"升级为"湖仓操作平台"（表维护服务 Table Maintenance Service、UDF 管理、服务端扫描规划、Delta Lake 外部表治理、Trino 连接器多数据源）
2026-06	1.3.0："Govern at the Source"——单目录多云（Iceberg REST 目录同时服务 S3/GCS/ADLS）、AWS Glue 目录与引擎连接器、统一视图管理、多节点缓存一致性

注：以上为官网博客/路线图公开信息整理，具体版本以 Apache 官方发布页为准。

主要功能

统一元数据管理：用统一元数据模型与 API 抽象不同元数据源——关系型元数据模型（Hive、MySQL、PostgreSQL、Doris、OceanBase 等表数据）、文件元数据模型（HDFS、S3 等非结构化数据）、消息/流元数据模型（Kafka Topic）、模型元数据模型（AI/ML）。
端到端数据治理：统一治理层，覆盖访问控制、审计、元数据发现、打标签、统计信息、视图管理等，一次配置即可对所有数据资产生效。
直接元数据管理（Direct Metadata Management）：连接器直连底层系统，Gravitino 中的变更实时反映到底层系统，底层变更也实时反映回来（双向同步），而非被动采集。
跨地域/多云支持：不同地域或云上可部署多个 Gravitino 实例，通过本地 Iceberg REST 目录代理远程目录请求，实现跨地域/云的全局元数据视图。
多引擎兼容：在不改动现有 SQL 方言的前提下，接入 Trino、Spark、Flink、Daft 等查询引擎；提供 Java 客户端与 Python 客户端。
AI 资产管理（WIP）：支持模型（Model）、特征（Feature）等 AI 资产元数据管理，朝向"数据 + AI 资产"统一治理演进；提供 MCP Server 让 AI Agent 接入数据上下文，支持 Lance REST 服务纳管向量数据集。

当前支持的目录（Catalog）类型：

关系型：Hive、Iceberg、Paimon、Hudi、MySQL、PostgreSQL、Doris、OceanBase、StarRocks、ClickHouse、Hologres；
Fileset 文件集：Hadoop（HDFS）、S3、GCS、阿里云 OSS、Azure ADLS、腾讯云 COS；
消息型：Kafka；
模型型：Model Catalog；
其他：AWS Glue Catalog、Lakehouse 通用目录（Delta Lake、Lance）等。

核心优势

SSOT（单一事实源）：为多区域数据提供统一、可信的元数据入口，配合跨地域架构支持。
"直接管理"而非"被动采集"：与底层系统实时双向同步，避免传统采集式目录的一致性与滞后问题。
多源、多云、多格式联邦：一个模型/API 同时纳管数据库、文件、消息流、AI 模型，跨区域/云提供全局视图。
多引擎无缝接入：无需改造 SQL 方言即可让 Trino/Spark/Flink 等接入，降低集成成本。
集中式安全与治理：访问控制、审计、发现"一处集中"，降低多系统分别治理的复杂度。
开源中立 + 生态背书：Apache 2.0 协议、ASF 顶级项目，已毕业 TLP，避免被单一厂商锁定。
向操作平台演进：从目录扩展出表维护、UDF 治理、服务端扫描规划、元数据驱动 Action，具备更强的"可执行"能力。
AI 原生方向：Model Catalog + MCP Server + Lance 向量目录，率先打通 AI 资产治理。

主要短板

AI 资产管理仍为 WIP：模型/特征等功能标注"开发中"，尚未完全成熟。
治理能力仍在演进：访问控制、审计、Action 等框架相对较新，生产环境大规模实践仍需验证。
引擎覆盖仍以 Trino 为最成熟：Spark/Flink/Daft 等处于持续完善中，部分功能成熟度不一。
依赖独立服务部署：需单独部署 Gravitino Server，相对内嵌式 Hive Metastore 增加了运维组件。
Windows 构建不支持：从源码构建官方声明不支持 Windows（需 Linux/macOS）。
生态/案例相对年轻：相比 Databricks Unity Catalog、Hive Metastore 等，企业级案例沉淀时间较短。

局限性

构建环境限制：Gradle 构建不支持 Windows；部署镜像以 Linux 为主。
非"数据存储"本身：Gravitino 是元数据/目录层，不负责数据存储与计算，需配合底层系统使用。
与厂商目录互操作范围有限：虽然可注册 AWS Glue、Polaris、远程 Gravitino 等目录，但对部分专有目录的深度功能支持仍在补齐。
特定能力仍在路线图上：如更全面的 Thrift/JDBC 接口（当前以 REST 为主）、更多引擎、更完整的 AI 资产能力。

适用场景

湖仓联邦元数据发现：统一发现数据湖与数仓中分散的表/文件元数据；
混合云/多云多区域元数据同步：跨地域、跨云架构下的全局元数据视图；
数据与 AI 资产统一治理：统一审计、访问控制、发现、打标签；
多引擎即插即用接入：Trino/Spark/Flink 等无需改 SQL 即可访问统一目录；
开放目录替代专有方案：用开放架构治理 Iceberg/Hudi/Paimon/Delta，减少对 Unity Catalog 等专有目录的依赖；
AI/ML 模型与向量数据治理：管理模型元数据、通过 Lance 管理向量数据集、通过 MCP 连接 AI Agent。

竞品	类型	与 Gravitino 的对比
Databricks Unity Catalog	专有企业级目录/治理	功能成熟、生态强，但闭源、与 Databricks 平台绑定；Gravitino 以开放中立姿态对标，支持统一治理 Delta 等格式、减少对其依赖
Apache Polaris（Snowflake 开源目录）	开源目录（基于 Iceberg REST）	同为开放目录，聚焦 Iceberg；Gravitino 覆盖面更广（多格式、文件、消息、模型）
Hive Metastore（HMS）	传统表元数据服务	广泛部署但仅限 Hive 生态、无跨源治理；Gravitino 可联邦注册/治理 HMS
AWS Glue Data Catalog	云厂商托管目录	云绑定；Gravitino 1.3 已支持注册并治理 Glue 元数据
Apache Amoro（原 Arctic）	湖仓数据管理层/目录	侧重 Iceberg 等表格式的自管理；Gravitino 更偏联邦元数据湖
OpenMetadata / DataHub / Amundsen	元数据发现/数据目录平台	侧重采集型元数据发现与血缘；Gravitino 侧重"直接管理 + 治理 + 多引擎接入"

发展趋势

从目录到操作平台：1.2 起引入表维护服务、UDF 治理、服务端扫描规划，变被动目录为可执行的湖仓操作层。
"Govern at the Source"：1.3 主打单目录多云（Iceberg REST 同时服务 S3/GCS/ADLS）、注册外部目录（Glue/Polaris/HMS）而不拷贝元数据，数据主权留给属主。
AI 原生目录：Model Catalog、Lance 向量目录、MCP Server 三线并进，把数据治理与 AI 资产治理打通。
社区高速增长：详见下方活跃趋势。

开源社区活跃趋势

Star 趋势：2025 年全年 Star 增长超 130%，年末突破 2,600；到 2026 年中约 3,058–3,230。
Fork 趋势：2025 年 Fork 增长约 150%，至 2026 年中约 887–939。
Contributor/Commits：贡献者约 340 人；仓库累计 4,500+ commits；1.1.0 等大版本由 40+ 位来自不同组织的开发者共同贡献，活跃开发者社区近一年增长近 100%。
项目从孵化到 TLP 仅约 14 个月（2024-04 入孵 → 2025-06 毕业），发布节奏紧凑（0.4 → 1.3）。

总结：Gravitino 正从"开源联邦元数据湖/目录"快速演进为"开放、AI 原生、具备可操作治理能力的湖仓治理平台"，社区活跃度与生态规模持续快速增长。

2 工作原理与架构

概念术语

术语	说明
Metalake（元数据湖）	元数据的顶层容器 / 租户。通常一个组织/团队一个 Metalake，内部通过三级命名空间 `catalog.schema.table` 组织数据；用户与角色也挂在 Metalake 下
Catalog（目录）	来自某个特定元数据源的元数据集合，每个目录配一个对应连接器
Schema（模式）	二级命名空间，用于分组元数据；对应关系型数据库的 database/schema，也可作为 fileset、model 的逻辑命名空间
Table（表）	关系型元数据源中对象层级的最底层，在具体 Schema 下创建
Fileset（文件集）	文件系统中一组文件/目录的逻辑元数据对象，用于管理非结构化文件
Model（模型）	支持模型管理的目录中的 AI/ML 模型元数据对象
Topic（主题）	消息队列系统（如 Kafka）中管理主题的元数据对象
Connector（连接器）	连接并直管某个具体元数据源（Hive/MySQL/S3 等）的适配组件
Iceberg REST Catalog	Gravitino 原生提供的、兼容 Iceberg 规范的 REST 目录服务，可跨地域代理联邦

核心概念: Job/作业、Job Template/作业模板

Job 是 Gravitino "代你执行的具体任务"——它是 Gravitino 从"被动元数据目录"升级为"可操作治理平台"的核心机制，让【元数据】不仅能看、能管，还能触发执行。

核心概念：模板（Template）与作业（Job）

Job Template（作业模板）：一个可复用的定义——指定"跑什么命令/应用、带哪些参数"。注册一次、反复使用。
Job（作业）：模板的一次实际运行，有独立状态（排队中/运行中/成功/失败/取消中/已取消）。

官方定义："A job is a piece of work Gravitino runs on your behalf"——即 Gravitino 替你运行的、基于它已管理的元数据的任务。

这些"作业/Job"是干嘛的

截图正打开的是 builtin-iceberg-rewrite-data-files 模板，属于内置的 Iceberg 表优化作业：

模板（截图下拉列表里可见）	作用
`builtin-iceberg-rewrite-data-files`	重写 Iceberg 数据文件（即表压缩/合并小文件），提升查询性能，属于表维护（Table Maintenance）
`builtin-iceberg-update-stats`	更新 Iceberg 表统计信息，供优化器生成更好的执行计划
`builtin-sparkpi`	一个 Spark 示例作业（跑 Pi 计算），用于验证作业链路是否打通

注意弹窗里这些关键字段，正好解释了 Job 的"驱动方式"：

Job Type: spark → 这是一个 Spark 类型的作业（通过 spark-submit 提交）；

Executable: /opt/gravitino/auxlib/gravitino-jobs-1.3.0.jar → Gravitino 内置的作业 Jar；

Class Name: org.apache.gravitino.maintenance.jobs.iceberg.IcebergRewriteDataFilesJob → 执行类是 "表维护"包下的 Iceberg 重写数据文件作业；

Template Parameters / Job /Configuration：catalog_name、table_identifier（对哪张表操作）、strategy、sort_order、where_clause、options、spark_conf → 每次运行时由你填值，一个模板服务多种场景。

Job 系统能做什么（定位）

表维护：如 Iceberg 压缩、更新统计，是当前最主要用途；
元数据驱动的治理动作（metadata-driven action）：路线图里的方向——按【元数据定义策略】（如 TTL、压缩）并执行；
通用执行：任何"应该针对 Gravitino 已知元数据运行"的任务都能用同一套机制（可通过自定义 Job Executor 扩展，不只是 Spark）。

两种模板类型

SHELL 模板：运行一条 shell 命令/可执行文件；
SPARK 模板：提交一个 Spark 应用（需配置 SPARK_HOME 或 gravitino.jobExecutor.local.sparkHome）。

工作流（对应截图的按钮）

Register Job Template：注册模板（定义命令 + 参数占位符 {{xxx}}）；
Run Job：运行模板，填参数值 → 生成一个 Job；
Watch：查看状态（QUEUED → STARTED → SUCCEEDED/FAILED/CANCELLED），可拉取 stdout/stderr 输出。

权限（截图页面按权限展示可见作业）

REGISTER_JOB_TEMPLATE：注册模板；
USE_JOB_TEMPLATE：读取/使用模板；
RUN_JOB：运行作业。
模板的修改/删除仅限 metalake 属主和模板属主。

要注意的现状（官方明确标注）

Job 系统仍在【开发中】。

默认 executor 是 local：在 Gravitino 服务器本地进程里跑，仅用于测试/开发；生产要自己实现 Job Executor；
当前只支持单作业运行，不支持作业调度（不做定时排程）；
不打算替代现有调度器（如 Airflow/Spark 调度），定位是"基于元数据的治理/维护动作"的落地通道。

总结

Gravitino 的 Job = 让元数据"动起来"的执行机制。 它把"对某个表做维护/优化（如 Iceberg 重写文件、更新统计）"这类动作做成【可复用模板】，你在 UI 里选模板、填参数、点 Run Job 就能触发执行——你截图里的 builtin-iceberg-rewrite-data-files 正是做表压缩优化的内置模板。它是 Gravitino 从"元数据目录"走向"操作平台"的关键一环，但目前仍是测试级、单作业、无调度的早期能力。

架构与运行原理

Gravitino 采用分层架构，官方将其划分为四个层次：

┌─────────────────────────────────────────────────────────────┐
│  功能层 Functionality Layer                                  │
│  元数据创建/更新/删除 + 统一治理（访问控制、发现、审计…）         │
├─────────────────────────────────────────────────────────────┤
│  接口层 Interface Layer                                      │
│  标准 REST API（未来支持 Thrift、JDBC）；Java / Python 客户端   │
├─────────────────────────────────────────────────────────────┤
│  核心对象模型 Core Object Model                               │
│  通用元数据模型：Metalake → Catalog → Schema → Table/         │
│  Fileset/Model/Topic                                          │
├─────────────────────────────────────────────────────────────┤
│  连接层 Connection Layer                                      │
│  连接器集：Hive、Iceberg、Paimon、MySQL、PostgreSQL、          │
│  Kafka、HDFS/S3/GCS/OSS/ADLS/COS、Model、AWS Glue、Delta、    │
│  Lance …                                                      │
└─────────────────────────────────────────────────────────────┘

运行原理关键点：

统一对象模型：所有异构元数据被抽象为 Metalake → Catalog → Schema → (Table | Fileset | Model | Topic) 的统一模型，屏蔽底层差异。
REST 接口 + 连接器：客户端通过标准 REST API 操作；连接层连接器将统一操作翻译并直连到底层系统。
直接双向管理：连接器直接读写底层系统元数据，Gravitino 的变更实时同步到底层，底层变更也反向同步——区别于传统"主动/被动采集"模式。
跨地域联邦：不同地域/云部署多个实例，本地实例通过 Iceberg REST（IRC）目录代理远程目录请求，用户获得跨地域/云的全局视图。
多引擎接入：Trino/Spark/Flink/Daft 通过各自连接器，无需修改 SQL 方言即可访问统一目录；Iceberg 客户端可直接用 Gravitino 提供的 REST 目录。
服务端可执行能力：1.2+ 提供表维护服务（分区级健康/压缩）、UDF 治理、服务端扫描规划，1.3+ 提供元数据驱动的 Action/作业调度与统一视图管理。
安全集中：统一认证（OAuth/Kerberos 等）与授权（含 Apache Ranger 权限集成）在目录层集中实施。

元数据访问对象层级（三级命名空间）

graph TD M[Metalake 元数据湖/租户] --> C1[Catalog: Hive] M --> C2[Catalog: Iceberg] M --> C3[Catalog: Fileset-Hadoop] M --> C4[Catalog: Kafka] C1 --> S1[Schema/database] S1 --> T1[Table] C3 --> F1[Fileset] C4 --> Tp1[Topic]

3 使用指南

安装部署

说明：Gravitino 官方从源码构建不支持 Windows（需 Linux/macOS），但已发布二进制包与 Docker 镜像，可在 Windows 上通过二进制/容器方式运行。

方式一：二进制包（推荐，支持本地快速启动）

从 Apache Gravitino 下载页下载并解压二进制发行包。
编辑 conf/gravitino.conf 完成基础配置。

启动 / 停止服务：

./bin/gravitino.sh start     # 启动
./bin/gravitino.sh stop      # 停止

（可选）Web UI 版本选择：

export GRAVITINO_USE_WEB_V2=false   # 回退到旧版 v1 UI
./bin/gravitino.sh restart

方式二：Docker / Playground（推荐体验全栈 / 亲测）

Docker 部署方式1：使用官方 Gravitino Playground（Docker Compose 一键拉起全栈体验），克隆 gravitino-playground 仓库按其 README 执行。
Docker 部署方式2：也支持拉取官方 Docker 镜像单独部署。（亲测）

docker run -d -i --name gravitino -p 8090:8090 -p 9001:9001 apache/gravitino:latest

8090：Gravitino Web UI 与主服务端口

9001：Iceberg REST 目录服务端口（Iceberg 客户端接入用）

latest 版本标签也可替换为: 1.3.0 等具体的版本号

启动后验证是否就绪：

# 浏览器打开 Web UI
http://localhost:8090

# 或命令行检查版本接口
curl -v -X GET -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  http://localhost:8090/api/version

常用运维命令：

# 查看日志
docker logs -f gravitino

# 进入容器
docker exec -it gravitino bash

# 停止 / 删除
docker stop gravitino
docker rm gravitino

调整 JVM 内存

默认堆为 -Xms1024m -Xmx1024m -XX:MaxMetaspaceSize=512m，数据量大时可调大：

docker run -d -i --name gravitino -p 8090:8090 -p 9001:9001 \
  -e GRAVITINO_MEM="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=1g" \
  apache/gravitino:1.3.0

如果想体验完整生态（Hive + Trino + Gravitino）可用 Playground

官方单镜像只含 Gravitino Server 基础配置。要一键拉起完整湖仓环境，用 Docker Compose：

git clone https://github.com/apache/gravitino-playground.git
cd gravitino-playground
docker compose up -d

其他可选官方镜像（按需）

镜像	用途	示例
`apache/gravitino-iceberg-rest`	独立 Iceberg REST 服务	`docker run -d -p 9001:9001 apache/gravitino-iceberg-rest:1.3.0`
`apache/gravitino-mcp-server`	MCP Server（AI Agent 接入）	`docker run -d -p 8000:8000 apache/gravitino-mcp-server:1.3.0 --metalake test --transport http --mcp-url http://0.0.0.0:8000/mcp`
`apache/gravitino-lance-rest`	Lance 向量目录服务	`docker run -d -p 9102:9102 -e LANCE_REST_GRAVITINO_METALAKE_NAME=test -e LANCE_REST_GRAVITINO_URI=http://host-ip:8090 apache/gravitino-lance-rest:1.3.0`

需要注意的点：

首次拉取镜像较大（含多个目录连接器），请耐心等待。
localhost:8090 是宿主机访问地址；若容器内的服务要访问容器外的主机服务（如外部 Hive Metastore、Lance 连 Gravitino），用宿主机 IP 而不是 localhost。
默认镜像是基础配置，生产环境建议通过 docker run -v 挂载自定义 conf/gravitino.conf、conf/gravitino-env.sh 或各 catalog 配置文件。

方式三：从源码构建（Linux/macOS）

# 无测试干净构建
./gradlew clean build -x test
# 构建发行包（产物在 distribution/ 目录）
./gradlew compileDistribution -x test
# 跳过 Web UI 构建
./gradlew compileDistribution -PskipWebBuild=true -x test
# 压缩发行包
./gradlew assembleDistribution -x test

关键操作（以常用命令/接口为例）

使用 Gravitino CLI：提供命令行管理 Metalake、Catalog、Schema、Table、Fileset、Topic、Model 等资源。
使用 Java / Python 客户端：通过 REST API 与客户端库编程式管理元数据。
使用 Iceberg REST 目录：Iceberg 客户端直接对接 Gravitino 的 REST 目录服务，无需额外转换层。
接入查询引擎：
- Trino：部署 Gravitino Trino 连接器后，用原生 SQL 查询统一目录元数据与数据；
- Spark / Flink / Daft：分别通过对应连接器接入（如 Spark–Paimon、Flink–Iceberg 等）。
Web UI：通过 Web 界面可视化管理元数据（1.2+ 默认使用 Web V2 UI）。
安全接入：支持认证（OAuth / Kerberos / 简单令牌）、授权（可集成 Apache Ranger）、安全凭证分发（云存储）。

Web UI Intro (Docker版)

假定已通过docker run -d -i --name gravitino -p 8090:8090 -p 9001:9001 apache/gravitino:1.3.0成功部署。
此时可访问: http://localhost:8090/ui/metalakes

创建 Catalog （可选步骤）

支持创建的 Catalog 的数据源:

MySQL / PostgreSQL / OceanBase

Clickhouse / Apache Doris / StarRocks / Hologres / Apache Hive

Lakehouse Generic / AWS Glue / Apache Hudi / Apache Iceberg / Apache Paimon

创建 Job

CASE Gravitino (Docker版) 纳管 PostgreSQL

在 Windows 本地用 Docker 部署的 Gravitino 快速体验 PostgreSQL 元数据管理的完整实操步骤。

前置：准备一台 PostgreSQL（数据源）

Apache Gravitino 只是元数据目录，要"纳管 PostgreSQL"，得先有一台 PostgreSQL 可供容器访问。

最省事的方式：再起一个 PostgreSQL 容器，并把 5432 端口映射到宿主机（这样 Gravitino 容器可通过 host.docker.internal:5432 访问）。

docker run -d --name postgres  -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=mydb -p 5432:5432 postgres:16

如果你本机已装了 PostgreSQL，也可以直接用宿主机的 5432，Gravitino 容器通过 jdbc:postgresql://host.docker.internal:5432/库名 连接即可（Windows Docker Desktop 会自动解析 host.docker.internal 到宿主机）。

通过 dbeaver 可以成功连接。

我准备了3张表和样例数据（便于后续步骤中查看其元数据管理能力）

第 1 步：确认 Gravitino 的安装已就绪

假定已通过docker run -d -i --name gravitino -p 8090:8090 -p 9001:9001 apache/gravitino:1.3.0成功部署。
此时可访问: http://localhost:8090/ui/metalakes

查验状态/版本

确认 Gravitino 已就绪

$ curl http://localhost:8090/api/version -v

响应信息，形如:
StatusCode        : 200
StatusDescription : OK
Content           : {"code":0,"version":{"version":"1.3.0","compileDate":"28/06/2026 11:57:15","gitCommit":"40fdf6ab96ac87b47e6d3e14e7c4dc0d815e68f0"}}
RawContent        : HTTP/1.1 200 OK
                    Content-Length: 131
                    Content-Type: application/json
                    Date: Tue, 22 Sep 2026 17:02:33 GMT
                    Server: Jetty(9.4.58.v20250814)

                    {"code":0,"version":{"version":"1.3.0","compileDate":"28/0...
Forms             : {}
Headers           : {[Content-Length, 131], [Content-Type, application/json], [Date, Tue, 22 Sep 2026 17:02:33 GMT], [Server, Jetty(9.4.58.v20250814)]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 131

返回版本号即正常。浏览器可访问 http://localhost:8090 打开 Web UI。

第 2 步：创建 Metalake（元数据湖租户）

创建 Metalake

curl -X POST -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  -d '{"name":"demo_metalake","comment":"demo metalake","properties":{}}' \
  http://localhost:8090/api/metalakes

成功的样例响应:

{"code":0,"metalake":{"name":"demo_metalake","comment":"demo metalake","properties":{},"audit":{"creator":"anonymous","createTime":"2026-09-22T17:05:39.686392495Z"}}}

注意1: 入参 name 不支持-符号，但支持_符号。

查看界面 Metalake 实例

http://localhost:8090/ui/metalakes

第 3 步：创建 PostgreSQL Catalog（核心：接入数据源）

把 PostgreSQL 库注册成 Gravitino 的一个 RELATIONAL 目录（provider 为 jdbc-postgresql），在 properties 里填 JDBC 连接信息：

curl -X POST -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "pg_catalog",
    "type": "RELATIONAL",
    "provider": "jdbc-postgresql",
    "comment": "PostgreSQL demo catalog",
    "properties": {
      "jdbc-url": "jdbc:postgresql://host.docker.internal:5432/mydb",
      "jdbc-driver": "org.postgresql.Driver",
      "jdbc-user": "postgres",
      "jdbc-password": "postgres",
      "jdbc-database": "mydb"
    }
  }' \
  http://localhost:8090/api/metalakes/demo_metalake/catalogs

需注意：Gravitino 的 catalog 属性创建后不可修改。所以，光改配置是没用的，需要【删除】后【重建】

curl -X DELETE -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog

成功的样例响应:

{"code":0,"catalog":{"name":"pg_catalog","type":"relational","provider":"jdbc-postgresql","comment":"PostgreSQL demo catalog","properties":{"jdbc-url":"jdbc:postgresql://host.docker.internal
:5432/mydb","jdbc-driver":"org.postgresql.Driver","in-use":"true"},"audit":{"creator":"anonymous","createTime":"2026-09-22T17:26:23.503230905Z","lastModifier":"anonymous","lastModifiedTime":
"2026-09-22T17:26:23.503230905Z"}}}

说明：

Gravitino 的 Catalog 对应 PostgreSQL 的一个 database（这里就是 mydb）；

Gravitino 的 Schema 对应 PostgreSQL 的 schema；

Gravitino 的 Table 对应 PostgreSQL 的表；

官方二进制/Docker 镜像已内置 jdbc-postgresql 目录及其驱动，无需额外下载。若创建时报驱动缺失，把 postgresql-*.jar 放进容器 catalogs/jdbc-postgresql/libs/ 后重启即可。

第 4 步 : 查阅、享用 Postgre Catalog

# 1) 列出目录
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs

  注: 样例输出: {"code":0,"identifiers":[{"namespace":["demo_metalake"],"name":"pg_catalog"}]}

# 2) 加载指定 Catalog
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog

  注: 样例输出: {"code":0,"catalog":{"name":"pg_catalog","type":"relational","provider":"jdbc-postgresql","comment":"PostgreSQL demo catalog","properties":{"jdbc-url":"jdbc:postgresql://host.docker.internal:5432/mydb","jdbc-dri
ver":"org.postgresql.Driver","in-use":"true"},"audit":{"creator":"anonymous","createTime":"2026-09-22T17:26:23.503230905Z","lastModifier":"anonymous","lastModifiedTime":"2026-09-22T17:26:23.503230905Z"}}}


# 3) 列出指定 Catalog 某 schema（如 public）下已有的表
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/public/tables
> 样例响应:
{"code":0,"identifiers":[{"namespace":["demo_metalake","pg_catalog","public"],"name":"course"},{"namespace":["demo_metalake","pg_catalog","public"],"name":"elective"},{"namespace":["demo_metalake","pg_catalog","
public"],"name":"student"}]}

# 4) 加载某张已有表的完整元数据（列、类型、索引等）
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/public/tables/student
> 样例响应:
{"code":0,"table":{"name":"student","comment":"学生维度表","columns":[{"name":"id","type":{"type":"external","catalogString":"bigserial"},"comment":"代理主键ID","nullable":false,"autoIncrement":true,"defaultValu
e":{"type":"unparsed","unparsedExpression":"nextval('student_id_seq'::regclass)"}},{"name":"student_no","type":"varchar(20)","comment":"学号 (业务唯一键)","nullable":false,"autoIncrement":false},{"name":"name","
type":"varchar(50)","comment":"姓名","nullable":false,"autoIncrement":false},{"name":"gender","type":{"type":"external","catalogString":"gender_enum"},"comment":"性别","nullable":true,"autoIncrement":false,"defa
ultValue":{"type":"unparsed","unparsedExpression":"'男'::gender_enum"}},{"name":"age","type":"short","comment":"年龄","nullable":true,"autoIncrement":false,"defaultValue":{"type":"literal","dataType":"short","va
lue":"18"}},{"name":"major_no","type":"varchar(20)","comment":"专业号","nullable":true,"autoIncrement":false,"defaultValue":{"type":"literal","dataType":"null","value":"NULL"}},{"name":"create_time","type":"time
stamp(6)","comment":"记录创建时间","nullable":true,"autoIncrement":false,"defaultValue":{"type":"function","funcName":"current_timestamp","funcArgs":[]}}],"properties":{},"audit":{},"distribution":{"strategy":"n
one","number":0,"funcArgs":[]},"sortOrders":[],"partitioning":[],"indexes":[{"indexType":"UNIQUE_KEY","name":"student_student_no_key","fieldNames":[["student_no"]],"properties":{}},{"indexType":"PRIMARY_KEY","na
me":"student_pkey","fieldNames":[["id"]],"properties":{}}]}}

查看 web ui:

http://localhost:8090/ui/catalogs?metalake=demo_metalake&catalogType=relational

http://localhost:8090/ui/catalogs?metalake=demo_metalake&catalog=pg_catalog&catalogType=relational&schema=public&table=course

第 5 步：手动创建 Schema（在 PostgreSQL 里真实建 schema） | 可选步骤

curl -X POST -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  -d '{"name":"app","comment":"app schema","properties":{}}' \
  http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas

样例响应:

{"code":0,"schema":{"name":"app","comment":"app schema","properties":{},"audit":{"creator":"anonymous","createTime":"2026-09-23T03:58:35.492130873Z"}}}

http://localhost:8090/ui/catalogs?metalake=demo_metalake&catalog=pg_catalog&catalogType=relational&schema=app

第 6 步：手动创建表（含列、主键索引，DDL 会真实落到 PostgreSQL） | 可选步骤

curl -X POST -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "users",
    "comment": "user table",
    "columns": [
      {"name": "id",   "type": "long",       "nullable": false, "autoIncrement": true},
      {"name": "name", "type": "varchar(200)", "nullable": false},
      {"name": "email","type": "varchar(320)", "nullable": true}
    ],
    "indexes": [
      {"indexType": "primary_key", "name": "pk_users", "fieldNames": [["id"]]}
    ]
  }' \
  http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/app/tables

样例响应:

{"code":0,"table":{"name":"users","comment":"user table","columns":[{"name":"id","type":"long","nullable":false,"autoIncrement":true},{"name":"name","type":"varchar(200)","nullable":false,"autoIncrement":false},
{"name":"email","type":"varchar(320)","nullable":true,"autoIncrement":false}],"properties":{},"audit":{"creator":"anonymous","createTime":"2026-09-23T04:03:51.705085881Z"},"distribution":{"strategy":"none","numb
er":0,"funcArgs":[]},"sortOrders":[],"partitioning":[],"indexes":[{"indexType":"PRIMARY_KEY","name":"pk_users","fieldNames":[["id"]],"properties":{}}]}}

http://localhost:8090/ui/catalogs?metalake=demo_metalake&catalog=pg_catalog&catalogType=relational&schema=app
http://localhost:8090/ui/catalogs?metalake=demo_metalake&catalog=pg_catalog&catalogType=relational&schema=app&table=users

第 7 步：查询 / 修改 / 删除元数据 | 可选步骤

本步骤未一一亲测，修改、删除操作在生产环境需谨慎操作。

# 列出 schema 下的表
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/app/tables

# 加载单张表
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/app/tables/users

# 修改表（加列 + 改注释）
curl -X PUT -H "Accept: application/vnd.gravitino.v1+json" \
  -H "Content-Type: application/json" \
  -d '{"updates":[
        {"@type":"addColumn","fieldName":["age"],"type":"integer","nullable":true},
        {"@type":"updateComment","newComment":"user table v2"}
      ]}' \
  http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/app/tables/users

# 删除表
curl -X DELETE -H "Accept: application/vnd.gravitino.v1+json" "http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/app/tables/users?purge=false"

第 8 步：验证"双向同步"（关键卖点）

回到 PostgreSQL 里确认 DDL 已真实生效——Gravitino 是直接管理而非【被动采集】：

docker exec -it postgres psql -U postgres -d mydb

# 在 psql 里查看
\dn              -- 应看到 schema "app"
\d app.users     -- 应看到 users 表及其列、主键

操作结果:

(base) PS C:\Users\Johnny> docker exec -it postgres psql -U postgres -d mydb
psql (16.15 (Debian 16.15-1.pgdg13+2))
Type "help" for help.
mydb=# \dn
      List of schemas
  Name  |       Owner
--------+-------------------
 app    | postgres
 public | pg_database_owner
(2 rows)
mydb=#
mydb=# \d app.users
                                     Table "app.users"
 Column |          Type          | Collation | Nullable |             Default
--------+------------------------+-----------+----------+----------------------------------
 id     | bigint                 |           | not null | generated by default as identity
 name   | character varying(200) |           | not null |
 email  | character varying(320) |           |          |
Indexes:
    "pk_users" PRIMARY KEY, btree (id)

mydb=#

你会看到 Gravitino 在 schema/表注释里写入的内部标记（如 (From Gravitino, DO NOT EDIT: gravitino.v1.uid...)），不要改动，那是它跟踪元数据用的。

可视化方式（更省事）

打开 http://localhost:8090 的 Web UI（v1.2+ 默认 Web V2），可以图形化：创建 Metalake → 创建 Catalog（选 PostgreSQL 填 JDBC）→ 浏览/新建 Schema 与 Table，不必手敲 curl。

几点提醒

连接串里用 host.docker.internal，不要用 localhost（容器内 localhost 指向容器自身）。
PostgreSQL 的数据库 = Catalog、schema = Schema、表 = Table，别把概念搞混。
Gravitino 支持 PostgreSQL 12–16，建表类型映射见官方文档（如 Gravitino Long→Int8、varchar(n)→varchar、Decimal→numeric 等）。
想更深体验，可再接入 Trino 引擎做"跨源联邦查询"，或用官方 Python 客户端 client = GravitinoClient(...) 编程式管理。

Z FAQ for Apache Gravitino

Q: Gravitino 与 Hive Metastore（HMS）有什么区别？(必读)

HMS 仅面向 Hive 生态管理表元数据；
Apache Gravitino 是联邦元数据湖，通过连接器统一管理 Hive、Iceberg、Paimon、MySQL、PostgreSQL、Kafka、文件系统、AI 模型等多源元数据，并提供统一治理（权限、审计、发现）与跨地域联邦。
- Gravitino 也可以把 HMS 作为一个目录来注册和管理。

Q: Gravitino 和 Iceberg REST Catalog 是什么关系？（必读）

Gravitino 原生提供兼容 Iceberg 规范的 Iceberg REST 目录服务（IRC），Iceberg 客户端可直接使用。
它同时充当跨地域联邦的代理节点：本地 IRC 目录可把请求代理到远程 Gravitino 实例，从而获得全局元数据视图。

Q: Gravitino 能运行在 Windows 上吗？

A: 官方提供二进制发行包和 Docker 镜像，在 Windows 上可通过解压二进制或容器方式运行服务；但从源码构建（Gradle）官方声明不支持 Windows，源码构建请在 Linux/macOS 上进行。

Q: Gravitino 是商业软件吗？授权如何？

A: 它是完全开源的 Apache 2.0 协议项目，且已毕业为 Apache 顶级项目（TLP）。其背后有商业化公司 Datastrato 提供企业版（Datastrato Enterprise）支持，但 Apache Gravitino 本身开源免费。

Q: Gravitino 支持哪些数据源和引擎？

A: 目录侧支持关系型（Hive/Iceberg/Paimon/Hudi/MySQL/PostgreSQL/Doris/OceanBase/StarRocks/ClickHouse/Hologres）、文件集（HDFS/S3/GCS/OSS/ADLS/COS）、消息（Kafka）、模型（Model）、AWS Glue、Lakehouse 通用（Delta/Lance）等；引擎侧支持 Trino、Spark、Flink、Daft 及 Java/Python 客户端。

Q: Gravitino 的 AI 资产能力成熟吗？与Lance的集成？（必读）

A: Model Catalog（模型目录）已随 0.8 引入并持续增强，Lance REST 服务（向量数据集）在 1.1 提供，MCP Server 支持 AI Agent 接入数据上下文。但整体 AI 资产能力在官方文档中仍标注为 WIP（开发中），生产使用需关注版本成熟度。

Q: 相比 Databricks 的 Unity Catalog(闭源)，为什么选 Gravitino？（必读）

Unity Catalog：功能成熟、但闭源且与 Databricks 平台绑定；
Apache Gravitino ：是开放中立的 Apache 顶级项目，可用开放架构统一治理 Iceberg/Hudi/Paimon/Delta 等Catalog格式，减少对专有目录的依赖，并支持"在数据所在处治理"而不迁移数据。

Q: 把 Gravitino 作为统一的catalog，是否可以把Doris内部表纳入呢？（必读）

可以。

但要分清“纳管 Doris 内部表的元数据”和“把内部表变成 Iceberg Catalog 管理”这两件事——Gravitino 做的是前者，不会把 Apache Doris 表改造成湖表。

一、Gravitino 对 Doris 内部表的纳管支持

Gravitino 提供 Doris catalog（relational / jdbc-doris），通过 JDBC 连 Doris 实例，把 Doris 的库表当作【统一元数据对象】管理：

schema ↔ Doris database，table ↔ Doris 表
支持建/删库表、改表名、加删列、改列类型/注释、设表属性、注释
支持 Doris 分区（RANGE/LIST）、主键索引、列默认值、replication_num 等属性
类型映射覆盖 Boolean/TinyInt/SmallInt/Int/BigInt/Float/Double/Decimal/Date/DateTime/Varchar/Char/String；不支持 Timestamp_tz、Struct、Map、List、UUID 等，会落为 Unparsed
改动双向生效：Gravitino 侧建表会写到 Doris，Doris 侧变更也可通过 Gravitino 管理；alter 在 Doris 是异步的，刚改完查元数据可能短暂不一致

使用时要自己放 Doris JDBC 驱动到 catalogs/jdbc-doris/libs，用 jdbc-url / jdbc-user / jdbc-password 连接，未知参数可用 gravitino.bypass.* 透传。

结论：Doris 内部表（Duplicate/Unique/Aggregate 等）可以整体注册进 Gravitino 的 metalake，作为“统一目录”的一员做发现、鉴权、审计、schema 治理。

二、但它在“湖仓/多引擎查询”里的边界

Gravitino 是元数据+治理层，不是表格式转换层：

注册 Doris catalog 后，表底层仍是 Doris 自有存储，没有 Iceberg 的 snapshot、time travel、open Parquet/ORC 文件管理、schema/partition evolution 那一套。
如果目标是“多引擎像查 Iceberg 一样查 Doris 内部表”，要看消费端连接器：
- Trino + Gravitino connector：可把 Doris catalog 和 Iceberg catalog 都挂到同一 metalake，Trino 统一发现、跨源 join（Doris 走 JDBC、Iceberg 走 Iceberg 连接器）。这是最典型的“统一查询”用法。
- Spark/Flink：Gravitino 提供统一元数据/命名，实际读 Doris 仍走对应 Spark JDBC 或 Doris 连接器，不会因挂了 Gravitino 就变成 Iceberg。
- Doris 自己：Doris 通过 Gravitino 主要用来访问 Iceberg REST（S3/MinIO 上的 Iceberg），而不是把 Doris 内部表反向暴露给别的引擎当 Iceberg。

三、常见三种落地姿势

只做统一元数据/治理
Gravitino 注册 doris_catalog（jdbc-doris）+ iceberg_catalog（lakehouse-iceberg/Iceberg REST）+ Hive/MySQL 等，Web/REST/CLI 统一看库表、做 RBAC、审计。Doris 内部表原样不动。
多引擎联邦查询
Trino 接 Gravitino 一个 connector，注册 Doris 和 Iceberg 两个 catalog，SQL 直接 doris_db.t1 join iceberg_db.t2。元数据集中在 Gravitino，查询下推由各引擎连接器负责。
Doris 内部表要进湖格式
别靠 Gravitino “纳管”实现，而是：

在 Iceberg catalog 建表，定期 INSERT INTO iceberg_ctl.x SELECT * FROM doris_internal.x 同步；或
Doris 建 Iceberg 外部 catalog 直接读/写 Iceberg，Gravitino 只管 Iceberg 那边的元数据与凭证（vended-credentials 给 Doris/Trino/Spark 分发临时 AK）。

四、总结

想“Doris 内部表在统一 catalog 里被看到、被管 schema、被做权限/审计”→ Gravitino Doris catalog 可以。
想“Doris 内部表变成 Iceberg、带 snapshot/time travel、被 Spark/Trino 当原生湖表读”→ 不行，得另建 Iceberg 表做同步/双写。
想“Trino/Spark 统一查 Doris+Iceberg”→ Gravitino 做【统一注册】和【治理】，查询能力取决于各引擎连接器。

Q: 当 postgresql 已经有几张表时，如何让 gravitino 自动采集元数据，而非手动去操纵 schema / table 等元数据？ (必读)

这个问题问到了 Gravitino 的核心设计差异上。

关键结论：Gravitino 不做"采集"，只做"直连注册"——已存在的表会自动可见

Gravitino 的定位是直接管理（Direct Metadata Management），官方文档明确区别于传统目录：

"Unlike traditional metadata management systems, which need to collect the metadata actively or passively from underlying systems, Gravitino manages these systems directly. The changes in Gravitino directly reflect in the underlying systems, and vice versa."

也就是说：Gravitino 没有"扫描/采集/同步"已有元数据进自己存储的机制。它的逻辑是——你只需要注册一个 Catalog（即指向 PostgreSQL 那个数据库的连接），之后 Gravitino 的连接器就实时直读 PostgreSQL 里的真实 schema 和表。

所以，对已有表的处理非常简单：

你不需要手动 POST 建 schema / 建 table。 只要建好 Catalog，然后用 GET（列出）就能看到 PostgreSQL 里已有的表。

实操：让已有表"自动出现"

沿用上一步，pg_catalog 指向 mydb 库。建好 Catalog 后，直接列出来即可，无需任何创建操作：

# 1) 列出 PostgreSQL 已有的 schema（会真实读到 public、information_schema 等）
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas
> 样例响应:
{"code":0,"identifiers":[{"namespace":["demo_metalake","pg_catalog"],"name":"public"}]}

# 2) 列出某 schema（如 public）下已有的表
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/public/tables
> 样例响应:
{"code":0,"identifiers":[{"namespace":["demo_metalake","pg_catalog","public"],"name":"course"},{"namespace":["demo_metalake","pg_catalog","public"],"name":"elective"},{"namespace":["demo_metalake","pg_catalog","
public"],"name":"student"}]}

# 3) 加载某张已有表的完整元数据（列、类型、索引等）
curl -X GET -H "Accept: application/vnd.gravitino.v1+json" http://localhost:8090/api/metalakes/demo_metalake/catalogs/pg_catalog/schemas/public/tables/student
> 样例响应:
{"code":0,"table":{"name":"student","comment":"学生维度表","columns":[{"name":"id","type":{"type":"external","catalogString":"bigserial"},"comment":"代理主键ID","nullable":false,"autoIncrement":true,"defaultValu
e":{"type":"unparsed","unparsedExpression":"nextval('student_id_seq'::regclass)"}},{"name":"student_no","type":"varchar(20)","comment":"学号 (业务唯一键)","nullable":false,"autoIncrement":false},{"name":"name","
type":"varchar(50)","comment":"姓名","nullable":false,"autoIncrement":false},{"name":"gender","type":{"type":"external","catalogString":"gender_enum"},"comment":"性别","nullable":true,"autoIncrement":false,"defa
ultValue":{"type":"unparsed","unparsedExpression":"'男'::gender_enum"}},{"name":"age","type":"short","comment":"年龄","nullable":true,"autoIncrement":false,"defaultValue":{"type":"literal","dataType":"short","va
lue":"18"}},{"name":"major_no","type":"varchar(20)","comment":"专业号","nullable":true,"autoIncrement":false,"defaultValue":{"type":"literal","dataType":"null","value":"NULL"}},{"name":"create_time","type":"time
stamp(6)","comment":"记录创建时间","nullable":true,"autoIncrement":false,"defaultValue":{"type":"function","funcName":"current_timestamp","funcArgs":[]}}],"properties":{},"audit":{},"distribution":{"strategy":"n
one","number":0,"funcArgs":[]},"sortOrders":[],"partitioning":[],"indexes":[{"indexType":"UNIQUE_KEY","name":"student_student_no_key","fieldNames":[["student_no"]],"properties":{}},{"indexType":"PRIMARY_KEY","na
me":"student_pkey","fieldNames":[["id"]],"properties":{}}]}}

返回的就是 PostgreSQL 里真实存在的表——你没有手动创建过任何 schema/table，它们通过连接器被"直接读取"出来。在 Web UI 里也一样：进到 Catalog → 展开 schema，已有表直接可见。

这点为什么重要（避免误区）

你的心智模型	Gravitino 实际行为
"采集元数据进 Gravitino 存储"	❌ 不成立。Gravitino 【不复制】一份元数据存起来
"手动 POST 建 schema/table 才能纳管"	❌ 不需要。建 Catalog 即可，表自动可见
"底层表变了要手动同步"	❌ 不需要。底层变更会实时反映（反之亦然）
只需"注册数据源连接"	✅ 建 Catalog = 注册连接，后续全部直读

换言之：Gravitino 的"元数据管理"发生在"读"的环节（list/load），而不是"写入采集"的环节。 你只用管"注册了哪些数据源（Catalog）"这一件事。

如果你真正需要的是"爬取式的元数据盘点/目录/血缘"

这要澄清一下：如果你期望的是一个把元数据采集到独立存储、做统一搜索、血缘、数据目录门户的系统，那 Gravitino 不是这个定位——它是"治理层 + 访问层"，需要的话可以配合这类工具：

OpenMetadata / DataHub / Amundsen：典型"采集型"元数据目录/发现平台，会 crawl 你的 PostgreSQL、做索引和搜索、血缘；
Gravitino 则负责在你现有系统之上【统一治理与统一访问】（权限、审计、跨源查询），两者可互补，不冲突。

总结

对已有 PostgreSQL 表：建一个指向该库的 Catalog 即可，Gravitino 自动"看得到"里面所有已存在的 schema/表，无需手动创建或同步。 它不采集、不复制，而是直连直读——这是它与传统采集式目录的本质区别。

Y 推荐文献

Apache Gravitino

https://gravitino.apache.org

https://github.com/apache/gravitino

https://gravitino.apache.org/docs/latest | 官方文档（最新版）

https://github.com/apache/gravitino/blob/main/ROADMAP.md | ROADMAP（路线图）

https://gravitino.incubator.apache.org/blog/ | 官方博客 / 版本发布说明

...

https://gravitino.incubator.apache.org/blog/2025-summary/ | 2025 年度总结

Gravitino 1.3 "Govern at the Source" - Datastrato 博客

Gravitino Playground - GitHub

X 参考文献

posted @ 2026-09-23 00:49 千千寰宇阅读(9) 评论(0) 收藏举报

刷新页面返回顶部

千千寰宇

面向Data+AI转型的软件工程师，数智化转型实践者。 【文章分类】 【网络测验方法】 【好物推荐】