AWS hat die Möglichkeit angekündigt, in einem Data Lake gespeicherte Apache-Iceberg- und Apache-Parquet-Daten direkt neben den Betriebsdaten in Amazon Aurora PostgreSQL abzufragen. Die neue Funktion ermöglicht es Anwendungen, aktuelle und historische Datensätze in einer einzigen Abfrage mit PostgreSQL-Syntax und vorhandenen Tools zu kombinieren, ohne die Daten über ETL-Pipelines in die Datenbank zu kopieren.
Was hat sich praktisch geändert?
Die Funktion basiert auf der direkt in Aurora PostgreSQL eingebetteten DuckDB-Engine. Dadurch kann eine einzige Abfrage Betriebsdaten lesen, einschließlich noch nicht festgeschriebener Schreibvorgänge, sowie Iceberg-Tabellen oder Parquet-Dateien aus Amazon S3. AWS Glue Data Catalog sowie Amazon S3 und S3 Tables werden ebenfalls unterstützt, außerdem Iceberg-kompatible Kataloge des Iceberg REST Catalog über den Federation-Mechanismus in Glue.
Der Benutzer muss einen Aurora-PostgreSQL-Cluster erstellen, eine IAM-Rolle anhängen, die die Funktion AuroraAnalytics umfasst, und anschließend die Erweiterung aurora_analytics aktivieren. Danach können Foreign Tables erstellt werden, die auf die externen Daten verweisen, oder IMPORT FOREIGN SCHEMA verwendet werden, um mehrere Tabellen automatisch zu erstellen und das Datenschema aus den Metadaten abzuleiten.
Warum ist diese Nachricht wichtig?
Anwendungen, die aktuelle Transaktionen in Aurora mit historischen Datensätzen in S3 kombinieren, mussten die Daten bisher üblicherweise über Reverse ETL kopieren, was zusätzliche Synchronisationsprozesse, Betriebskosten und technische Komplexität verursacht. Nun kann diese Kombination während der Abfrage selbst erfolgen. Das ist hilfreich für Dashboards, die historischen Kontext benötigen, für Anwendungen, die eine Transaktion mit einem früheren Datensatz verknüpfen, und für Systeme, deren Daten auf eine Betriebsdatenbank und einen Data Lake verteilt sind.
Dieser Aspekt gewinnt bei Anwendungen mit KI-Agenten zusätzlich an Bedeutung, da sich im Voraus nur schwer vorhersagen lässt, welche Datensätze der Agent möglicherweise benötigt, und diese in eine Betriebsdatenbank kopiert werden müssten. Der direkte Zugriff ermöglicht es, den Umfang der verfügbaren Daten zu erweitern, ohne für jeden Anwendungsfall eine Kopie zu erstellen.
Leistung und Zugriffsoptionen
Aurora wendet Optimierungen wie das Übertragen von Filtern an die Datenquelle und die Reduzierung der gelesenen Spalten an. Außerdem werden häufig verwendete Daten vorübergehend innerhalb der Aurora-Instance gespeichert. Das Verhalten jeder Abfrage kann über die Funktion aurora_analytics_stat_statements() überprüft werden, die unter anderem die Anzahl der geprüften Zeilen, die aus S3 gelesene Datenmenge und die Häufigkeit der Nutzung des Caches anzeigt.
Die Abfragen sind auf den verschiedenen Aurora-Instances innerhalb des Clusters verfügbar, einschließlich der Writer-Instance und der Read Replicas. Dadurch können analytische Scanvorgänge vom operativen Workload getrennt werden. Wenn Antwortzeiten im Bereich von Bruchteilen einer Millisekunde erforderlich sind, können die Daten hingegen mithilfe von CREATE TABLE AS SELECT, INSERT INTO ... SELECT oder MERGE INTO in einer nativen Aurora-Tabelle materialisiert werden. Die aus der Materialisierung resultierenden Schreibvorgänge werden auf der Writer-Instance ausgeführt.
Verfügbarkeit und Kosten
Die Funktion unterstützt Aurora PostgreSQL 17 ab Version 17.11 und Version 18 ab 18.6. Sie ist in allen kommerziellen AWS-Regionen sowie den AWS-GovCloud-(US)-Regionen verfügbar, ohne zusätzliche Gebühr für die Funktion selbst. Die Kosten hängen weiterhin von der zusätzlichen Aurora-Rechenleistung ab, die von den Abfragen verbraucht wird, sowie von den Gebühren für Amazon-S3-Anfragen zum Lesen von Data-Lake-Dateien.
Lesart von certi.news: Die grundlegende Änderung besteht nicht in der Einführung eines neuen Speicherformats, sondern in der Verringerung der Distanz zwischen der operativen Datenbank und dem Data Lake. Das hebt jedoch die Überlegungen zur Workload-Gestaltung nicht auf: Direkte Abfragen eignen sich für den flexiblen Datenzugriff, während eine Materialisierung weiterhin erforderlich sein kann, wenn extrem niedrige Antwortzeiten Priorität haben. Auch der Verbrauch von Aurora-Rechenleistung und S3-Anfragen bleibt ein Faktor, der je nach Abfragemuster und Datenvolumen gemessen werden muss.