GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.
Aurora PostgreSQL kann jetzt operative Daten zusammen mit Daten, die in Ihrem Data Lake in den Formaten Apache Iceberg und Apache Parquet gespeichert sind, direkt abfragen – und das mit Ihren vorhandenen PostgreSQL-Anwendungen und -Tools. Durch die Eliminierung der Notwendigkeit, strukturierte Daten aus Data Lakes zu extrahieren, transformieren und laden (ETL) zu müssen, reduzieren Sie die operative Komplexität und vereinfachen die Anwendungsentwicklung.
Aurora kann auch Data Lakes abfragen, die in Iceberg REST Catalog (IRC)-kompatiblen Katalogen verwaltet werden – Zugriff auf eine breite Palette von Analysesystemen, ohne Daten zu verschieben oder zu duplizieren. Ob Sie Echtzeit-Dashboards betreiben, Transaktionen mit historischem Kontext anreichern oder KI-Agenten entwickeln, die über Live- und Archivdaten nachdenken – alles geschieht über eine einzige, vertraute Schnittstelle.
Bisher bedeutete die Kombination aktueller Transaktionsdaten in Aurora mit historischen Aufzeichnungen in S3 den Aufbau von Reverse-ETL-Pipelines, die Daten duplizierten, Infrastrukturkosten erhöhten und laufende Engineering-Arbeit erforderten, um alles synchron zu halten. Diese Belastung wächst, wenn Sie KI-Agenten in Anwendungen einbetten – Sie können nicht vorhersagen und vorab replizieren, welche Datensätze ein Agent möglicherweise benötigt.
Das Team hinter DuckDB (DuckLabs) ist kürzlich Amazon beigetreten, und diese Funktion ist die erste sichtbare Integration: DuckDB ist jetzt direkt in Aurora PostgreSQL eingebettet. Sie können live operative Daten – einschließlich nicht committeter Schreibvorgänge – zusammen mit Ihrem Data Lake in einer einzigen Abfrage abfragen. Die Abfrageverarbeitung bleibt innerhalb von Aurora: keine zusätzlichen Netzwerk-Hops, keine ETL-Duplizierung.
Sie fragen Iceberg-Tabellen ab, die über den AWS Glue Data Catalog verwaltet werden, sowie Parquet- und Iceberg-Daten in Amazon S3 und S3 Tables – alles mit vertrauter PostgreSQL-Syntax und vorhandenen Anwendungen und Tools. Da die Funktion auf DuckDB basiert, fließen zukünftige Verbesserungen der Open-Source-Engine weiterhin in Aurora und andere AWS-Services ein.
Dies eliminiert das Reverse-ETL-Muster für eine ganze Klasse von Workloads. Wenn Ihre Anwendungen – oder Ihre KI-Agenten – frische Transaktionsdaten mit historischen Lake-Daten kombinieren müssen, können sie dies jetzt in einer einzigen PostgreSQL-Abfrage mit null Duplizierung tun. Der DuckDB-in-Aurora-Ansatz ist eine wirklich interessante architektonische Richtung, die es zu beobachten lohnt.