#Databricks#FinOps#Spark#Engineering

Otimização de Custos no Databricks: O Guia Definitivo do Engenheiro de Dados

2026-01-30 DataFusionX Engineering 20 min read
Databricks Lakehouse Architecture

O Custo da Escala Mal Gerenciada

Em ambientes de Big Data, o desperdício é silencioso. Um cluster superdimensionado ou um job Spark mal otimizado podem drenar o orçamento de TI em dias. Este guia técnico explora estratégias avançadas para reduzir o TCO (Total Cost of Ownership) do Databricks em até 40%.

1. Cluster Policies: Governança como Código

A primeira linha de defesa é impedir a criação de clusters caros. As Cluster Policies permitem definir limites rígidos sobre o que os usuários podem provisionar.


// Exemplo de Cluster Policy para limitar custos
{
  "spark_conf.spark.databricks.cluster.profile": {
    "type": "fixed",
    "value": "serverless"
  },
  "aws_attributes.availability": {
    "type": "fixed",
    "value": "SPOT_WITH_FALLBACK"
  },
  "autotermination_minutes": {
    "type": "range",
    "minValue": 10,
    "maxValue": 60,
    "defaultValue": 20
  },
  "num_workers": {
    "type": "range",
    "maxValue": 10
  }
}
      

Este JSON força o uso de instâncias Spot (com fallback), limita o número máximo de workers a 10 e impõe um tempo de auto-inativação.

2. Otimização de Storage: Delta Lake Best Practices

O custo de computação está diretamente ligado à eficiência de I/O. Tabelas Delta fragmentadas (small files problem) matam a performance.

Compactação e Z-Ordering

O comando OPTIMIZE compacta pequenos arquivos em arquivos maiores (geralmente 1GB). O ZORDER co-localiza dados fisicamente para maximizar o Data Skipping.


-- Executar periodicamente em tabelas grandes
OPTIMIZE events_table
ZORDER BY (event_type, customer_id);

-- Remover arquivos antigos para economizar storage S3/ADLS
VACUUM events_table RETAIN 168 HOURS; -- 7 dias
      

Impacto Real:

Em um cliente fintech, a aplicação de Z-ORDER na coluna de transaction_date reduziu o tempo de query de relatórios mensais de 45 minutos para 3 minutos, reduzindo proporcionalmente o custo de DBU.

3. Spot Instances vs. On-Demand

Para workloads resilientes (como jobs ETL batch), use instâncias Spot. Elas custam até 90% menos que On-Demand.

Estratégia Recomendada: Configure o Driver Node como On-Demand (para manter o Spark Context vivo) e os Worker Nodes como Spot. Se a nuvem reclamar as instâncias Spot, o Driver apenas solicita novos executores, sem falhar o job.

4. Photon Engine: Quando vale a pena?

O Photon é o motor C++ vetorizado do Databricks. Ele custa mais por DBU, mas executa muito mais rápido.

  • Use Photon para: Queries SQL complexas, Joins grandes, agregações pesadas.
  • Evite Photon para: UDFs em Python complexas (que forçam a saída do motor C++ para a JVM/Python), jobs de streaming simples com pouca transformação.

./SUBSCRIBE_UPDATES

// Receba dicas de FinOps, cases de otimização e novidades sobre engenharia de dados.