- AWS ermöglicht es Aurora PostgreSQL nun, Apache Iceberg- und Apache Parquet-Daten aus S3 und S3 Tables zu lesen, ohne sie vorher in die Datenbank laden zu müssen.
- Die Funktion nutzt eine eingebettete DuckDB-Engine, die aurora_analytics-Erweiterung und eine IAM-Rolle mit Zugriff auf S3 und AWS Glue.
- Unterstützt werden die Versionen Aurora PostgreSQL 17.11 und höher sowie Aurora PostgreSQL 18.6 und höher, sowohl in kommerziellen als auch in GovCloud-Regionen.
- Teams können Live-Transaktionszeilen mit Lakehouse-Daten verknüpfen, Ergebnisse zwischenspeichern und häufig genutzte Datensätze für Lesezugriffe mit geringer Latenz materialisieren.
Amazon Web Services hat einen neuen Weg für Aurora PostgreSQL- Cluster eröffnet , die Anwendungsdatensätze aus dem täglichen Gebrauch mit Daten aus einem Data Lake verknüpfen müssen. Die verwaltete Datenbank kann nun Apache Iceberg-Tabellen und Apache Parquet-Dateien lesen, ohne diese vorher in Aurora kopieren zu müssen. So kann eine einzige SQL-Anweisung sowohl aktuelle operative Datensätze als auch archivierte Informationen abdecken. Diese Neuerung richtet sich an Teams, die es leid sind, ETL-Prozesse (Extract, Transform, Load) zu erstellen und zu überwachen, nur um Fragen zu beantworten, die aktuelle und historische Daten miteinander verknüpfen.
Anstatt den Data Lake als separate Umgebung zu behandeln, ermöglicht der Dienst bestehenden PostgreSQL-Clients, -Tools und -Endpunkten den Zugriff auf die Inhalte des Data Lakes über Fremdtabellen. Dadurch entfällt die Notwendigkeit, eine Kopie des historischen Datensatzes in der operativen Datenbank zu speichern, und Anwendungsentwickler können weiterhin die gewohnte Syntax verwenden. AWS positioniert dies als Möglichkeit, den Wartungsaufwand für Pipelines zu reduzieren, die Infrastrukturausweitung einzudämmen und die Anreicherung von Transaktionen mit älteren Kontextdaten zu vereinfachen.
Welche Änderungen die neue Aurora PostgreSQL-Funktionalität mit sich bringt
Diese Funktion ist kein separates Analyseprodukt, das Kunden separat einrichten müssen. Sie wird über die Erweiterung „aurora_analytics“ und eine AWS Identity and Access Management-Rolle aktiviert, die dem Cluster die Berechtigung für den Zugriff auf Amazon S3 und den AWS Glue Data Catalog erteilt. Sobald diese Rolle und die Erweiterung eingerichtet sind, erstellen Administratoren externe Tabellen, die auf Iceberg- oder Parquet-Daten verweisen, und können diese ähnlich wie gewöhnliche PostgreSQL-Tabellen abfragen.
Ein wesentlicher Bestandteil der Architektur ist die direkte Einbettung von DuckDB in Aurora . Die Open-Source-Analyse-Engine führt Scans der Lakehouse-Dateien durch, während Aurora weiterhin den operativen Betrieb aufrechterhält. Die Abfrageverarbeitung findet innerhalb der Datenbankumgebung statt, wodurch die Auslagerung auf einen separaten Cluster vermieden und Latenz sowie Netzwerk-Overhead minimiert werden.
Zu den unterstützten Datenquellen gehören Iceberg-Tabellen, die im AWS Glue Data Catalog registriert sind, Parquet- und Iceberg-Objekte in Amazon S3 sowie Daten in S3-Tabellen. Externe Kataloge, die der Iceberg REST Catalog-Schnittstelle folgen , können ebenfalls über die Federation mit Glue erreicht werden, sodass Teams ihre bestehenden Kataloginvestitionen nicht aufgeben müssen. Eine Abfrage kann Zeilen aus Aurora mit Iceberg-Tabellen aus verschiedenen Katalogen verknüpfen und Anwendungen so eine einheitliche Ansicht ermöglichen, ohne dass Dateien verschoben werden müssen.
Versionen, Einrichtung und unterstützte Dienste
Unterstützt werden Aurora PostgreSQL 17 ab Version 17.11 und Aurora PostgreSQL 18 ab Version 18.6. Nach dem Erstellen oder Auswählen eines Clusters ordnet ein Administrator eine IAM-Rolle mit der AuroraAnalytics-Funktion zu und aktiviert die Erweiterung. Die Einrichtung kann über die Amazon RDS-Konsole oder einen PostgreSQL-Client wie psql erfolgen.
Fremdtabellendefinitionen können einzeln erstellt werden. In größeren Umgebungen lässt sich jedoch mit `IMPORT FOREIGN SCHEMA` ein Großteil der Fremdtabellen in einem Schritt aus einer AWS Glue Data Catalog-Datenbank generieren. Bei Parquet-Dateien kann Aurora das Schema aus den Dateimetadaten lesen, wodurch die manuelle Angabe jeder einzelnen Spalte entfällt. Dies ist besonders wichtig für Teams mit umfangreichen oder sich häufig ändernden Datensätzen.
Leseabfragen können auf der Schreibinstanz oder einem Lesereplikat ausgeführt werden, sodass analytische Scans von der primären Betriebslast entkoppelt werden können. Befehle, die Daten in Aurora schreiben, wie z. B. `CREATE TABLE AS SELECT`, `INSERT INTO … SELECT` oder `MERGE INTO`, werden auf der Schreibinstanz ausgeführt . Dies ermöglicht es Teams, dringend benötigte Daten aus dem Lakehouse in eine native Tabelle zu übertragen, wenn sie konstant schnelle Antworten benötigen.
Um die Funktionsweise einer Abfrage zu überprüfen, können Administratoren `aurora_analytics_stat_statements()` aufrufen. Die Funktion liefert Metriken wie gescannte Zeilen, gelesene Bytes aus Amazon S3 und Cache-Treffer . Häufig verwendete Daten werden auf der Aurora-Instanz zwischengespeichert, sodass wiederholte Zugriffe auf dieselben Lakehouse-Objekte schneller erfolgen, ohne dass dieselben Bytes wiederholt aus dem Objektspeicher abgerufen werden müssen.
Leistung, Caching und Pfade mit geringer Latenz
Aurora verwendet Prädikat-Pushdown und Spaltenbereinigung , wodurch nur relevante Zeilen und Spalten aus dem Data Lake angefordert werden. Mit zunehmender Größe des zugrunde liegenden Datensatzes verhindert diese Filterung, dass Abfragen zu vollständigen Scans führen. Die zwischengespeicherten Ergebnisse und Abfragestatistiken bieten den Betreibern eine praktische Möglichkeit, die Arbeitslast zu optimieren, anstatt nur zu raten, wo Zeit verbraucht wird.
Für Anwendungen, die Latenzzeiten im einstelligen Millisekundenbereich erfordern, bietet AWS die Materialisierung als Lösung an. Ausgewählte Datensätze aus dem Data Lake lassen sich mit bekannten SQL-Befehlen in eine native Aurora-PostgreSQL-Tabelle kopieren und anschließend wie jede andere lokale Tabelle abfragen. Dadurch wird ein schneller Zugriff auf die wichtigsten Daten gewährleistet, während der gesamte Data Lake für umfassendere Analysen weiterhin zur Verfügung steht.
Das Unternehmen nennt Echtzeit-Dashboards, Transaktionen mit historischem Kontext und KI-Systeme, die sowohl aktuelle als auch archivierte Datensätze analysieren müssen, als typische Anwendungsfälle. Gemeinsamer Nenner ist eine Arbeitslast, die nicht auf einen nächtlichen Batch-Prozess oder einen Reverse-ETL-Job warten kann. Indem AWS es einer Anwendung ermöglicht, sowohl aktuelle als auch ältere Informationen aus einer einzigen Datenbank abzufragen, soll eine wiederkehrende Quelle für Pipeline-Komplexität beseitigt werden.
Verfügbarkeit und Preisgestaltung
Laut AWS ist diese Funktion in allen kommerziellen AWS-Regionen und AWS GovCloud (US)-Regionen verfügbar. Es fallen keine separaten Gebühren an. Kunden zahlen weiterhin für die zusätzliche Aurora-Rechenleistung, die durch Abfragen verbraucht wird, sowie für die Amazon S3-Anfragekosten zum Lesen von Data-Lake-Dateien. Dieses Preismodell hält den Einstieg günstig, obwohl bei intensiver analytischer Nutzung weiterhin Kosten anfallen.
AWS hat die Einführung als Teil einer umfassenderen Initiative dargestellt, die Leistungsfähigkeit von DuckDB in seine Managed Services zu integrieren. Das DuckLabs-Team, das das DuckDB-Projekt betreut, ist Amazon beigetreten, und das Unternehmen erklärt, dass zukünftige Verbesserungen der Open-Source-Engine in Aurora und andere AWS-Angebote einfließen können. Diese Verbindung deutet darauf hin, dass die Integration als fortlaufende Weiterentwicklung und nicht als einmalige Funktion gedacht ist.
Für Datenbankteams liegt der praktische Vorteil auf der Hand: weniger bewegliche Teile, weniger Datenredundanz und ein kürzerer Weg von der Frage zur Antwort. Der Nachteil besteht darin, dass Zugriffskontrollen, IAM-Berechtigungen und die Katalogkonfiguration weiterhin sorgfältig gehandhabt werden müssen. Ein Cluster, der sowohl Produktionsdatensätze als auch Archivdateien einsehen kann, wird zu einer leistungsstarken, einheitlichen Abfrageoberfläche , weshalb die Governance weiterhin Teil der Aufgabe bleibt.
Der praktische Effekt ist eine engere Verbindung zwischen Aurora PostgreSQL und dem Data Lake. Aktuelle Transaktionen und historische Dateien können in einer einzigen SQL-Abfrage zusammengeführt werden, DuckDB übernimmt den analytischen Scan, und die Materialisierung bietet bei Bedarf einen schnellen Zugriff. Teams, die bereits in PostgreSQL-Tools investiert haben, erhalten eine weitere Option für analyseintensive Workloads. Unternehmen mit strengen Sicherheits- oder Kostenvorgaben sollten hingegen Berechtigungen, Caching-Verhalten und die S3-Nutzung vor einer breiten Einführung überprüfen.
