AWS объявила о добавлении возможности напрямую запрашивать данные Apache Iceberg и Apache Parquet, хранящиеся в озере данных, наряду с операционными данными в Amazon Aurora PostgreSQL. Новая возможность позволяет приложениям объединять свежие и исторические записи в одном запросе с использованием синтаксиса PostgreSQL и существующих инструментов, без копирования данных в базу данных через ETL-конвейеры.
Что изменилось на практике?
Функция основана на движке DuckDB, непосредственно встроенном в Aurora PostgreSQL. Благодаря этому один запрос может читать операционные данные, включая незакоммиченные записи, а также таблицы Iceberg или файлы Parquet из Amazon S3. Кроме того, поддерживаются AWS Glue Data Catalog, Amazon S3 и S3 Tables, а также каталоги, совместимые с Iceberg REST Catalog, через механизм federation в Glue.
Пользователю необходимо создать кластер Aurora PostgreSQL, прикрепить роль IAM, включающую возможность AuroraAnalytics, а затем активировать расширение aurora_analytics. После этого можно создавать foreign tables, указывающие на внешние данные, или использовать IMPORT FOREIGN SCHEMA для автоматического создания нескольких таблиц с определением схемы данных по метаданным.
Почему эта новость важна?
Ранее приложениям, объединяющим современные транзакции в Aurora с историческими записями в S3, обычно требовалось копировать данные посредством reverse ETL, что добавляло процессы синхронизации, эксплуатационные расходы и инженерную сложность. Теперь такое объединение можно выполнять непосредственно во время запроса. Это полезно для информационных панелей, которым необходим исторический контекст, приложений, связывающих транзакцию с предыдущей записью, и систем, работающих с данными, распределёнными между операционной базой данных и озером данных.
Этот аспект приобретает дополнительное значение в приложениях, использующих агентов искусственного интеллекта, поскольку заранее трудно предсказать, какой набор данных может понадобиться агенту, и скопировать его в операционную базу данных. Прямой доступ позволяет расширить диапазон доступных данных без создания отдельной копии для каждого варианта использования.
Производительность и варианты доступа
Aurora применяет такие оптимизации, как передача фильтров источнику данных и сокращение числа считываемых столбцов, а также временно хранит часто используемые данные внутри экземпляра Aurora. Поведение каждого запроса можно проверить с помощью функции aurora_analytics_stat_statements(), которая показывает, в частности, количество проверенных строк, объём данных, прочитанных из S3, и количество обращений к кэшу.
Запросы доступны на разных экземплярах Aurora внутри кластера, включая экземпляр-источник и реплики, предназначенные для чтения, что позволяет направлять аналитические операции сканирования отдельно от операционной нагрузки. Для случаев, требующих времени выполнения порядка долей миллисекунды, данные можно материализовать в собственной таблице Aurora с помощью CREATE TABLE AS SELECT, INSERT INTO ... SELECT или MERGE INTO. Операции записи, возникающие в результате материализации, выполняются на экземпляре-источнике.
Доступность и стоимость
Возможность поддерживается в версиях Aurora PostgreSQL 17 начиная с 17.11 и 18 начиная с 18.6. Она доступна во всех коммерческих регионах AWS и регионах AWS GovCloud (US), без дополнительной платы за саму функцию. При этом стоимость по-прежнему связана с дополнительными вычислительными ресурсами Aurora, которые потребляют запросы, а также с платой за запросы Amazon S3 при чтении файлов озера данных.
Чтение certi.news: Основное изменение заключается не в добавлении нового формата хранения, а в сокращении расстояния между операционной базой данных и озером данных. Однако это не отменяет необходимости учитывать особенности проектирования нагрузок: прямые запросы подходят для гибкого доступа к данным, тогда как материализация по-прежнему необходима, когда приоритетом является крайне низкое время отклика. Кроме того, потребление вычислительных ресурсов Aurora и количество запросов к S3 останутся факторами, которые следует измерять с учётом характера запросов и объёма данных.