DEV Community

Cover image for Amazon Athena: análises SQL diretas no S3 – quando usar, quanto custa e quais os limites
Thiago Marques
Thiago Marques

Posted on

Amazon Athena: análises SQL diretas no S3 – quando usar, quanto custa e quais os limites

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.

  1. 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');
Enter fullscreen mode Exit fullscreen mode

Esse comando informa ao Athena:

  • Onde estão os dados (LOCATION);
  • Que o formato é CSV (SERDE);
  • E quais colunas existem no arquivo.
  1. 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;
Enter fullscreen mode Exit fullscreen mode

💡 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.

  1. 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
Enter fullscreen mode Exit fullscreen mode

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.

  1. 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;

Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)