Uma empresa de jogos coleta eventos de clickstream com o Amazon Kinesis Data Streams e usa o Kinesis Data Firehose para entregar arquivos JSON para o Amazon S3. Cientistas de dados consultam os dados mais recentes no Amazon Athena. A empresa deseja reduzir os custos de consulta do Athena sem reconstruir o pipeline de dados existente. Qual opção minimiza o esforço de gerenciamento ao mesmo tempo em que atende ao requisito?

A opção correta otimiza os custos do Athena convertendo os dados para o formato Parquet, que é colunar e compactado, reduzindo a quantidade de dados escaneados por consulta. Configurar o Firehose para gerar Parquet e usar um prefixo de objeto AAAA/MM/DD (particionamento) minimiza o esforço de gerenciamento para dados futuros, pois o Firehose faz a conversão e particionamento automaticamente. Para dados históricos, um trabalho ETL do AWS Glue une pequenos arquivos JSON em arquivos Parquet maiores, o que é crucial porque o Athena cobra por dados escaneados e o número de arquivos, então menos arquivos grandes são mais eficientes. ALTER TABLE ADD PARTITION atualiza o catálogo do Athena de forma eficiente. As outras opções são menos ideais: Criar um trabalho Spark em um cluster EMR efêmero adiciona complexidade e custo operacional. Alterar a localização da tabela Athena pode ser disruptivo. Enviar dados para um Kinesis Data Stream e usar o Apache Flink é uma solução mais complexa e cara, adicionando mais serviços ao pipeline. Anexar um Lambda ao Firehose para converter para Parquet adiciona complexidade e custo de desenvolvimento e manutenção do Lambda, além de ter limites de tempo de execução e memória.