Databricks - Clusters e Compute

O compute no Databricks é o conjunto de VMs que executam Spark, SQL ou Python. Escolher o tipo e configuração correta impacta diretamente performance e custo.

Tipos de compute

All-Purpose Cluster

Cluster de uso geral, criado manualmente. Fica ativo até ser terminado manualmente ou pelo timeout de inatividade.

Usado em notebooks interativos e desenvolvimento
Pode ser compartilhado entre vários usuários e notebooks simultaneamente
Mais caro: paga por toda a duração em que o cluster está ligado
Configurar autotermination_minutes para evitar cobranças desnecessárias

Job Cluster

Cluster criado automaticamente quando um Job inicia e destruído ao final.

Ambiente isolado e reproducível por execução
Mais barato: paga apenas pelo tempo da execução do job
Não pode ser acessado via notebook interativo
Configurado dentro da definição do job ou DAB

SQL Warehouse (antes SQL Endpoint)

Compute otimizado exclusivamente para queries SQL via Databricks SQL. É o tipo de cluster correto para consumo pela ponta final: analistas, dashboards e sistemas analíticos conectados ao Databricks.

Usa o engine Photon (C++, muito mais rápido que Spark para SQL puro)
Escala por clusters (unidades de 2 workers) de forma automática
Suporta conexão via JDBC/ODBC, ODBC DSN, e APIs REST
Integra nativamente com ferramentas de BI: Power BI, Tableau, Looker, Metabase
Auto-stop configurável: desliga automaticamente após período de inatividade

Subtipos de SQL Warehouse

Tipo	Infra	Quando usar
Serverless	Gerenciado pela Databricks, sem VMs no workspace	Padrão recomendado; start rápido (~5s), sem gestão de infra
Pro	VMs no workspace do cliente, features avançadas	Necessário para Databricks AI/BI, Genie, lakehouse federation
Classic	VMs no workspace do cliente, features básicas	Legado; preferir Pro ou Serverless em novos projetos

Por que SQL Warehouse para consumo final?

All-Purpose e Job Clusters executam Spark de propósito geral, sendo adequados para engenharia e processamento. O SQL Warehouse é otimizado para o padrão de uso de dashboards e sistemas analíticos:

Concorrência: múltiplos usuários consultando ao mesmo tempo sem degradação
Latência baixa: Photon + serverless reduz tempo de resposta vs Spark tradicional
Custo controlado: auto-stop garante que o warehouse não fique ocioso pagando
Segurança: integra com Unity Catalog para governança de dados por usuário/grupo
Sem gerenciamento: analistas e times de BI não precisam gerenciar clusters

Configurações essenciais de cluster

# Dentro de databricks.yml (DAB) ou via API
cluster:
  spark_version: "15.4.x-scala2.12"   # Databricks Runtime (DBR)
  node_type_id: "Standard_D8ds_v5"    # Azure / "m5.2xlarge" AWS
  num_workers: 4                       # workers fixos
  # OU autoscaling:
  autoscale:
    min_workers: 2
    max_workers: 10
  autotermination_minutes: 30
  spark_conf:
    spark.sql.shuffle.partitions: "200"
    spark.databricks.delta.optimizeWrite.enabled: "true"
  data_security_mode: "SINGLE_USER"    # necessário para Unity Catalog

Databricks Runtime (DBR)

Cada cluster roda uma versão do Databricks Runtime, uma distribuição customizada do Spark com otimizações próprias.

Runtime	Destaque
`15.4 LTS`	Spark 3.5, Python 3.11, suporte longo (LTS)
`15.4 LTS ML`	Igual ao LTS + MLflow, TensorFlow, PyTorch pré-instalados
`15.4 LTS Photon`	Spark + Photon engine para SQL analítico

Regra: use LTS em produção. Use versões non-LTS apenas para testar novas features.

Autoscaling

Com autoscale habilitado, Databricks adiciona/remove workers automaticamente baseado na carga do Spark:

Vantagem: custo otimizado em jobs com carga variável
Cuidado: autoscaling pode aumentar latência em jobs curtos (tempo de provisionar VM)
Para jobs de streaming ou queries críticas de latência, prefira workers fixos

Instance Pools

Instance Pools mantêm VMs pré-aquecidas prontas para uso, eliminando o tempo de cold start de clusters.

{
  "instance_pool_name": "pool-engenharia",
  "node_type_id": "Standard_D8ds_v5",
  "min_idle_instances": 2,
  "max_capacity": 20,
  "idle_instance_autotermination_minutes": 30
}

Workers do pool iniciam em ~30s vs 3-5 min de cold start
Clusters apontam para um pool via instance_pool_id
Custo: paga pelas VMs idle no pool (menor que cluster ativo)

Cluster Policies

Policies restringem e padronizam configurações de cluster, evitando que usuários criem clusters caros ou mal configurados.

{
  "node_type_id": {
    "type": "fixed",
    "value": "Standard_D8ds_v5"
  },
  "autotermination_minutes": {
    "type": "range",
    "minValue": 10,
    "maxValue": 120,
    "defaultValue": 30
  },
  "spark_version": {
    "type": "regex",
    "pattern": "15\\.[0-9]+\\.x-scala2\\.12"
  }
}

Administradores criam policies e as atribuem a grupos de usuários
Usuários sem policy de admin só podem criar clusters dentro dos limites da policy
Essencial para controle de custos em workspaces multi-time

Modos de acesso (Unity Catalog)

Modo	Suporte Unity Catalog	Uso
`SINGLE_USER`	Sim (completo)	Jobs e pipelines de produção
`SHARED`	Sim (com limitações)	Notebooks multi-usuário, desenvolvimento
`NO_ISOLATION_SHARED`	Não	Legado, evitar em novos projetos

Para usar Unity Catalog, o cluster deve estar em SINGLE_USER ou SHARED.

Ver também: databricks | databricks-jobs | databricks-asset-bundles | databricks-unity-catalog

Second Brain

Explorer