This content originally appeared on DEV Community and was authored by Thiago Marques
Quando começei a trabalhar com AWS em 2021, nos meus estudos para a CCP via o S3 **como um Google Drive com **capacidade infinita (obviamente tinha uma visão beemm limitada de um cara que vinha de router bgp em Cisco). Contudo tenho notado que nos últimos anos, o S3 se consolidou como a espinha dorsal dos Data Lakes modernos na AWS, com cada vez mais funções e inovações.
Praticamente todo projeto de dados na AWS começa por lá: armazenando logs, relatórios financeiros, eventos de aplicações ou mesmo datasets públicos. Na prática ele deixou de ser um repositório passivo e virou o ponto de partida da inteligência de dados na nuvem.
O desafio agora não é mais guardar dados, e sim extrair valor deles sem clusters caros ou ETLs pesados.
É aí que entra o Amazon Athena. Lançado em 2016, como um serviço serverless de consultas SQL sobre o S3. Com ele, você não provisiona servidores, não paga por nós ociosos e obviamente não precisa configurar instâncias: apenas descreve o schema (e por traz ele usa o Glue Data Catalog) e consulta via SQL.
Nesse blog post quero mostrar como o Athena faz as queries no S3, como podemos deixar essa queries mais baratas e mais rápidas, e também quando utilizar esse combo é uma vantagem.
Cenário de estudo
Vamos usar um caso prático: temos um arquivo CSV com dados de filmes do IMDb armazenado no S3 com cerca de 10 MB, contendo colunas como título, ano, gênero e avaliação.
A ideia é analisar esses dados diretamente no S3 usando o Athena, sem precisar criar um banco de dados. Queremos responder perguntas como:
- “Quais são os filmes mais bem avaliados por gênero?”
- “Quantos filmes foram lançados por década?”
No começo, as consultas funcionam, mas são lentas e caras (o Athena precisa ler todo o CSV a cada execução). Então para resolver isso, aplicamos CTAS (Create Table As Select), convertendo o CSV para Parquet e criando partições por ano de lançamento, e assim reduzir tempo e custo.
Nosso objetivo: comparar a diferença entre consultar o CSV bruto e a versão otimizada em Parquet, analisando tempo de execução, volume de dados escaneado e custo em dólar.
Arquitetura por trás do Athena
Ok, o Athena além de ter um nome fanstástico foi algo totalmente revolucionário? A resposta direta: Não. Em resumo, ele funciona como a ponte entre o S3, onde os dados vivem, e as ferramentas que precisam deles.
Junto com ele tem o todo poderoso AWS Glue Data Catalog: que descreve o conteúdo, como se fose um mapa para o dataset (palavra bonita para o .csv), na prática ele é que vai dar significado ao .csv.
Ai temos o Presto (motor interno (Trino)): que é quem realmente executa as consultas em paralelo, lendo os arquivos diretamente do S3.
Visualmente, a arquitetura pode ser imaginada assim: o S3 armazena os dados (CSV, JSON, Parquet), o Glue Catalog descreve como esses dados estão estruturados, o Athena (Presto) executa as queries em workers temporários, e os resultados podem ser enviados para QuickSight, Redshift ou devolvidos ao S3.
Mão na massa: dataset do IMDb
Para entender na prática como o Athena trabalha, vamos usar um dataset real: baixei a base de filmes do IMDb e subi em um bucket no S3, a base possui filmes com informações como título, ano de lançamento, nota e país.
Nosso objetivo será analisar quantos filmes foram lançados por ano nas décadas de 1980 e 1990, comparando a execução entre uma base CSV e uma versão otimizada em Parquet com particionamento por ano.
- Criando a tabela no Athena (CSV original no S3)
CREATE EXTERNAL TABLE IF NOT EXISTS imdb_movies (
id STRING,
title STRING,
link STRING,
year INT,
duration STRING,
rating_mpa STRING,
rating_imdb STRING,
vote STRING,
budget STRING,
gross_world_wide STRING,
gross_us_canada STRING,
gross_opening_weekend STRING,
director STRING,
writer STRING,
star STRING,
genre STRING,
country_origin STRING,
filming_location STRING,
production_company STRING,
language STRING,
win STRING,
nomination STRING,
oscar STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
'separatorChar' = ',',
'quoteChar' = '"'
)
LOCATION 's3://datanews-user-event/input/'
TBLPROPERTIES ('skip.header.line.count'='1');
Esse comando informa ao Athena:
- Onde estão os dados (LOCATION);
- Que o formato é CSV (SERDE);
- E quais colunas existem no arquivo.
- Consultando quantos filmes foram lançados por ano (anos 80 e 90)
Agora podemos fazer a primeira consulta, (aqui ainda sem sem otimização).
Essa query irá contar quantos filmes existem por ano entre 1980 e 1999.
SELECT year, COUNT(*) AS total_filmes
FROM movies_csv
WHERE year BETWEEN 1980 AND 1999
GROUP BY year
ORDER BY year;
💡 Aqui o Athena vai ler o CSV inteiro, mesmo que a maioria dos registros não esteja dentro do período desejado.
Isso significa mais dados escaneados, mais tempo e mais custo.
- Criando a tabela otimizada em Parquet com CTAS (filmes entre 80 e 90) Para melhorar a performance, vamos criar uma nova tabela em formato Parquet e particionada por ano. Usaremos o comando CTAS (Create Table As Select), que lê o dataset original, filtra os dados desejados e grava uma nova versão da tabela já otimizada no S3.
CREATE TABLE imdb_movies_80_90
WITH (
format = 'PARQUET',
external_location = 's3://datanews-user-event/ctas/',
partitioned_by = ARRAY['year'],
parquet_compression = 'SNAPPY'
) AS
SELECT
id,
title,
director,
year
FROM
movies_csv
WHERE year BETWEEN 1980 AND 1999
O Athena criará automaticamente subpastas no S3 como:
s3://datanews-user-event/ctas/year=1980/
s3://datanews-user-event/ctas/year=1981/
...
s3://datanews-user-event/ctas/year=1999/
Cada partição conterá apenas os filmes daquele ano.
- Consultando novamente a base otimizada Agora, basta rodar a mesma query de antes, mas sobre a nova tabela particionada:
SELECT year, COUNT(*) AS total_filmes
FROM imdb_movies_80_90
GROUP BY year
ORDER BY year;
O Athena agora só lê as partições necessárias (anos 80 e 90), em formato colunar e comprimido, em vez de varrer o CSV inteiro.
Isso pode reduzir o volume escaneado em até 90% e o tempo de execução em 3 a 5 vezes, dependendo do tamanho do dataset.
Resultado? O mesmo conjunto de dados, mas agora com consultas até 90% mais baratas e 3x mais rápidas.
O que muda não é o dado, é o formato e a forma como o Athena o lê.
Esse é o ponto em que o S3 deixa de ser apenas armazenamento e passa a ser plataforma de análise.
Comparações com outras soluções
Mas apenas o Athena consegue ler dados do S3? Não. Ele é muito bom para consultas ad-hoc (imagine o ad-hoc como um uber, ou seja, você solicita só quando precisa) e analises sob demanda, mas não é a escolha ideal para todos os cenários.
O Redshift Spectrum, por exemplo, também consultas dados no S3, mas depende de um cluster RedShift ativo, e é mais indicado para quem usa um data warehouse e quer estender o alcance das consultas.
O Amazon EMR, com Spark e Hive, é voltado a pipelines complexos e ETL massivos, também vai conseguir ler o S3, é mais fléxivel e muito mais poderoso, contudo exige uma manutenção e configuração mais pesada.
Custos e casos de uso
O Athena te cobra $5 por terrabyte escaneado proporcionalmente, ou seja, uma query que lê 1GB custa aproximadamente $0,005.
Simplicidade sedutora, posso dizer, mas perigosa.
Em números práticos, imagine um CloudTrail com 450GB de logs, que precisam ser analisados uma vez por semana:
- CSV: 450 GB lidos × $5/TB = ~$9 por execução
- Parquet: 110 GB lidos × $5/TB = ~$2.25
Essa diferença se repete toda semana, em um ano, são mais de $350 de economia só por mudar o formato.
Então utilize o Athena para contextos onde precisa da informação rápida ou quer manter a infra totalmente serveless. Exemplos:
- BI e dashboards: junto com o QuickSight, gera relatórios em tempo real sem precisar mover dados.
- Logs e auditoria: usado por equipes de segurança/redes para consultar CloudTrail, VPC Flow Logs e ALB Logs.
- Data Lakes serverless: combinação de Glue + Athena + S3, criando um ecossistema de análise totalmente sem servidor.
Pontos importantes:
- Cada query pode rodar no máximo por 30 minutos;
- Os resultados (download) é limitado em 100MB (maiores só mandar para o S3 e fazer o download por lá);
- Tem um soft-limit de 20 queries simultâneas por conta/região;
Bonus
quando NÃO utilizar o Athena:
Quando não usar o Athena:Quando você precisa de queries complexas com muitos joins e aggregations;
Quando os dados precisam de atualizações frequentes (Athena é leitura, não transação);
Ou quando o custo por leitura começa a se igualar ao de um Redshift mantido ativo.
No fim, essa é a mentalidade por trás da nuvem moderna:
trazer a análise para os dados, e não os dados para a análise.
É o que faz o Athena ser tão poderoso — ele não é apenas uma ferramenta de consulta, mas um lembrete de que inteligência começa quando paramos de mover informação e começamos a escutá-la onde ela vive.
revisado por: Elisa Livramento
This content originally appeared on DEV Community and was authored by Thiago Marques
Thiago Marques | Sciencx (2025-10-17T14:59:44+00:00) Amazon Athena: análises SQL diretas no S3 – quando usar, quanto custa e quais os limites. Retrieved from https://www.scien.cx/2025/10/17/amazon-athena-analises-sql-diretas-no-s3-quando-usar-quanto-custa-e-quais-os-limites/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.