AWS anunció la incorporación de la posibilidad de consultar directamente datos de Apache Iceberg y Apache Parquet almacenados en el lago de datos junto con los datos operativos dentro de Amazon Aurora PostgreSQL. La nueva capacidad permite a las aplicaciones combinar registros recientes e históricos en una sola consulta utilizando la sintaxis de PostgreSQL y las herramientas actuales, sin copiar los datos a la base de datos mediante canalizaciones ETL.
¿Qué ha cambiado en la práctica?
La función se basa en el motor DuckDB integrado directamente en Aurora PostgreSQL. De este modo, una única consulta puede leer datos operativos, incluidas las escrituras no confirmadas, y leer tablas de Iceberg o archivos Parquet desde Amazon S3. AWS Glue Data Catalog, Amazon S3 y S3 Tables también son compatibles, al igual que los catálogos compatibles con Iceberg REST Catalog mediante el mecanismo de federación de Glue.
El usuario debe crear un clúster de Aurora PostgreSQL, asociar un rol de IAM que incluya la función AuroraAnalytics y, después, activar la extensión aurora_analytics. A continuación, puede crear foreign tables que apunten a los datos externos o utilizar IMPORT FOREIGN SCHEMA para crear varias tablas automáticamente, con inferencia del esquema de datos a partir de los metadatos.
¿Por qué importa esta noticia?
Las aplicaciones que combinaban transacciones recientes en Aurora con registros históricos en S3 normalmente necesitaban copiar los datos mediante reverse ETL, lo que añadía operaciones de sincronización, costes operativos y complejidad de ingeniería. Ahora, esta integración puede ejecutarse durante la propia consulta. Esto resulta útil para paneles que necesitan contexto histórico, aplicaciones que vinculan una transacción con un registro anterior y sistemas que trabajan con datos distribuidos entre una base de datos operativa y un lago de datos.
Este aspecto adquiere una importancia adicional en las aplicaciones que utilizan agentes de inteligencia artificial, ya que es difícil prever de antemano cada conjunto de datos que el agente podría necesitar y copiarlo a una base de datos operativa. El acceso directo permite ampliar el alcance de los datos disponibles sin crear una copia para cada caso de uso.
Rendimiento y opciones de acceso
Aurora aplica optimizaciones como el envío de filtros al origen de datos y la reducción de las columnas leídas, además de almacenar temporalmente los datos utilizados con frecuencia dentro de la instancia de Aurora. El comportamiento de cada consulta puede examinarse mediante la función aurora_analytics_stat_statements(), que muestra indicadores como el número de filas examinadas, el volumen de datos leídos desde S3 y las veces que se utilizó la caché.
Las consultas están disponibles en las distintas instancias de Aurora dentro del clúster, incluida la instancia escritora y las réplicas dedicadas a lectura, lo que permite asignar las operaciones de exploración analítica lejos de la carga operativa. En los casos que requieren tiempos del orden de fracciones de milisegundo, los datos pueden materializarse en una tabla nativa de Aurora mediante CREATE TABLE AS SELECT, INSERT INTO ... SELECT o MERGE INTO. Las operaciones de escritura resultantes de la materialización se ejecutan en la instancia escritora.
Disponibilidad y coste
La capacidad admite Aurora PostgreSQL 17 a partir de la versión 17.11 y 18 a partir de la versión 18.6. Está disponible en todas las regiones comerciales de AWS y en las regiones de AWS GovCloud (US), sin un cargo adicional por la propia función. El coste sigue estando relacionado con el aumento de computación de Aurora consumido por las consultas, además de las tarifas por las solicitudes de Amazon S3 para leer archivos del lago de datos.
Lectura de certi.news: el cambio fundamental no es la incorporación de un nuevo formato de almacenamiento, sino la reducción de la distancia entre la base de datos operativa y el lago de datos. Sin embargo, esto no elimina las consideraciones de diseño de las cargas de trabajo: la consulta directa es adecuada para un acceso flexible a los datos, mientras que la materialización sigue siendo necesaria cuando los tiempos de respuesta extremadamente bajos son una prioridad. Asimismo, el consumo de computación de Aurora y las solicitudes de S3 seguirán siendo factores que deberán medirse según el patrón de consulta y el volumen de datos.