Um varejista online armazena logs de acesso do ALB no S3 e os consulta com o Amazon Athena. O engenheiro criou uma tabela Athena não particionada, e os tempos de resposta da consulta aumentaram à medida que o volume de dados cresceu. Qual abordagem melhorará o desempenho da consulta do Athena com o menor esforço operacional?

A criação de um crawler do AWS Glue é a solução mais eficiente e de menor esforço operacional. Um crawler pode inferir automaticamente o esquema dos logs do ALB, identificar partições com base na estrutura de pastas (como ano, mês, dia) e registrar esses metadados no AWS Glue Data Catalog. O Athena utiliza esses metadados de partição para escanear apenas os dados relevantes para a consulta, reduzindo significativamente o volume de dados processados e melhorando o desempenho. As outras opções são menos ideais: Um job do AWS Glue para inferir o esquema e gravar metadados de partição é possível, mas um crawler é a ferramenta específica e automatizada para essa tarefa, exigindo menos configuração manual. Transformar os logs para Apache Parquet com uma função Lambda e adicionar partições é uma boa prática para otimização de formato e particionamento, mas envolve um esforço operacional maior para desenvolver e manter a função Lambda e o processo de transformação, além de não ser a etapa inicial mais direta para resolver o problema de particionamento. Usar Apache Hive para criar tabelas em bucket e uma função Lambda para transformar os logs é complexo e não se alinha com a simplicidade e a abordagem serverless do Athena e Glue para este caso.