Apache Polaris 1.7.0: Ein Iceberg-REST-Katalog für Spark, Trino, Flink und Dremio
Apache Polaris ist ein interoperabler Metadatenkatalog für Apache Iceberg-Tabellen, der für Cross-Engine-Kompatibilität konzipiert ist.
Auf einen Blick
- Was ist das?
- Apache Polaris implementiert die REST-Schnittstelle von Apache Iceberg und bedient damit mehrere Engines aus einem Katalog. Wir prüfen Modulstruktur, Build-Befehle, Zugangsdaten und was die README offenlässt.
- Für wen ist es gedacht?
- Polaris passt zu Teams, die Iceberg-Tabellen aus mehreren Engines über eine zentrale REST-Schnittstelle ansprechen, Java 21 einsetzen und Rechte in OPA oder Ranger halten. Weniger geeignet ist es für Umgebungen ohne Docker für die Integrationstests oder mit einer festen Hive-Metastore-Vorgabe, denn eine Kompatibilitätsmatrix liefert die README nicht.
- 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. Die letzten Commits kamen vor 1 Tag.
- 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 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Polaris als Iceberg-REST-Katalog für Doris, Flink, Spark und Trino
Die README von apache/polaris beschreibt das Projekt als vollständig ausgestatteten Katalog für Apache Iceberg, der die REST-Schnittstelle von Iceberg implementiert. Genau diese Entscheidung trägt die Reichweite: Wer die REST-Schnittstelle spricht, lässt sich von jedem Werkzeug ansprechen, das sie ebenfalls spricht. Als Plattformen nennt die README Apache Doris, Apache Flink, Apache Spark, Dremio OSS, StarRocks und Trino.
Die Metadaten ordnen das Vorhaben ein: Hauptsprache Java, Standardzweig main, Lizenz Apache-2.0, zuletzt gepusht am 2. August 2026. GitHub weist 2.044 Sterne, 510 Forks und 373 offene Issues aus. Das jüngste Release trägt den Namen Apache Polaris 1.7.0 und erschien am selben Tag, davor lagen 1.6.0 im Juli und 1.5.0 im Mai 2026.
Diese Versionsfolge sagt etwas über das Tempo. Drei Minor-Releases in knapp drei Monaten bedeuten, dass ein Upgrade mit Verhaltensänderungen einhergehen kann.
polaris-core, polaris-server und die Gradle-Modulgruppen
Die Projektstruktur ist in Gradle-Module gegliedert, die die README in Gruppen sortiert. Unter Core liegt polaris-core mit Entitätsdefinitionen und Geschäftslogik. Die Gruppe API wird aus den OpenAPI-Spezifikationen erzeugt und umfasst polaris-api-management-model, polaris-api-management-service, polaris-api-iceberg-service sowie polaris-api-catalog-service.
Unter Runtime finden sich polaris-server als Quarkus-basierter Server, polaris-admin als Verwaltungswerkzeug vor allem für das Aufsetzen der Persistenz, dazu polaris-runtime-service, polaris-runtime-defaults und polaris-distribution für die Auslieferung. Die Persistenz liefert polaris-relational-jdbc als JDBC-Umsetzung von BasePersistence.
Diese Aufteilung hilft beim Einstieg in den Quelltext. Wer die Entitätsdefinitionen sucht, beginnt in polaris-core; wer das Verhalten eines REST-Endpunkts nachvollziehen will, in der API-Gruppe. Einige Module besitzen eine eigene README, auf die die Übersicht verweist.
Von polaris-extensions-federation-hive bis polaris-extensions-auth-ranger
Unter Extensions listet die README zwei Richtungen. Die Module polaris-extensions-federation-hive, polaris-extensions-federation-hadoop und polaris-extensions-federation-bigquery dienen der Katalogföderation, binden also fremde Kataloge ein. Die Module polaris-extensions-auth-opa und polaris-extensions-auth-ranger lagern die Autorisierung an externe Systeme aus, jeweils mit eigenen Testmodulen.
Für Betriebe mit bestehenden Richtlinien ist das der Punkt, an dem sich der Katalog einfügt. Rechte werden nicht doppelt gepflegt, sondern in OPA oder Ranger gehalten und von dort abgefragt. Wer diese Module nicht braucht, muss sie auch nicht mitbauen.
Die README beschreibt die Module mit einem Stichwort und nicht mehr. Wie eine Föderation konfiguriert wird, welche Metastore-Stände unterstützt sind und wie sich externe Autorisierung auf Antwortzeiten auswirkt, steht dort nicht.
./gradlew run und die Zugangsdaten über polaris.bootstrap.credentials
Zum Bauen und Starten macht die README präzise Angaben. Gebaut wird mit Gradle, vorausgesetzt werden Java 21 und Docker 27. ./gradlew build baut und testet, ./gradlew assemble überspringt Tests, und ./gradlew check -PnoIntegrationTests führt alle Prüfungen außer den Integrationstests aus. Die Integrationstests setzen einen laufenden Docker-Daemon voraus.
Für den lokalen Betrieb steht ./gradlew run bereit; der Server ist danach unter localhost:8181 erreichbar. Die Zugangsdaten werden über eine Systemeigenschaft gesetzt: ./gradlew run -Dpolaris.bootstrap.credentials=POLARIS,root,secret. Der erste Wert POLARIS ist der Realm, root die CLIENT_ID und secret die CLIENT_SECRET. Wer nichts angibt, erhält laut README die voreingestellte Kombination POLARIS,root,s3cr3t.
An dieser Stelle entstehen die meisten Fehler in Testumgebungen. Die voreingestellten Werte gehören in keine Umgebung, die von außen erreichbar ist. Als erster Schritt nach dem Start eignet sich ./regtests/run_spark_sql.sh, über das sich im Spark-SQL-Shell eine Tabelle anlegen und abfragen lässt.
OpenAPI unter spec/, der Python-Client und die Polaris-Tools
Die Schnittstellen liegen als OpenAPI-Spezifikation im Repository. Im Verzeichnis spec/ finden sich unter anderem polaris-management-service.yml für die Verwaltungsschnittstelle und die gebündelte Datei bundled-polaris-catalog-service.yaml für die Katalogschnittstelle. Die README verweist darauf, dass sich beide online im Swagger-Editor betrachten lassen. Für Integrationsarbeit ist das brauchbar, weil die Spezifikation die Vertragsgrundlage bildet und sich unabhängig von einer installierten Serverversion lesen lässt.
Hinzu kommen ein Python-Client unter client/python/, ein Spark-Plugin unter plugins/spark/, Helm-Diagramme unter helm/ und Regressionstests unter regtests/. Der Aufruf env POLARIS_HOST=localhost ./regtests/run.sh startet die Regressionstests gegen einen lokalen Server.
Die README weist zudem darauf hin, dass weiteres Werkzeug im separaten Repository apache/polaris-tools liegt.
Java 21, Docker 27 und die Lücken der Polaris-README
Zur Einordnung der Quellen hilft eine Stelle im README: Ein automatisch erzeugtes Code-Wiki wird ausdrücklich als Orientierungshilfe bezeichnet, maßgeblich bleibe der Quellbaum. Diese Unterscheidung ist bei einem Java-Projekt dieser Größe nützlich, weil generierte Übersichten hinter dem Code herlaufen.
Was die README nicht liefert, lässt sich ebenfalls benennen. Es fehlt eine Kompatibilitätsmatrix mit Versionsangaben für Spark, Trino oder Flink. Leistungswerte, Aussagen zum Produktionseinsatz und Zusagen zur Unterstützung sucht man vergeblich. Die 373 offenen Issues deuten auf lebhafte Arbeit hin, ohne dass die README aufschlüsselt, woran gerade gearbeitet wird.
Als Alternative im selben Umfeld bietet sich Project Nessie an. Es nutzt ebenfalls die Iceberg-REST-Schnittstelle, setzt aber auf Git-artige Versionierung von Katalogzuständen mit Branches und Tags. Polaris zielt stärker auf den Betrieb als geteilter Katalog mit Föderation und ausgelagerter Autorisierung, was die Erweiterungsmodule zeigen. Wer Katalogstände verzweigen und zurücknehmen will, ist bei Nessie besser aufgehoben; wer mehrere Engines mit zentralen Rechten bedienen will, bei Polaris.
Redaktionelles Fazit
Polaris passt zu Teams, die Iceberg-Tabellen aus mehreren Engines über eine zentrale REST-Schnittstelle ansprechen, Java 21 einsetzen und Rechte in OPA oder Ranger halten. Weniger geeignet ist es für Umgebungen ohne Docker für die Integrationstests oder mit einer festen Hive-Metastore-Vorgabe, denn eine Kompatibilitätsmatrix liefert die README nicht. Vor einer Entscheidung sollte ./gradlew run mit eigenen Werten für polaris.bootstrap.credentials starten, eine Abfrage über ./regtests/run_spark_sql.sh gelingen und Release 1.7.0 gegen die eigene Engine-Version geprüft sein.
Community-Notizen