Apache Gravitino 1.3.0: föderierter Metadaten-See mit Iceberg- und Lance-REST-Katalog
Projektüberblick: Der weltweit leistungsstärkste offene Datenkatalog zum Aufbau eines leistungsstarken, geografisch verteilten und föderierten Metadatensees.
Auf einen Blick
- Was ist das?
- Gravitino bündelt Metadaten aus Hive, MySQL, HDFS und S3 hinter einem Modell. Wir prüfen README, Startbefehle, Gradle-Build und Reifegrad.
- Für wen ist es gedacht?
- Gravitino lohnt sich für Umgebungen, in denen Metadaten über mehrere Quellsysteme und Regionen verstreut liegen und eine gemeinsame Sicht mit Zugriffskontrolle gebraucht wird. Wer ausschließlich Iceberg-Tabellen katalogisieren will, ist mit Apache Polaris schlanker unterwegs, und für KI-Bestände ist das Projekt noch nicht fertig, weil dieser Bereich im README als laufende Arbeit geführt wird.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 18. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was Gravitino als föderierter Metadaten-See verwaltet
Das README von apache/gravitino beschreibt das Projekt als leistungsstarken, geografisch verteilten und föderierten Metadaten-See. Die Formulierung verrät die Stoßrichtung: Gravitino will Metadaten nicht an einem Ort sammeln, sondern dort verwalten, wo sie entstehen, also in unterschiedlichen Quellen, Typen und Regionen. Nach außen soll daraus ein einheitlicher Zugriff auf Daten- und KI-Bestände werden.
Der Ausgangspunkt ist ein bekanntes Problem. In gewachsenen Umgebungen liegen Tabellenbeschreibungen im Hive-Metastore, Zugriffsrechte in einem eigenen System, Objektlisten im Speicher und Modellangaben wiederum woanders. Wer eine Frage nach Herkunft oder Berechtigung beantworten will, fragt mehrere Systeme ab. Gravitino setzt sich davor und liefert eine gemeinsame Sicht.
Die Metadaten nennen Java als Sprache und die Apache-Lizenz 2.0. Zum Abrufzeitpunkt standen knapp 3.200 Sterne und 918 Forks im Raum, hinzu kamen etwas über 1.000 offene Issues. Standardbranch ist main, die jüngste Aktivität datiert vom Juni 2026.
Hive, MySQL, MariaDB, HDFS und S3 hinter einem Gravitino-Modell
Sechs Merkmale listet das README auf. Das erste ist die einheitliche Metadatenverwaltung über ein einziges Modell und eine einzige Programmierschnittstelle, wobei Hive, MySQL, MariaDB, HDFS und S3 als Beispielquellen genannt werden. Das zweite betrifft Daten-Governance über den gesamten Weg, mit Zugriffskontrolle, Prüfprotokoll und Auffindbarkeit.
Das dritte Merkmal ist dasjenige, an dem der Ansatz trägt oder scheitert: die direkte Metadaten-Integration. Änderungen in den angebundenen Systemen sollen über die Konnektoren von Gravitino sofort sichtbar werden. Das README beschreibt damit einen lesenden Durchgriff statt einer Kopie. Ein solcher Durchgriff spart den Abgleich zwischen Katalog und Quellsystem, macht die Antwortgeschwindigkeit des Katalogs aber abhängig von der Erreichbarkeit der Quellen.
Hinzu kommen die geografische Verteilung, die Metadaten über Regionen und Cloud-Grenzen hinweg teilen soll, sowie die Anbindung an Abfrage-Engines ohne Anpassung von SQL-Dialekten. Das sechste Merkmal, die Verwaltung von KI-Beständen mit Nachverfolgung von Modellen und Merkmalen, ist im README ausdrücklich als Arbeit im Gang gekennzeichnet.
conf/gravitino.conf und ./bin/gravitino.sh start: der lokale Start
Für den lokalen Betrieb nennt das README eine kurze Folge. Zunächst wird eine Binärversion von der Download-Seite geholt und entpackt, danach wird conf/gravitino.conf angepasst, und mit ./bin/gravitino.sh start läuft der Server. Beendet wird er über ./bin/gravitino.sh stop. Wer eine vollständige Umgebung mit mehreren Komponenten möchte, findet im separaten Repository apache/gravitino-playground eine auf Docker Compose aufgebaute Spielwiese, die das README als empfohlenen Weg bezeichnet.
Ein Detail aus dem README wird im Betrieb schnell gebraucht. Die Weboberfläche liegt standardmäßig in der Fassung Web V2. Wer die ältere v1-Oberfläche bevorzugt, setzt die Umgebungsvariable GRAVITINO_USE_WEB_V2 auf false. Das geschieht laut README entweder in der Datei conf/gravitino-env.sh oder unmittelbar vor dem Start, gefolgt von ./bin/gravitino.sh restart. Der umgekehrte Weg führt über den Wert true.
Was in conf/gravitino.conf eingetragen werden kann, steht nicht im README. Auch eine erforderliche Java-Version wird dort nicht genannt, was vor dem ersten Start auf einer fremden Maschine eine zusätzliche Prüfung verlangt.
Iceberg-REST-Katalog und Lance-REST-Katalog in Gravitino
Zwei Katalogdienste hebt das README gesondert hervor: einen nativen Iceberg-REST-Katalog und einen nativen Lance-REST-Katalog. Beide werden mit einem Verweis auf die Projektdokumentation unter gravitino.apache.org/docs/latest genannt, ohne dass das README die Schnittstellenfläche, die Endpunkte oder die Konfiguration beschreibt.
Dass beide Dienste nebeneinander stehen, ist aufschlussreich. Iceberg ist ein Tabellenformat für Analysedaten, während Lance im KI-Umfeld verortet wird und damit zum Merkmal der KI-Bestandsverwaltung passt. Das README stellt diese Verbindung nicht ausdrücklich her, der genaue Verwendungszweck des Lance-Katalogs ergibt sich erst aus der verlinkten Seite. Beide Dienste lassen sich anhand des README allein also nicht bewerten.
Als dritte Anbindung nennt das README einen Konnektor für Trino, über den der föderierte Zugriff in Abfragen landet. Welche Trino-Versionen unterstützt werden und wie der Konnektor installiert wird, bleibt offen. Die Liste der Anwendungsfälle führt Trino und Spark ausdrücklich als Engines auf, für die der Zugriff ohne Anpassung der Abfragesprache funktionieren soll.
Gradle statt Maven: distribution/ bauen ohne Windows-Unterstützung
Wer aus den Quellen baut, arbeitet mit Gradle, nicht mit Maven. Das README nennt vier Befehle. ./gradlew clean build -x test erzeugt einen sauberen Bau ohne Tests. ./gradlew compileDistribution -x test erstellt eine Distribution. Sollen beide Weboberflächen übersprungen werden, lautet der Aufruf ./gradlew compileDistribution -PskipWebBuild=true -x test. Für ein komprimiertes Paket steht ./gradlew assembleDistribution -x test bereit. Die Ergebnisse liegen anschließend im Verzeichnis distribution/.
Eine Einschränkung ist unmissverständlich formuliert: Windows wird beim Bauen nicht unterstützt. Für reine Windows-Umgebungen bleibt damit der Weg über eine Binärversion oder über eine Unix-artige Umgebung, etwa ein Container.
Der Schalter -PskipWebBuild=true ist praktisch, wenn der Server ohnehin nur über die Schnittstelle bedient wird. Er ändert jedoch nichts daran, dass alle vier Befehle Tests auslassen; ein erfolgreicher Bau auf einem unbekannten Quellstand besagt damit wenig über das spätere Verhalten. Eine Gradle-Version wird nicht vorausgesetzt, der Wrapper ./gradlew zieht sie selbst.
Gravitino 1.3.0 gegen Apache Polaris: Föderation als Trennlinie
Der Versionsstand wirkt gefestigt. v1.3.0 erschien Ende Juni 2026, davor liegen v1.2.1 vom Mai 2026 und v1.1.1 vom April 2026. Es gibt damit eine Hauptlinie oberhalb von 1.0 mit mehreren Wartungsfreigaben in kurzer Folge, was einen anderen Reifegrad bedeutet als bei Projekten ohne Veröffentlichung.
Die auffälligste Einschränkung betrifft die Verwaltung von KI-Beständen. Sie ist im README als Arbeit im Gang markiert, und einer der Anwendungsfälle nennt die Herkunftsnachverfolgung von KI-Modellen als Standard in Entwicklung. Wer Gravitino vorrangig für Modell-Metadaten einsetzen will, begibt sich in einen unfertigen Bereich. Ebenso unerwähnt bleiben Messwerte zur Antwortgeschwindigkeit und eine Aussage zum Verhalten bei Ausfall einer angebundenen Quelle.
Als Alternative kommt Apache Polaris infrage, wenn ausschließlich Tabellen im Iceberg-Format katalogisiert werden sollen. Ein solcher Dienst deckt die Iceberg-REST-Schnittstelle ab und lässt die Anbindung fremder Quellsysteme außen vor. Gravitino wählt den breiteren Weg und föderiert Systeme wie Hive, MySQL, MariaDB, HDFS und S3 hinter einem Modell. Die Apache-Lizenz 2.0 erlaubt kommerzielle Nutzung und eigene Konnektoren bei Beachtung der Hinweispflichten; das README weist zudem darauf hin, dass Apache Gravitino eine Marke der Apache-Stiftung ist.
Redaktionelles Fazit
Gravitino lohnt sich für Umgebungen, in denen Metadaten über mehrere Quellsysteme und Regionen verstreut liegen und eine gemeinsame Sicht mit Zugriffskontrolle gebraucht wird. Wer ausschließlich Iceberg-Tabellen katalogisieren will, ist mit Apache Polaris schlanker unterwegs, und für KI-Bestände ist das Projekt noch nicht fertig, weil dieser Bereich im README als laufende Arbeit geführt wird. Vor dem Einsatz sollte der lokale Start mit ./bin/gravitino.sh start gegen die eigenen Quellen geprüft werden, wobei conf/gravitino.conf der Ort für die Anbindung ist.
Community-Notizen