AWS Glue vs. S3 Tables: Wie Iceberg REST Catalogs funktionieren

Der Umstieg auf Apache Iceberg als Tabellenformat bringt neue Herausforderungen mit sich – besonders bei der Konfiguration von REST-Catalogs. Zwei AWS-Dienste nutzen dieselbe Iceberg-REST-Spezifikation, doch ihre Implementierungen unterscheiden sich fundamental in Aufbau und Verwendung. Während der AWS Glue Iceberg REST Catalog als zentraler Zugangspunkt für mehrere Kataloge fungiert, ist der Amazon S3 Tables Iceberg REST Catalog auf einzelne Tabellenspeicher optimiert. Diese Unterschiede werden bereits in den API-Pfaden sichtbar und wirken sich auf die gesamte Metadatenverwaltung aus.

Warum der Iceberg REST Catalog die Tabellenverwaltung revolutioniert

Apache Iceberg definiert mit dem Iceberg REST Catalog einen offenen Standard, der alle Katalogoperationen über eine HTTP-API standardisiert. Diese Spezifikation ermöglicht es Clients wie PyIceberg, Spark oder Trino, mit jedem kompatiblen Catalog auf die gleiche Weise zu kommunizieren. Der entscheidende Vorteil liegt in der Konsistenz: Unabhängig davon, ob ein Catalog auf AWS Glue, S3 Tables oder einem anderen System basiert, können Entwickler dieselben API-Aufrufe nutzen.

Die Spezifikation legt dabei klare Regeln fest:

Alle Endpunkte folgen einem festen URL-Muster wie GET /v1/{prefix}/namespaces.
Der {prefix}-Parameter dient als flexibler Segmentbezeichner für Kataloghierarchien.
Clients starten mit dem Aufruf von GET /v1/config, um die Endpunktkonfiguration abzurufen – darunter den Standard-prefix und weitere Einstellungen.
Tabellenmetadaten wie Schema, Snapshots oder Speicherorte werden in der LoadTable-Antwort als JSON zurückgegeben.

Unter der Haube bedeutet das: Wenn PyIceberg catalog.load_table("analytics.daily_sales") ausführt, wird intern eine HTTP-Anfrage an GET /v1/{prefix}/namespaces/analytics/tables/daily_sales gesendet. Diese Abstraktion vereinfacht die Arbeit mit Iceberg erheblich, erfordert aber ein tiefes Verständnis der zugrundeliegenden Mechanismen – besonders bei der Konfiguration der Authentifizierung.

Glue vs. S3 Tables: Zwei Philosophien, ein Standard

AWS setzt die Iceberg-REST-Spezifikation auf zwei unterschiedliche Weisen um. Die Kernunterschiede zeigen sich bereits in der Grundarchitektur der Endpunkte:

AWS Glue Iceberg REST Catalog

Endpoint: `
Prefix-Muster: /catalogs/{catalog} – unterstützt hierarchische Katalogstrukturen.
Authentifizierung: Kombination aus IAM-Rollen und Lake Formation für feingranulare Zugriffskontrollen.
SigV4-Dienstname: glue
Zweck: Dient als zentraler Einstiegspunkt für mehrere Kataloge, die auf unterschiedliche Datenquellen verweisen.

Amazon S3 Tables Iceberg REST Catalog

Endpoint: `
Prefix-Muster: URL-codierte Tabellenspeicher-ARN (z. B. arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test) – jeder Bucket entspricht einem eigenen Catalog.
Authentifizierung: Beschränkt auf S3-spezifische IAM-Aktionen.
SigV4-Dienstname: s3tables
Zweck: Optimiert für einzelne Tabellenspeicher, bei denen jede Tabelle direkt in einem dedizierten S3-Bucket liegt.

Diese Unterschiede werden besonders deutlich, wenn man die URL-Pfade der beiden Implementierungen vergleicht:

# Glue: Hierarchische Katalogstruktur
GET /v1/catalogs/glue/namespaces/analytics/tables/daily_sales

# S3 Tables: Direkter Bezug auf den Tabellenspeicher
GET /v1/arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test/namespaces/analytics/tables/daily_sales

Obwohl beide Endpunkte dasselbe metadata.json referenzieren, liegt der entscheidende Unterschied in der Verwaltung der Metadatenpfade. Ein Catalog in Iceberg verwaltet nicht die Metadatei selbst, sondern lediglich die metadata-location – den Pfad zum aktuellen metadata.json. Während Glue diese Pfade über eine Kataloghierarchie organisiert, nutzt S3 Tables direkte Bucket-ARNs für eine strikte 1:1-Beziehung zwischen Catalog und Speicherort.

