Um problema comum: 15-20k/mês em infra de dados.
A stack: Cluster Spark (EMR) + Airflow para orquestração.
Parecia "enterprise". Funcionava. Mas o custo não fazia sentido para o volume processado.
Com redesign de arquitetura, é possível alcançar redução de 97% em infra.
Aqui está como.
O Problema: EMR + Airflow Para Dados Que Cabem em Memória
A stack típica:
- Spark (EMR): rodando jobs de append/dedup
- Airflow: orquestração (MWAA)
A questão óbvia: por que um cluster Spark + Airflow gerenciado rodando jobs que cabem em uma máquina?
Resposta: falta de questionamento técnico.
Por Que Tudo Custava 15k/Mês
Spark não cobra por execução. Cobra por existência.
O breakdown:
EMR cluster (mesmo pequeno): ~8-10k/mês
- Master node sempre rodando
- Workers ociosos entre jobs
- Startup overhead
- Bootstrap lento
Airflow managed: ~3-4k/mês
- MWAA (AWS managed)
- Scheduler sempre ligado
- Workers sempre prontos
Data transfer: ~1-2k/mês
O cluster Spark rodava jobs de dedup/append uma vez por dia, ~15 minutos. Os outros 23:45 horas: custo.
Airflow esperava jobs. EMR esperava Airflow. Tudo esperando, tudo custando.
A Solução: Python Puro + Self-Host + Snowflake (Sem Spark)
Redesenhamos os pipelines para serem incrementais de verdade:
- Append-only (sem reprocessamento)
- Deduplicação com janela de 3 dias
- Sem shuffle
- Python puro (Pandas + Polars)
Stack nova:
- EC2 t3.medium (~30/mês): roda job Python via cron
- Prefect self-host: orquestração leve
- S3: storage dos dados
- Python: para o processamento
Resultado:
EC2 liga → roda Python → escreve em S3 → desliga. Fim.
Custo: mínimo. Velocidade: máxima.
Resultado: 97% de Redução em Infra
Antes: 15k/mês
Depois: Uma fração disso.
Não vou colocar o número exato aqui porque soa até irreal. Mas basta dizer que o que a gente pagava em 1 mês de cluster, agora cobre vários meses de self-host.
E melhor ainda: os pipelines ficaram mais rápidos e previsíveis.
A gente saiu de:
Para:
O kicker: agora a gente consegue escalar sem aumentar o custo proporcionalmente. Antes, mais dados = mais workers = mais caro. Agora é adicionar storage.
Por Que Isso Importa
Se você tem Spark rodando ETL simples, dedup ou append-only, você está pagando 10-15x mais do que precisa.
É assim mesmo.
A Moral
Você não precisa de um cluster para ser engineer.
Precisa de bom senso.
A gente tinha infra cara rodando 2% do potencial. Parecia impressionante. A fatura discordava.
Consertamos em 2 semanas. Sem reescrever tudo. Sem perder dados. Sem downtime.
Próximo Passo
Transformamos clusters caros para arquiteturas limpas e previsíveis. O processo quase sempre é o mesmo:
1. Audit: entender o que está rodando (e por quanto)
2. Diagnóstico: identificar o overkill
3. Redesign: arquitetura eficiente
4. Implementação: migração controlada
"Se o seu pipeline cabe em memória, talvez ele não precise de um cluster inteiro tentando parecer importante."