AWS ergänzt S3 Tables um verwaltete Migration von Hive zu Iceberg: Startumfang sind in Glue registrierte Parquet-Tabellen im selben Konto und derselben Region, zehn Regionen, Ziel bis zum Abschluss schreibgeschützt

Am 4. November 2026 kündigte AWS die verwaltete Migration von Apache-Hive-Tabellen nach Apache Iceberg in Amazon S3 Tables an. Der What’s-New-Beitrag und der Einführungsartikel im AWS News Blog beschreiben sie als API-gesteuerten Vorgang: S3 Tables prüfen die Quelle, wandeln Datentypen um, kopieren die Daten, komprimieren sie neu und fassen kleine Dateien zusammen, während die Produktionslasten weiterlaufen. AWS sagt, der Wechsel von Hive zu Iceberg habe früher Wochen an Entwicklungsarbeit gekostet, weil jede Tabelle eine eigene Migrationspipeline brauchte. Diese Dauer ist eine Aussage von AWS, und die Beiträge liefern keine Messung dazu.

Der Startumfang ist eng und sollte zuerst gelesen werden. Zum Start unterstützt die Funktion in AWS Glue registrierte Hive-Tabellen im Parquet-Format innerhalb desselben AWS-Kontos und derselben Region. Sie ist in zehn Regionen verfügbar: USA Ost (Nord-Virginia, Ohio), USA West (Oregon), Asien-Pazifik (Mumbai, Singapur, Sydney, Tokio) und Europa (Frankfurt, Irland, Stockholm). Hive-Tabellen in anderen Formaten, in einem anderen Konto oder in einer Region außerhalb dieser Liste liegen außerhalb des genannten Umfangs. Wann sich das ändert, sagen die Beiträge nicht.

Der Ablauf hat drei Schritte: Start, Synchronisierung und Abschluss. Beim Start ermitteln S3 Tables alle betroffenen Quellobjekte und erstellen Kompatibilitätsberichte, bevor Daten kopiert werden. Standardmäßig läuft der Auftrag nach der Planung automatisch weiter; ein Prüfmerker hält ihn an, damit die Berichte zuerst gelesen werden können. Das Ziel ist eine neue Iceberg-Tabelle in einem Tabellen-Bucket, mit empfohlenen Standardwerten angelegt und während der Migration schreibgeschützt. Die Synchronisierung lässt sich beliebig oft aufrufen, und jede kopiert nur die Änderungen. Beim Abschluss wird die Zieltabelle auf Lesen und Schreiben hochgestuft. Athena und Amazon SageMaker Unified Studio sind in der Konsole direkt eingebunden, und jede Engine, die die Iceberg-REST-API spricht, kann das Ergebnis abfragen.

Die Quellen beschreiben nicht ganz gleich, wie stark die Quelltabelle gestört wird. Das Entwicklerhandbuch sagt, die Quelltabelle bleibe während eines Migrationsauftrags unverändert und voll lesbar und schreibbar. Der Einführungsblog sagt, man könne beliebig oft synchronisieren, ohne Schreibvorgänge auf die Quelle zu stoppen, außer für einige Minuten beim Umschalten. Das widerspricht sich nicht, ist aber auch nicht identisch: Die Dokumentation spricht vom Auftrag, der Blog vom abschließenden Umschalten. Teams, die selbst eine kurze Schreibpause beim Umschalten nicht hinnehmen können, sollten diesen Schritt einplanen und nicht von null Ausfallzeit ausgehen. Die Beiträge sagen auch, man könne auf die Quelldaten zurückgehen, was zur Aussage der Dokumentation passt, dass die Quelle unversehrt bleibt.

Die Behandlung von Typen und Schema ist ausdrücklich. Die Migration bildet das Hive-Schema und die Partitionierung auf ein Iceberg-Schema und eine Partitionsspezifikation ab; man kann ein Zielschema angeben oder aus dem Glue-Schema ein kompatibles erzeugen lassen. Eine Migrationsrichtlinie bestimmt, was bei Abweichungen geschieht, und das Beispiel im Blog setzt sowohl die Richtlinie für nicht zugeordnete Felder als auch die für inkompatible Werte auf „fail“. Das ist ein Beispielwert in einer Musteranfrage, kein genannter Standardwert. Die Musteranfrage zeigt auch einstellbare Wartungsparameter: Kompaktierung mit einer Zieldateigröße von 512 MB und eine Snapshot-Verwaltung, die mindestens drei Snapshots behält und sie nach 168 Stunden ablaufen lässt. Nach dem Kopieren liefert ein Objektmigrationsbericht das Ergebnis für jedes Quellobjekt.

Die Kosten werden qualitativ beschrieben. Man zahlt nur für die vom Auftrag kopierten Daten, die Umwandlung von Hive nach Iceberg selbst kostet nichts, und Quellobjekte in S3 Intelligent-Tiering bleiben in ihrer aktuellen Zugriffsstufe und behalten ihren Zähler der Tage seit dem letzten Zugriff. Keine Gebühr für die Umwandlung heißt nicht, dass die Migration kostenlos ist: Kopierte Daten werden zu S3-Preisen abgerechnet, und die Beiträge verweisen auf die S3-Preisseite, ohne einen Preis pro Gigabyte zu nennen. Nutzen Tabellen Snappy-Kompression, komprimiert S3 Tables sie auf Zstandard um und kompaktiert sie, was laut AWS Speicher und Objektzahl senkt und die Abfrageleistung verbessert; Zahlen davor und danach nennt AWS nicht.

Agenten gehören zum Angebot. Ein Migrations-Skill im Agent Toolkit for AWS lässt einen Coding-Agenten wie Kiro vorhandene IAM-Richtlinien analysieren und gleichwertige Zielrichtlinien empfehlen, den Plan prüfen, die Aufrufe für Start, Synchronisierung und Abschluss ausführen und den Fortschritt überwachen, mit Sicherheitsleitplanken. Der Skill ist eine Anleitung für einen Agenten, der dieselben APIs aufruft, keine andere Migrationsengine.

Unsere Einschätzung: Die Funktion erspart den Bau einer Pipeline, und die genannten Grenzen entscheiden, ob sie für Sie passt. Prüfen Sie vier Dinge, bevor Sie sich darauf verlassen: Die Tabelle ist in Glue registriert, die Daten liegen als Parquet vor, Quelle und Ziel liegen im selben Konto und in derselben Region, und die Region steht auf der Liste. Planen Sie dann das Umschaltfenster, lesen Sie bei ungewöhnlichen Typen im Schema die Kompatibilitätsberichte vor dem Kopieren und schätzen Sie die Kopierkosten anhand Ihres Datenvolumens. Weil das Ziel während der Migration schreibgeschützt ist, kann die neue Tabelle erst nach dem Abschluss Schreibvorgänge annehmen.