Praktische Umsetzung: Testumgebung einrichten

Um die Unterschiede konkret zu demonstrieren, richten wir eine minimale Testumgebung mit S3 Tables ein. Die Schritte gelten analog für Glue, erfordern jedoch zusätzliche Konfigurationen wie Katalog-ID und Lake Formation-Einstellungen.

Tabellenspeicher und Namespace erstellen

Zuerst wird ein dedizierter Tabellenspeicher in der Region Tokio (ap-northeast-1) angelegt:

aws s3tables create-table-bucket \
  --name penguin-rest-test \
  --region ap-northeast-1

Anschließend wird ein Namespace für analytische Tabellen definiert:

aws s3tables create-namespace \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test \
  --namespace analytics

Schließlich wird eine Testtabelle mit einem einfachen Schema erstellt:

aws s3tables create-table \
  --table-bucket-arn arn:aws:s3tables:ap-northeast-1:123456789012:bucket/penguin-rest-test \
  --namespace analytics \
  --name daily_sales \
  --format ICEBERG \
  --metadata '{
    "iceberg": {
      "schema": {
        "fields": [
          {"name": "sales_date", "type": "date", "required": false},
          {"name": "amount", "type": "long", "required": false}
        ]
      }
    }
  }'

Authentifizierung mit SigV4: Warum curl allein nicht reicht

Die Iceberg-REST-Spezifikation sieht OAuth2 als Authentifizierungsmechanismus vor, doch AWS setzt stattdessen auf SigV4-Signierung – eine bewährte Methode für AWS-APIs. Diese Signierung stellt sicher, dass jede Anfrage mit gültigen IAM-Berechtigungen versehen ist.

Die Konfiguration in PyIceberg (rest.sigv4-enabled: true) aktiviert genau diese Signierung. Ohne sie scheitern direkte API-Aufrufe mit Fehlern wie AccessDenied oder SignatureDoesNotMatch. Praktisch bedeutet das:

Manuelles Signieren von Anfragen ist aufwendig und fehleranfällig.
awscurl bietet hier eine elegante Lösung, indem es SigV4-Signaturen automatisch generiert und Anfragen versendet.

Nach der Installation kann awscurl direkt genutzt werden:

pip install awscurl

Der entscheidende Parameter ist --service, der je nach Endpunkt gesetzt werden muss:

glue für den Glue Iceberg REST Catalog
s3tables für den S3 Tables Iceberg REST Catalog

Ein Beispielaufruf für den S3-Tables-Endpunkt:

awscurl \
  --service s3tables \
  --region ap-northeast-1 \
  "

Wichtig: Die Tabellenspeicher-ARN darf nicht vorcodiert werden. awscurl codiert den Parameter bereits im Rahmen der Signaturberechnung – eine doppelte Codierung führt zu SignatureDoesNotMatch-Fehlern.

Fazit: Welcher Catalog passt zu welchem Anwendungsfall?

Die Entscheidung zwischen Glue und S3 Tables hängt maßgeblich vom Einsatzszenario ab. Wer bereits mit hierarchischen Katalogen arbeitet und auf Lake Formation setzt, profitiert von der Flexibilität des Glue Iceberg REST Catalogs. Dieser eignet sich besonders für Umgebungen mit mehreren Datenquellen und komplexen Zugriffssteuerungen.

Der S3 Tables Iceberg REST Catalog hingegen bietet eine schlankere Lösung für Projekte, die auf einzelne Tabellenspeicher optimiert sind. Hier entfällt die Verwaltung von Katalogen zugunsten einer direkten 1:1-Beziehung zwischen Tabellenmetadata und Speicherort. Diese Architektur vereinfacht die Einrichtung und Wartung, erfordert aber eine strikte Trennung der Daten in dedizierten Buckets.

Langfristig wird die Wahl des Catalogs auch von der Entwicklung der AWS-Dienste abhängen. Beide Implementierungen nutzen dieselbe Iceberg-REST-Spezifikation – doch ihre unterschiedlichen Designansätze spiegeln die vielfältigen Anforderungen moderner Datenarchitekturen wider. Entwickler sollten daher nicht nur die technischen Spezifikationen, sondern auch die langfristige Wartbarkeit und Skalierbarkeit ihrer Lösung im Blick behalten.

KI-Zusammenfassung

Compare AWS Glue and S3 Tables Iceberg REST Catalog endpoints to understand their distinct design, API behavior, and access control models.