apache/gravitino

如果你的数据环境已经超过单个元数据目录能管理的范围，Gravitino 值得认真评估：它想成为横跨异构存储、甚至跨区域的统一元数据层，而不是靠人肉在每个系统里各注册一遍。

解决什么问题

团队希望用同一个查询引擎同时访问 Hive 表、MySQL 库和 S3 上的对象，而不必给每个引擎逐个登记后端。现在的做法通常是在每个引擎里分别配置来源，访问规则和资产发现散落在多处，上游一变更就要挨个同步。Gravitino 在引擎和底层系统之间加了一层元数据服务，引擎只连一个端点，目录管理员只注册一次来源。最终得到的是跨引擎、跨区域的共享视图，名义上也覆盖 AI 资产。

有什么不同

核心机制是直接集成元数据：连接器读取底层系统的实时信息，而不是定时导入快照，README 称底层变更会立即反映出来。它还提供原生 Iceberg、Lance REST catalog 服务以及 Trino 连接器，如果你的技术栈里已经有这些组件，这一点很关键。访问控制、审计和发现等功能放在同一层，这其实是采用它的主要理由：你可以集中判断谁能看到哪个资产。

代价是 Gravitino 会成为查询链路上的一环。你在引擎和存储之间加了一台带自身配置、版本和升级节奏的服务，而它的价值取决于你实际有多少个来源和引擎。README 也把 AI 模型和特征管理标为进行中，所以“AI 资产”这部分目前更适合当作方向，而不是可以依赖的能力。

谁值得试

适合的场景是：平台团队在湖仓之上跑多个引擎，数据源分散在不同云或不同区域，联邦发现和集中治理是真实痛点。用 Docker Compose 搭的 playground 是评估整套组件比较稳妥的入口。如果只是单一数据库项目，或者只有一种引擎和一层存储，就不太合适：联邦和地理分布这套机制只会多出一个运维组件，却解决不了你实际没有的问题。如果只需要 Iceberg REST 访问，可以从 Iceberg REST catalog 服务文档 这个更窄的入口入手。

使用条件与边界

README 明确说明，用 Gradle 从源码构建目前不支持 Windows，Windows 上的开发者需要另找本地构建环境；想先跑服务的话，下载二进制发行包是文档给出的替代路径。构建和打包会涉及 Gradle 以及两个 Web UI，可以选择跳过 UI 构建。除了一次性搭建，持续成本在于治理和连接器维护：每接入一种来源就多一个需要配置、并跟上游变化保持同步的集成，访问控制和审计功能也需要你自己定策略。

AI 资产管理明确标注为 WIP，README 也没有给出既有目录的迁移路径或兼容性承诺；如果已经有成熟的 metastore，迁移前应按具体连接器去查 官方文档。

HotRepo 点评

HotRepo 目前只有两个日榜记录：2026-10-24 增加 11 星，2026-10-25 增加 8 星，样本太短，无法判断热度能否持续。Gravitino 不是周末玩具，它 2023 年 4 月就出现在 GitHub 上，也是 Apache 项目；但要不要长期采用，应取决于你是否真的需要跨引擎、跨区域的联邦能力，而不是榜单上的露面。投入之前，先确认你要用的存储和引擎对应的连接器在文档里有明确说明，因为这个目录的价值完全建立在这些集成之上。