Como reduzo minha conta do Databricks/EMR/Glue sem quebrar nada?

Contas de infraestrutura de dados na nuvem raramente disparam por um grande erro — elas se acumulam a partir de uma dúzia de pequenos erros que faziam sentido na época e nunca foram revisados. A boa notícia: a maioria das correções baratas também são as mais seguras.

Baixo risco, faça isso primeiro

• Ajuste o número de instâncias com base na utilização real, não no pico para o qual você provisionou uma vez. Se a utilização média de CPU entre os executors de um job fica abaixo de 40%, você muito provavelmente está superprovisionado — isso é quase de graça porque não muda a lógica do job em nada.
• Ative o autoscaling se ainda não ativou. Um tamanho de cluster fixo significa pagar a capacidade de pico o tempo todo. A maioria das plataformas Spark gerenciadas (Databricks, EMR) suporta isso nativamente com configuração mínima.
• Mova cargas batch elegíveis para instâncias spot/preemptible. Um job batch que pode ser reexecutado e tem checkpoints (não um job de streaming stateful de longa duração) geralmente é um bom candidato, muitas vezes com 60-90% de desconto sobre o preço on-demand.

Risco médio, teste primeiro

• Reduza o número de shuffle partitions se estiver configurado com margem defensiva alta demais. Menos partições, maiores, significa menos overhead de agendamento de tasks, mas exagerar reintroduz os problemas de pressão de memória que aquele número alto provavelmente buscava evitar — verifique contra o tempo de GC e os bytes de spill depois de mudar, não só o tempo total.
• Consolide jobs pequenos e frequentes em menos execuções, maiores. O tempo de start/warmup do cluster é overhead fixo pago a cada execução; um job que roda a cada 5 minutos paga esse overhead 12x mais vezes que o mesmo trabalho agrupado por hora.

Risco mais alto, precisa de validação real

• Trocar a família de instância (por exemplo, de otimizada para memória para propósito geral) muda a proporção memória-por-núcleo contra a qual seu job foi implicitamente ajustado — uma vitória de custo no papel pode virar uma regressão de performance ou OOM na prática.
• Mudanças agressivas de TTL/lifecycle em armazenamento intermediário economizam em armazenamento mas podem silenciosamente quebrar qualquer coisa downstream que assumia que aqueles dados ainda estariam lá.