- AWS nyní umožňuje Auroře PostgreSQL číst data Apache Iceberg a Apache Parquet z S3 a tabulek S3 bez jejich předchozího načítání do databáze.
- Tato funkce využívá vestavěný engine DuckDB, rozšíření aurora_analytics a roli IAM s přístupem k S3 a AWS Glue.
- Podporované verze jsou Aurora PostgreSQL 17.11 a novější, plus Aurora PostgreSQL 18.6 a novější, a to v komerčních regionech a regionech GovCloud.
- Týmy mohou spojovat živé transakční řádky s daty z Lakehouse, ukládat výsledky do mezipaměti a materializovat aktivní datové sady pro čtení s nízkou latencí.
Služba Amazon Web Services otevřela novou cestu pro clustery Aurora PostgreSQL , které potřebují kombinovat každodenní záznamy aplikací se soubory uloženými v datovém jezeře. Spravovaná databáze nyní dokáže číst tabulky Apache Iceberg a soubory Apache Parquet, aniž by je musela nejprve kopírovat do Aurory, takže jeden příkaz SQL může pokrýt jak živé provozní řádky, tak archivované informace. Tento krok je zaměřen na týmy, které už unavuje vytvářet a hlídat úlohy extrakce, transformace a načítání jen proto, aby odpověděly na otázky, které se kříží s aktuálními i historickými daty.
Místo toho, aby se s datovým jezerem zacházelo jako se samostatným světem, umožňuje tato služba stávajícím klientům, nástrojům a koncovým bodům PostgreSQL přístup k obsahu datového jezera prostřednictvím cizích tabulek. To znamená, že v provozní databázi nemusí být uložena žádná duplicitní kopie historické datové sady a vývojáři aplikací mohou nadále používat syntaxi, kterou již znají. AWS to prezentuje jako způsob, jak snížit údržbu datových kanálů, omezit rozrůstání infrastruktury a usnadnit obohacení transakcí o starší kontext.
Co se mění s novými funkcemi Aurora PostgreSQL
Tato funkce není samostatným analytickým produktem, který by si zákazníci museli ověřit jinde. Je aktivována prostřednictvím rozšíření aurora_analytics a role AWS Identity and Access Management, která clusteru dává oprávnění k přístupu k Amazon S3 a katalogu dat AWS Glue. Jakmile je tato role a rozšíření nainstalováno, administrátoři vytvářejí cizí tabulky, které odkazují na data Iceberg nebo Parquet, a dotazují se na ně podobně jako na běžné tabulky PostgreSQL.
Pozoruhodnou součástí architektury je, že DuckDB je integrována přímo do Aurory . Open-source analytický engine zpracovává skenování souborů Lakehouse, zatímco Aurora nadále obsluhuje provozní úlohy. Zpracování dotazů zůstává v databázovém prostředí, což zabraňuje předávání úlohy samostatnému clusteru a pomáhá udržovat latenci a síťové režijní náklady pod kontrolou.
Mezi podporované zdroje patří tabulky Iceberg registrované v katalogu dat AWS Glue, objekty Parquet a Iceberg v Amazon S3 a data uložená v tabulkách S3. Externí katalogy, které sledují rozhraní Iceberg REST Catalog, lze také přistupovat prostřednictvím federace s Glue, takže týmy nemusí opustit investice do katalogů, které již mají. Dotaz může spojit řádky z Aurory s tabulkami Iceberg rozloženými napříč více katalogy, což aplikacím poskytuje jednotný pohled bez nutnosti přesouvání souborů.
Verze, nastavení a podporované služby
Podporované verze jsou Aurora PostgreSQL 17 počínaje verzí 17.11 a Aurora PostgreSQL 18 počínaje verzí 18.6. Po vytvoření nebo výběru clusteru administrátor připojí roli IAM s funkcí AuroraAnalytics a zapne rozšíření. Nastavení lze provést prostřednictvím konzole Amazon RDS nebo klienta PostgreSQL, jako je psql.
Definice cizích tabulek lze vytvářet jednu po druhé, ale větší prostředí mohou použít příkaz IMPORT FOREIGN SCHEMA k vygenerování mnoha cizích tabulek v jednom kroku z databáze AWS Glue Data Catalog. U souborů Parquet dokáže Aurora číst schéma z metadat souboru, což eliminuje nutnost ručně vypisovat každý sloupec. Tento detail je důležitý pro týmy s rozsáhlými nebo často se měnícími datovými sadami.
Dotazy na čtení mohou běžet na instanci zapisovače nebo na replice pro čtení, takže analytické skenování lze přesunout mimo primární provozní zátěž. Příkazy, které zapisují data do Aurory, jako například CREATE TABLE AS SELECT, INSERT INTO … SELECT nebo MERGE INTO, se běží na instanci zapisovače . To dává týmům způsob, jak materializovat horká data z Lakehouse do nativní tabulky, když potřebují konzistentně rychlé odezvy.
Aby administrátoři zjistili, co dotaz dělá, mohou zavolat funkci aurora_analytics_stat_statements(). Funkce hlásí metriky, jako jsou naskenované řádky, bajty přečtené z Amazon S3 a zásahy do mezipaměti . Často používaná data jsou uložena v mezipaměti instance Aurora, takže opakovaný přístup ke stejným objektům Lakehouse se může vrátit rychleji, aniž by se muselo opakovaně stahovat stejné bajty z úložiště objektů.
Výkon, ukládání do mezipaměti a cesty s nízkou latencí
Aurora používá odkládání predikátů dolů a prořezávání sloupců , což znamená, že z datového jezera jsou vyžadovány pouze relevantní řádky a sloupce. S růstem podkladové datové sady toto filtrování pomáhá zabránit tomu, aby se dotazy proměnily v úplné prohledávání. Výsledky uložené v mezipaměti a statistiky dotazů poskytují operátorům praktický způsob, jak ladit pracovní zátěž, místo aby hádali, kde se tráví čas.
Pro aplikace, které vyžadují latenci v řádu jednotek milisekund, AWS poukazuje na materializaci jako na únikové řešení. Vybrané záznamy datového jezera lze zkopírovat do nativní tabulky Aurora PostgreSQL pomocí známých SQL příkazů, načež se na ně dotazuje jako na jakoukoli jinou lokální tabulku. Tím se zachovává rychlá cesta k nejžhavějším datům a zároveň se celé datové jezero stále zpřístupňuje pro širší analýzu.
Společnost uvádí jako typické případy použití dashboardy v reálném čase, transakce obohacené o historický kontext a agenty umělé inteligence, kteří potřebují uvažovat o aktuálních i archivovaných záznamech. Společným rysem je pracovní zátěž, která nemůže čekat na noční dávku nebo reverzní úlohu ETL. Tím, že AWS umožňuje aplikaci požadovat od jedné databáze aktuální i staré informace, doufá, že odstraní opakující se zdroj složitosti procesů.
Dostupnost a ceny
Tato funkce je dostupná ve všech komerčních regionech AWS a regionech AWS GovCloud (USA) podle AWS. Neexistuje žádný samostatný poplatek za funkci. Zákazníci stále platí za dodatečné výpočetní prostředky Aurory, které dotazy spotřebovávají, a za náklady na požadavky Amazon S3 spojené s čtením souborů datového jezera. Tento cenový model udržuje vstupní bod nízký, i když se na účtu stále projeví intenzivní analytické využití.
Společnost AWS toto spuštění chápe jako součást širšího úsilí o zavedení výkonu DuckDB do svých spravovaných služeb. Tým DuckLabs, který projekt DuckDB spravuje, se připojil k Amazonu a společnost tvrdí, že budoucí vylepšení open-source enginu se mohou promítnout do Aurory a dalších nabídek AWS. Toto spojení naznačuje, že integrace se má spíše vyvíjet, než aby zůstala jednorázovou funkcí.
Pro databázové týmy je praktická výhoda známá: méně pohyblivých částí, méně duplicitních dat a kratší cesta od otázky k odpovědi. Nevýhodou je, že s řízením přístupu, oprávněními IAM a konfigurací katalogu je stále třeba zacházet opatrně. Cluster, který může vidět produkční řádky i soubory Lakehouse, se stává výkonnou jednotnou dotazovací plochou , takže správa zůstává součástí úkolu.
Praktickým efektem je užší propojení mezi Aurora PostgreSQL a datovým jezerem. Aktuální transakce a historické soubory se mohou setkat v jednom SQL dotazu, DuckDB se postará o analytické skenování a materializace nabízí rychlý přístup v případě potřeby. Týmy, které již investovaly do nástrojů PostgreSQL, získají další možnost pro úlohy s vysokou analytickou náročností, zatímco ty s přísnými bezpečnostními nebo nákladovými kontrolami budou chtít před jejich širokým zavedením zkontrolovat oprávnění, chování při ukládání do mezipaměti a využití S3.
