A AWS anunciou a adição da capacidade de consultar diretamente dados Apache Iceberg e Apache Parquet armazenados no data lake juntamente com dados operacionais no Amazon Aurora PostgreSQL. O novo recurso permite que as aplicações combinem registros recentes e históricos em uma única consulta usando a sintaxe do PostgreSQL e as ferramentas atuais, sem copiar os dados para o banco de dados por meio de pipelines de ETL.
O que mudou na prática?
A funcionalidade utiliza o mecanismo DuckDB incorporado diretamente ao Aurora PostgreSQL. Assim, uma única consulta pode ler dados operacionais, incluindo gravações não confirmadas, e ler tabelas Iceberg ou arquivos Parquet do Amazon S3. A AWS também oferece suporte ao AWS Glue Data Catalog, ao Amazon S3 e ao S3 Tables, além de catálogos compatíveis com o Iceberg REST Catalog por meio do mecanismo de federação do Glue.
O usuário precisa criar um cluster do Aurora PostgreSQL, associar uma função do IAM que inclua o recurso AuroraAnalytics e, em seguida, ativar a extensão aurora_analytics. Depois disso, é possível criar foreign tables que apontem para os dados externos ou usar IMPORT FOREIGN SCHEMA para criar várias tabelas automaticamente, inferindo o esquema dos dados a partir dos metadados.
Por que esta notícia é importante?
As aplicações que combinavam transações recentes no Aurora com registros históricos no S3 normalmente precisavam copiar os dados por meio de reverse ETL, o que acrescentava operações de sincronização, custo operacional e complexidade de engenharia. Agora, essa integração pode ser realizada durante a própria consulta. Isso é útil para painéis que precisam de contexto histórico, aplicações que associam uma transação a um registro anterior e sistemas que lidam com dados distribuídos entre um banco operacional e um data lake.
Esse ponto ganha importância adicional em aplicações que utilizam agentes de inteligência artificial, pois é difícil prever antecipadamente todos os conjuntos de dados de que o agente poderá precisar e copiá-los para um banco operacional. O acesso direto permite ampliar o escopo dos dados disponíveis sem criar uma cópia para cada caso de uso.
Desempenho e opções de acesso
O Aurora aplica otimizações como o envio de filtros à fonte de dados e a redução das colunas lidas, além de armazenar temporariamente os dados usados com frequência na instância do Aurora. É possível examinar o comportamento de cada consulta por meio da função aurora_analytics_stat_statements(), que exibe indicadores como o número de linhas examinadas, o volume de dados lidos do S3 e o número de vezes em que o cache foi utilizado.
As consultas estão disponíveis nas diferentes instâncias do Aurora dentro do cluster, incluindo a instância gravadora e as réplicas dedicadas à leitura, permitindo direcionar as operações de varredura analítica para longe da carga operacional. Nos casos que exigem tempos da ordem de frações de milissegundo, é possível materializar os dados em uma tabela nativa do Aurora usando CREATE TABLE AS SELECT, INSERT INTO ... SELECT ou MERGE INTO. As operações de gravação resultantes da materialização são executadas na instância gravadora.
Disponibilidade e custo
O recurso é compatível com o Aurora PostgreSQL 17 a partir da versão 17.11 e com a versão 18 a partir da 18.6. Ele está disponível em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US), sem cobrança adicional pelo recurso em si. O custo continua associado ao aumento da capacidade computacional do Aurora consumida pelas consultas, além das taxas de solicitações do Amazon S3 para a leitura de arquivos do data lake.
Leitura da certi.news: a mudança principal não é a adição de um novo formato de armazenamento, mas a redução da distância entre o banco de dados operacional e o data lake. Ainda assim, isso não elimina as considerações de projeto das cargas de trabalho: a consulta direta é adequada para o acesso flexível aos dados, enquanto a necessidade de materialização permanece quando tempos de resposta extremamente baixos são prioridade. Além disso, o consumo de computação do Aurora e as solicitações ao S3 continuarão sendo fatores que deverão ser medidos de acordo com o padrão de consulta e o volume de dados.