Databricks Runtime, Photon e Clusters: DBR/LTS, Políticas, Pools e a Forma do Custo de Compute

Todo pipeline deste curso roda em alguma coisa. Tabelas Delta não se otimizam sozinhas, o Auto Loader não lista um prefixo de graça, e um pipeline Lakeflow só é tão barato quanto as máquinas que ficam embaixo dele. Esta lição é sobre esse algo: qual versão do Databricks Runtime você fixa, se o Photon está executando o seu plano, em que tipo de cluster (ou warehouse, ou sessão serverless) o trabalho roda, quem pode criá-lo (cluster policies), quão rápido ele pode subir (instance pools), que família de EC2 ele usa e, a parte que aparece na fatura, qual taxa de DBU se aplica a ele.

Esse último ponto é a espinha da lição. Na AWS, a mesma instância EC2 é cobrada em uma taxa de DBU diferente dependendo do tipo de compute ao qual ela foi anexada. A Jobs API 2.0 diz isso sem rodeios: "Quando você executa um job em um novo jobs cluster, o job é tratado como um workload de Jobs Compute (automático) sujeito à precificação de Jobs Compute" e "Quando você executa um job em um all-purpose cluster existente, ele é tratado como um workload de All-Purpose Compute (interativo) sujeito à precificação de All-Purpose Compute" (docs.../jobs-2.0-api, página datada de 2026-08-03). Mesmos nós, mesmo Spark, mesmos dados, e nos preços de lista dos EUA em out 2026, um SKU de $0.15/DBU contra um SKU de $0.55/DBU. Todo o resto desta lição é decisão de performance ou decisão de governança; esta aqui é aritmética pura, e é a razão pela qual um ETL noturno de 45 minutos pode custar $1,027 ou$2,947 por mês (exemplo resolvido E5).

Nesta lição você vai:

• ler a tabela de DBRs suportados em out 2026 com todas as datas de EoS, e percorrer o ciclo de vida Beta → GA → LTS → EoS → EoL como um diagrama;
• rastrear uma query por Catalyst e Photon, nomear os quatro casos em que o Photon não ajuda, e datar cada benchmark que você citar;
• separar os tipos de compute all-purpose, job, SQL warehouse e serverless, incluindo a regra de precificação que decide a fatura;
• resolver seis exemplos resolvidos: uma cluster-policy JSON comentada, uma configuração de instance pool, a seleção de família de instância para quatro formas de workload, a forma de custo job-versus-all-purpose, uma triagem Photon-or-not, e uma postura de notebook de produção;
• aplicar cluster policies (fixed/allowlist/regex/range, dbus_per_hour, cluster_type, auto:latest-lts) e fechar a backdoor Unrestricted;
• definir janelas de autoscaling, auto-termination, topologia de spot e first_on_demand sem pisar nas armadilhas documentadas;
• estudar Comcast e Addepar na AWS, ler a caixa de atualizações de 2026, e praticar com doze questões mais quatro verificações interativas.

---

1. Databricks Runtime: a escada de versões e o relógio do LTS

1.1 O conjunto suportado (página de release-notes com última atualização em 11 de setembro de 2026)

A Databricks publica duas linhas ao mesmo tempo: uma linha atual, que continua recebendo features, e uma linha LTS, que troca novidade por uma janela de suporte de três anos. A tabela de versões suportadas na AWS (docs .../release-notes/runtime, última atualização em 11 de setembro de 2026, acesso 2026-10) é a única lista de versões em que você deve confiar:

Cada versão também vem com uma variante ML (mesmo número, MLflow mais bibliotecas de ML fixadas nela): a matriz de MLflow lê 19 → MLflow 3.12.0, 18 LTS → 3.8.1, 17.3 LTS → 3.0.1, 16.4 LTS → 2.21.3 (mesma página, acesso 2026-10).

Duas questões de 2026 importam mais que os próprios números:

1. A numeração mudou no DBR 19. "Antes do Databricks Runtime 19, a Databricks lançava runtimes como versões menores de features (por exemplo, 18.0, 18.1, 18.2), cada uma com seu próprio Beta e GA" (docs .../release-notes/runtime/databricks-runtime-ver, acesso 2026-10). A partir do 19, a fase de desenvolvimento de features roda como uma única linha major.
2. Um minor aposentado e um LTS vivo coexistem. A página de release-notes do DBR 18.0 já está rotulada de (EoS), "O suporte a esta versão do Databricks Runtime terminou", ainda que a mesma página registre "This version incorporates all features … Databricks released this version in January 2026", Spark 4.1.0 e JDK 21 por padrão (docs.../release-notes/runtime/18.0, acesso 2026-10). Enquanto isso, o 18 LTS é suportado até 10 de junho de 2029. Fixe a linha LTS, nunca um número de minor aposentado.

1.2 O ciclo de vida, desenhado

As quatro durações vêm direto da página de ciclo de vida de suporte (acesso 2026-10): uma fase de features no GA de ~seis meses, backports LTS por três anos, "The end-of-support date is three years after the GA release date", e "Databricks makes a best effort to set the end-of-life date six months after the end-of-support date". No EoS a versão "não é mais selecionável na interface quando você cria ou atualiza um recurso de compute"; no EoL ela "becomes unusable … existing workloads running on these versions fail". Essa é a diferença entre um job que para de ser agendado e um job que quebra, e é a razão pela qual fixar versão é um controle de produção, não uma preferência.

1.3 Qual linha para qual workload

A página de configuração de compute é explícita (docs .../compute/configure, última atualização em 6 de outubro de 2026): "Para compute all-purpose, use a versão mais atual … Para compute de job que executa workloads operacionais, considere usar a versão Databricks Runtime de suporte de longo prazo (LTS)." Traduzindo:

• Interativo/exploratório (all-purpose): a versão suportada mais nova: você quer as features e, de qualquer forma, reinicia com frequência.

• Jobs operacionais: uma linha LTS, fixada pela string exata (17.3.x-scala2.12), porque um minor inesperado do Spark no meio de um trimestre é uma indisponibilidade.

• Data science / ML: a variante ML da linha que você escolheu.

• Em uma cluster policy: spark_version com um token especial, auto:latest-lts, auto:latest-ml, auto:prev-major, auto:prev-lts, que "não faz o compute se atualizar automaticamente quando uma nova versão de runtime é publicada"; ele resolve quando um usuário edita o compute (docs.../admin/clusters/policy-definition, última atualização em 1 de outubro de 2026).

• 📚 Você sabia? A Databricks mantém "cluster configuration information for terminated clusters for 30 days" (intro da Clusters API, acesso 2026-10). É tempo suficiente para responder "que runtime e que tipo de nó aquele job com falha usou na terça passada?" e curto o bastante para você exportar as formas que interessam (via asset bundles ou Terraform) em vez de fazer arqueologia na UI.

---

2. Photon: o que o motor vetorizado faz, e o que ele não faz

2.1 Um planejador, dois motores de execução

"Photon is the Databricks-native vectorized query engine that accelerates your SQL workloads, DataFrame API calls, ETL pipelines, and stateless streaming workloads" (docs.../compute/photon, última atualização em 11 de setembro de 2026). A frase de arquitetura para decorar: "O otimizador de query do Apache Spark (Catalyst) ainda planeja a sua query, mas o Photon assume no nível de execução", e "Quando o Photon encontra uma operação não suportada … ele volta de forma transparente ao runtime Spark para o resto daquela operação."

O Photon processa "data in batches of thousands of rows at a time, enabling modern CPUs to use SIMD instructions", e features como predictive I/O e dynamic file pruning em MERGE/UPDATE/DELETE exigem Photon (mesma página). Ele é "o motor padrão para todos os SQL warehouses", está habilitado em compute serverless e pipelines Lakeflow serverless e, desde o DBR 9.1 LTS, "Photon is enabled by default on compute running Databricks Runtime 9.1 LTS and above" para compute all-purpose e job clássico criado pela UI.

2.2 Onde o Photon não ajuda

A documentação é incomumente direta, e cada cláusula abaixo é citável:

Há também uma cláusula de economia: Photon não é velocidade grátis. "Photon instance types consume DBUs at a different rate than the same instance type running the non-Photon runtime" (blog da Databricks, "Announcing Photon Public Preview", 2021-06-17). A regra operante: Photon só paga quando é mais do que proporcional em velocidade, então faça benchmark do seu workload e meça a fatia do Photon na Spark UI em vez de adivinhar.

2.3 As evidências, datadas

Cite-as com as datas; elas não são intercambiáveis:

• 📚 Você sabia? O recorde auditado de TPC-DS de 100 TB rodou neste substrato do curso: dados em Amazon S3, 256 × i3.2xlarge (SIGMOD '22). Instâncias storage-optimized mais um motor vetorizado é o datapoint de referência de "lakehouse bate warehouse", e é a mesma família de instância na qual os warehouses clássicos e pro ainda se padronizam hoje (todos os workers de warehouse classic/pro são i3.2xlarge, docs.../warehouse-behavior, acesso 2026-10).

2.4 Exemplo resolvido E1: Photon ou não? Triagem de dois notebooks

Em outubro de 2026. Duas equipes afirmam "Photon não ajudou". Faça a triagem antes de mudar qualquer coisa:

---

3. Anatomia do cluster: all-purpose versus job versus warehouse versus serverless

3.1 O que roda onde, na AWS

"Databricks components" (docs, página datada de 2026-07-28) traça a linha de forma simples: "There are two types of clusters: all-purpose and job." Some os SQL warehouses e as sessões serverless e você tem os quatro tipos de compute que este curso usa.

Três fatos específicos da AWS naquela figura: clusters clássicos e warehouses pro/classic rodam em EC2 na sua VPC ("With a pro SQL warehouse (unlike a serverless SQL warehouse), the compute layer exists in your AWS account", docs .../warehouse-types, última atualização em 12 de fevereiro de 2026); serverless roda na conta Databricks sem IPs públicos; e com o secure cluster connectivity ligado (o modo de implantação padrão), nada no plano de dados precisa de IP público de entrada.

3.2 A diferença de ciclo de vida, e a diferença de preço

Citação das docs (página de components, 2026-07-28): "O agendador de jobs da Databricks cria um job cluster quando você executa um job em um novo job cluster e encerra o cluster quando o job termina." E a consequência de precificação, vinda da Jobs API 2.0 (página datada de 2026-08-03): "When you run a job on a new jobs cluster, the job is treated as a Jobs Compute (automated) workload subject to Jobs Compute pricing": enquanto apontar um job para um all-purpose cluster existente é precificação de All-Purpose, e, segundo a página de components, "running a job on an existing all-purpose cluster is also treated as an interactive workload." A mesma API acrescenta: "We suggest running jobs on new clusters for greater reliability."

A orientação da Databricks sobre jobs-compute vai além (docs.../jobs/compute, última atualização em 15 de setembro de 2026): "O compute serverless para jobs é o padrão para todas as tarefas que o suportam", e "Compute all-purpose: você pode configurar tarefas opcionalmente com all-purpose clássico. A Databricks não recomenda essa configuração para jobs de produção."

Um detalhe que vale levar para a lição 09: um shared job cluster é "scoped to a single job run and cannot be used by other jobs or runs of the same job. Libraries cannot be declared in a shared job cluster configuration." Declare dependências por task (ou via job environments), não no objeto do cluster compartilhado.

3.3 Exemplo resolvido E2, a forma de custo: um pipeline, três configurações

Em outubro de 2026, lista US, plano Premium, AWS. Cenário: um ETL noturno de 45 minutos que roda 400 cluster-hours por mês, 4 nós no total (1 driver + 3 workers). O exemplo resolvido da própria Databricks usa um nó que "runs at 3 DBU/hour" (blog, Best practices for cost management in Databricks, 2022-10-18): trate esse valor de emissão como ilustrativo: a emissão de DBU por nó não é publicada como tabela oficial, então leia a sua em system.billing.list_prices ou na calculadora de preços.

A configuração (B) também carrega horas ociosas: um all-purpose cluster é cobrado enquanto está ligado, não enquanto trabalha, e é exatamente por isso que existem auto-termination (seção 8) e policies (seção 6). Repare no que não mudou entre (A) e (B): nós, runtime, Spark, dados. Só o tipo de compute, e, com ele, o SKU. Essa é a decisão de maior alavancagem desta lição, e é a razão pela qual a Databricks relata que clientes "saved tens of thousands of dollars by simply moving just ten percent of their workloads from all-purpose clusters to jobs clusters" (blog, 2022-10-18).

---

4. Compute serverless e SQL warehouses

4.1 A matriz de compute recomendado

A Databricks publica uma tabela de recomendação por tipo de task (docs .../jobs/compute, última atualização em 15 de setembro de 2026). Leia-a como "o padrão, a menos que sua lista de dependências proíba":

Elegibilidade de serverless na AWS (docs.../sql/admin/serverless, última atualização em 10 de junho de 2026): workspace em plano Premium ou superior, não um free trial, suportado em todas as regiões AWS, sem IPs públicos, e "Cluster policies, including spot instance policies, are not supported". Essa última cláusula é a frontira de tudo na seção 6: policies governam compute clássico; serverless é governado por controles em nível de conta/workspace no lugar disso.

4.2 Limitações do serverless: leia esta lista antes de migrar um job

De docs .../compute/serverless/limitations (acesso 2026-10), os bloqueadores que forçam compute clássico:

• "R is not supported." · "Scala e R não são suportados em notebooks."
• "Apenas as APIs Spark Connect são suportadas. As APIs Spark RDD não são suportadas."
• "Maven coordinates are not supported." · "JAR libraries are not supported in notebooks … JAR tasks in jobs are supported." · "Bibliotecas de tarefa não são suportadas para tarefas de notebook."
• "Você deve usar Unity Catalog para se conectar a fontes de dados externas." · "Access to DBFS is limited."
• "Serverless compute has a maximum runtime of 7 days."
• Gatilhos de streaming: Trigger.AvailableNow() (recomendado) e o deprecado Trigger.Once() apenas: Trigger.ProcessingTime e Trigger.Continuous não são suportados.

A página de migração (última atualização em 2026-07-10) lista os mesmos bloqueadores como coisas a substituir primeiro: imagens customizadas, variantes de ML Runtime, DBR < 13, instance profiles, e "dependencies such as eggs, JARs, and Maven libraries", com os padrões de substituição: RDD APIs → DataFrame APIs, caminhos DBFS → volumes do UC, IAM instance profiles → external locations do UC, JARs JDBC customizados → Lakehouse Federation.

4.3 SQL warehouses: três tipos, dois relógios

(docs .../sql-warehouse/warehouse-types, última atualização em 12 de fevereiro de 2026; auto-stop de docs .../sql-warehouse/create, acesso 2026-10)

O dimensionamento de classic/pro é um cluster para 10 queries concorrentes, de 2X-Small (1 driver + 1 worker) por X-Small, Small … X-Large (32 workers), 2X (64), 3X (128), 4X (256), com 5X-Large (512) em Public Preview (docs.../warehouse-behavior, acesso 2026-10). A orientação permanente da Databricks: "Databricks recommends using serverless SQL warehouses when available", e a frase de cobrança para decorar: "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped."

Veredito Comparativo: job cluster versus all-purpose versus SQL warehouse versus serverless (em out 2026)

• Job cluster (clássico, Jobs Compute $0.15/DBU + seu EC2): a resposta padrão para batch de produção. Efêmero por execução, sem reinício, auto-termina com a run, aceita spot, governado por policy, o SKU clássico mais barato por DBU. Pague pelas horas em que ele de fato roda; você é dono do EC2, do EBS e do tempo de aquecimento. Use quando as dependências forem só-clássicas (JAR/Spark Submit, RDD, instance profiles, DBFS) ou quando o job roda longo e quente em uma forma previsível.
• All-purpose (All-Purpose Compute $0.55/DBU + seu EC2): apenas interativo: exploração, notebooks compartilhados, ensino. 3.7× a taxa por DBU de jobs na lista US, é cobrado enquanto ligado, e apontar jobs de produção para ele é simultaneamente um anti-padrão de cobrança interativa e de confiabilidade ("a Databricks não recomenda essa configuração para jobs de produção"). Controles obrigatórios: auto-termination, uma policy, nunca um driver em spot.
• SQL warehouse (SQL Classic $0.22 / Pro $0.55 / Serverless $0.70 por DBU), o caminho de servir BI, cobrado enquanto ligado, dimensionado por camiseta e não pelos workers que você escolhe. Serverless soma Predictive IO + IWM e auto-stop de 10 minutos; pro/classic rodam na sua VPC em i3.2xlarge com auto-stop de 45 minutos e início de ~4 minutos. Escolha por concorrência de query e SLA de latência, não só pela taxa de DBU, o gap classic/serverless ($0.48 por DBU-hora) é a máquina+ops que o serverless absorve por você.
• Jobs/notebooks serverless (Jobs Serverless $0.35/DBU, All-Purpose Serverless $0.75/DBU), o padrão da plataforma onde a lista de limitações permite: sem fatura de EC2, sem pools, sem aquecimento, sem superfície de policy, runtime máximo de 7 dias, cobrança por segundo, custo ocioso zero. Custa por volta de 1,3 to 2,3× mais por DBU que o clássico, mas apaga as colunas de tempo ocioso e de administração da fatura.
• Veredito em uma linha: serverless por padrão → job clusters clássicos quando um bloqueador ou uma forma longa e quente exigir → all-purpose para humanos, nunca para pipelines → SQL warehouse para BI com auto-stop obrigatório. Toda taxa acima é lista US, plano Premium, AWS, em outubro de 2026; confirme contra system.billing.list_prices na sua conta antes de comprometer um orçamento com ela.

---

5. Instance pools: subida quente, não compute grátis

Um pool é "A set of idle, ready-to-use instances that reduce cluster start and auto-scaling times" (docs .../getting-started/concepts, 2026-07-28). Os clusters anexados tiram seu driver e seus workers do pool e os devolvem no encerramento. Três knobs de dimensionamento (docs .../compute/pools, acesso 2026-10): min_idle_instances, max_capacity, idle_instance_autotermination_minutes.

A regra de cobrança é a que os estudantes erram: "A Databricks não cobra DBUs enquanto as instâncias estão ociosas no pool. A cobrança do provedor de instâncias se aplica" (docs .../pool-best-practices / pool-index, acesso 2026-10). Pools deslocam custo da coluna de DBU para a coluna da AWS e compram minutos de subida; eles não apagam a fatura. Restrições e regras das mesmas páginas:

• Um pool é "either all spot instances or all on-demand instances"; a Instance Pools API acrescenta SPOT_WITH_FALLBACK: "o pool adquire instâncias spot primeiro e recua para instâncias on-demand quando a capacidade spot está indisponível".
• "By default, Databricks sets the max spot price at 100% of the on-demand price."
• Estourar a escala falha de forma barulhenta: "Se um cluster que usa o pool solicitar mais instâncias do que esse número durante o autoscaling, a solicitação falha com um erro INSTANCE_POOL_MAX_CAPACITY_FAILURE." Mantenha o tamanho máximo do cluster ≤ pool max_capacity.
• Clusters herdam a availability zone do pool; use pools separados quando os requisitos de driver e de worker diferem.
• Nunca spot no driver: "Não use um pool com instâncias spot como o tipo do seu driver. Escolha um tipo de driver on-demand para evitar que o seu driver seja recolhido."
• Onde o serverless cabe, o conselho da Databricks é direto: "If your workload supports serverless compute, Databricks recommends using serverless compute instead of pools."
• Orientação de dimensionamento: pools de spot para workers tolerantes a custo; pools on-demand para "jobs with short execution times and strict execution time requirements".

5.1 Exemplo resolvido E3: configuração de pool + a fatura de ociosidade

Em outubro de 2026 (lista us-east-1, lida em 2026-10-12). Uma equipe quer subidas quentes para um job noturno de 45 minutos e para clusters de dev interativos.

• 📚 Você sabia? O seguro de ociosidade do pool custa cerca de $136/mês neste exemplo: enquanto um único dia acidental daquele all-purpose cluster de 4 nós deixado ligado (12 DBU/h × 24 h × $0.55 = $158.40 de DBUs mais 4 × $0.192 × 24 ≈ $18.43 de EC2 ≈ $177) já custa mais do que um mês inteiro de subidas quentes. Pools são para latência de subida e capacidade, auto-termination é para custo; equipes que instalam pools mas pulam o auto-termination costumam terminar com as duas faturas.

---

6. Cluster policies: governança e guardrails de custo como JSON

"Uma policy é uma ferramenta que administradores de workspace podem usar para limitar as permissões de criação de compute de um usuário ou grupo com base em um conjunto de regras de policy" (docs.../admin/clusters/policies, página datada de 2026-06-10). Os benefícios documentados: configurações prescritas, limites de quantos clusters um usuário pode criar, uma UI simplificada, "Control cost by limiting per-cluster maximum cost" e "Enforce cluster-scoped library installations". O próprio blog de onboarding de policies da Databricks (2025-04-17) nomeia os dois ganhos, "Simplification of platform usage and effective cost control are the two main benefits of cluster policies", e o conjunto inicial de quatro famílias: Personal Compute, Power User Compute, Shared Compute, Job Compute.

Mecânica que você precisa saber antes de escrever JSON (docs .../admin/clusters/policy-definition, última atualização em 1 de outubro de 2026):

• As regras se aplicam a "qualquer um dos atributos controlados pela Clusters API", e "Pode haver apenas uma limitação por atributo."
• Tipos de limitação: fixed, forbidden, allowlist, blocklist, regex, range, unlimited (cada um pode carregar defaultValue, isOptional, hidden).
• Atributos virtuais: dbus_per_hour, "Atributo calculado que representa o máximo de DBUs que um recurso pode usar em base horária, incluindo o nó do driver … Use com range", e cluster_type (all-purpose / job / dlt), que te deixa bloquear uma classe de compute de plano.
• runtime_engine aceita PHOTON ou STANDARD; spark_version aceita os tokens auto:* (seção 1); workload_type.clients.jobs / .notebooks controlam qual tipo de cliente pode anexar.
• Armadilha da API: "Default values don't automatically get applied to compute created with the Clusters API. To apply default values using the API, add the parameter apply_policy_default_values … set it to true."
• Apagar uma policy não limpa nada: o compute em execução continua, mas "cannot be edited unless the user has unrestricted cluster creation permissions."

6.1 Exemplo resolvido E4: uma policy de guardrail de custo só para jobs

Construída sobre o próprio exemplo só-para-jobs da documentação (página policy-definition, 1 de outubro de 2026) e estendida com Photon, topologia de spot e tags. Este é o JSON que você colaria em um recurso databricks_cluster_policy do Terraform ou na UI de admin:

---

7. Bibliotecas e postura do notebook

7.1 Quatro escopos, uma matriz de origem

(docs .../libraries, última atualização em 11 de setembro de 2026)

Origens: PyPI, Maven, CRAN, arquivos do workspace, volumes do Unity Catalog, armazenamento de objetos da nuvem. As linhas de corte em out 2026:

• O modo de acesso padrão precisa de DBR 13.3 LTS+ para PyPI, Maven, volumes e arquivos do workspace; "CRAN: Not supported" no modo de acesso padrão (dedicated/legacy o mantêm).
• Python eggs apenas em "Databricks Runtime 13.3 LTS and below"; requirements.txt precisa de DBR 15.0+.
• "storing library files in the DBFS root is deprecated and disabled by default in Databricks Runtime 15.1 and above": use arquivos do workspace, volumes do UC ou repositórios de pacotes.
• "Bibliotecas de workspace foram descontinuadas e não devem ser usadas": note que os arquivos de workspace continuam totalmente suportados.
• Precedência de import do Python (maior primeiro): cwd da pasta Git → raiz da pasta Git → vinculado ao notebook (%pip) → vinculado ao compute → bibliotecas incluídas no DBR.

Ergonomia de notebook que vale decorar: "%pip, Install Python packages (notebook-scoped)" mas "%pip não reinicia automaticamente o processo do Python … você pode precisar dbutils.library.restartPython()"; "%run, Execute another notebook, importing its functions and variables" e "%run must be in a cell by itself, because it runs the entire notebook inline." Em serverless, %uv pip é a alternativa mais rápida (environment na versão 5+).

7.2 Exemplo resolvido E5: a postura do notebook de produção

• 📚 Você sabia? A orientação de engenharia da Databricks agora diz: "Declarative automation is built on the idea that if something isn't in version control, it doesn't exist" e "Minimize business logic in notebooks … Use notebooks only as thin orchestration and visualization layers that call the underlying code" (docs .../notebooks/best-practices e .../developers/best-practices, ambas com última atualização em 2026-09-11). O repositório companheiro é github.com/databricks/notebook-best-practices.

---

8. Autoscaling, auto-termination e spot

8.1 Horizontal no clássico, vertical do lado serverless

Clusters all-purpose e job clássicos fazem autoscale apenas nos workers, entre autoscale.min_workers e max_workers. O autoscaling otimizado (Premium e acima; workspaces em plano Standard recebem autoscaling padrão) tem quatro características documentadas (docs .../compute/configure, última atualização em 6 de outubro de 2026):

• "Scales up from min to max in at most 2 scaling events."
• "On job compute, scales down if the compute resource is underutilized over the last 40 seconds. On all-purpose compute … 150 seconds." (spark.databricks.aggressiveWindowDownS, até 600 s, retarda essa queda.)
• Ele pode reduzir nós não-ociosos usando o estado dos arquivos de shuffle, então um nó quente-mas-esperando não está protegido.
• O autoscaling padrão em vez disso começa com "+8 nodes, then exponential" e "reduz a escala quando 90% dos nós não estão ocupados por 10 minutos".

Scaling vertical não existe no clássico: "Scale vertically by adding or removing resources from a single machine … This typically means stopping the workload, moving it to a larger machine, and restarting it" (docs.../performance-efficiency, acesso 2026-10). A seleção vertical de instância é uma feature de pipelines serverless: "Vertical autoscaling is used for all serverless pipelines", escolhendo tipos de instância economicamente eficientes com base em evidência de OOM (docs.../ldp/auto-scaling, acesso 2026-10).

Duas armadilhas documentadas: "Do not enable Apache Spark Dynamic Allocation (spark.dynamicAllocation.enabled) on compute resources that use Databricks autoscaling" (executores em conflito → NODES_LOST), e o autoscaling "has limitations scaling down … for Structured Streaming workloads": streams longas querem um piso, não um piso que se move.

8.2 Auto-termination e topologia de spot

Auto-termination mata um all-purpose cluster ocioso depois de autotermination_minutes de inatividade. A API aceita 10 to 10.000 minutos, com 0 desabilitando-o (docs de schema de asset bundle/job da Databricks, acesso 2026-10), e as páginas de docs impressas em outubro de 2026 não trazem nenhum padrão numérico, então defina-o explicitamente em vez de confiar em um valor de UI que você não verificou. Os padrões de auto-stop de SQL warehouse são documentados (seção 4.3): 45 min pro/classic, 10 min serverless.

Spot, da mesma página de configuração de compute: aws_attributes.availability ∈ SPOT / ON_DEMAND / SPOT_WITH_FALLBACK; aws_attributes.first_on_demand fixa o driver (e N nós) em on-demand; aws_attributes.spot_bid_price_percent tem padrão de 100% do on-demand. "A primeira instância será sempre on-demand (o nó do driver é sempre on-demand) e as instâncias subsequentes serão instâncias spot." A AWS precifica o Spot em "up to 90% off On-Demand prices" (aws.amazon.com/ec2/spot, acesso 2026-10) com um aviso de interrupção de dois minutos, e a economia cai apenas na coluna da AWS: as taxas de DBU e as contagens de emissão não mudam com spot.

---

9. Tipos de nós da AWS: famílias, Graviton, fleet e discos

9.1 As famílias

Da documentação de tipos de instância da EC2 (acesso 2026-10): M propósito geral, C otimizado para compute, R otimizado para memória, e D/I otimizado para armazenamento com NVMe local: "Storage optimized instances are designed for workloads that require high, sequential read and write access to very large data sets on local storage" (as classes de família abrangem C5…C9g, R5…R9g, D3/D3en/I3en/I4i/I7i/I8g/Im4gn/Is4gen).

A própria orientação de seleção da Databricks (docs .../cluster-config-best-practices, página datada de 2026-06-11): ETL batch simples que "don't require wide transformations" → "instâncias com requisitos menores de memória e armazenamento"; workloads analíticos "will likely require reading the same data repeatedly, so recommended node types are storage optimized with disk cache enabled or instances with local storage"; e "Para jobs de ETL batch simples … use instâncias spot para workloads com requisitos de latência flexíveis."

9.2 Exemplo resolvido E6: seleção de família de instância para quatro formas de workload

Em outubro de 2026; EC2 Linux on-demand, us-east-1, lido da lista de preços da AWS em 2026-10-12.

Dois fatos de hardware mais que vale levar: os fleet instance types (m-fleet.xlarge, rd-fleet.4xlarge, …) são "a variable instance type that automatically resolves to the best available instance type of the same size" usando o Spot Placement Score da AWS, e "Se você atualizar a porcentagem de lance de instância spot pela API ou JSON, isso não tem efeito quando o tipo de nó worker é um tipo de instância fleet." Tipos fleet não trazem GPUs. A EC2 P2 não é mais suportada (mesma página). Para janelas garantidas de GPU/instância, os Capacity Blocks se anexam pela tag X-Databricks-AwsCapacityBlockId mais uma AZ e apenas on-demand.

---

10. O medidor: mesma instância, fatura diferente

10.1 A tabela de taxas na qual você será cobrado

Lista US, plano Premium, AWS, em outubro de 2026: fontes documentais (as próprias páginas de preços da Databricks renderizam no cliente; esses números vêm do registro de fornecedor UK G-Cloud 15 capturado em 2026-09-25 mais seis leituras independentes da mesma tabela de taxas datadas entre 2026-06-03 e 2026-10-06, e são corroborados para SQL por snapshots de página do databricks.com). Confirme na sua conta com system.billing.list_prices antes de orçar:

Três regras em torno dessa tabela:

1. Região: as taxas clássicas são planas em todas as regiões AWS (de qualquer forma você paga EC2 local); as taxas serverless não são: SQL Serverless é $0.70/DBU em us-east-1 contra $0.91 em eu-central-1 (leitura de page-data, 2026-08-07). Uma cotação dos EUA nunca se transfere para Frankfurt.
2. O Standard tier acabou. "Databricks has announced end-of-life for the Standard tier. All current Standard tier workspaces will be upgraded to the Premium tier effective October 1, 2025 on AWS and GCP", então a velha taxa de jobs de $0.10 é história (databricks.com/product/pricing/lakeflow-jobs, acesso 2026-10).
3. Duas faturas no clássico, uma no serverless. Clássico = DBUs + EC2/EBS na sua conta; serverless embute a máquina no DBU. system.billing.usage contém apenas o lado Databricks: "O system.billing.usage contém apenas os custos da Databricks … o gasto de infraestrutura em nuvem não está incluído e precisaria ser revisado pelo console de nuvem correspondente" (blog, 2026-09-22).

10.2 Atribuição: dê um endereço a cada DBU

system.billing.usage (página datada de 2026-07-23) traz sku, usage_type, product_feature, workspace_name, region, tags, run_as, metered_quantity, list_price e unblended_cost, "When a classic compute resource's driver and worker nodes use different instance types, their usage appears as separate records". Agrupe por sku + run_as e você vê exatamente quanto do seu parque está em All-Purpose versus Jobs. Um limite para lembrar quando montar o dashboard: as consultas de atribuição de custo de job "only calculate costs for jobs run on jobs compute and serverless compute. Jobs run on SQL warehouses and all-purpose compute are not billed as jobs" (docs.../system-tables/jobs-cost, acesso 2026-10). E os budgets (até 1.000 por conta, 4 thresholds cada, em USD a preço de lista) monitoram o gasto, eles não o limitam (doc de budgets, 2026-10-07).

---

11. As armadilhas: catorze confusões que esta lição não vai deixar você manter

1. "LTS é o número com .x." Em outubro de 2026 o 18 LTS é suportado (até 2029-06-10) enquanto o 18.0 está em EoS. Fixe spark_version na linha LTS.
2. "auto:latest-lts mantém meus clusters atualizados." Ele resolve quando o compute é editado, não continuamente: clusters em execução não se atualizam sozinhos.
3. "Nossos clusters criados por API estão no Photon." Só se runtime_engine for "PHOTON", o padrão da UI não viaja para a Clusters/Jobs API.
4. "O Photon vai consertar meu dashboard de 100 ms." "Queries that normally complete in under two seconds don't see meaningful improvement."
5. "O Photon faz tudo o que o Spark faz." Sem UDFs, sem APIs RDD/Dataset, sem streaming stateful; o fallback é por operação e silencioso.
6. "Um job em um all-purpose cluster existente é a opção barata." Ele é cobrado na precificação de All-Purpose (interativo) e classificado como interativo: 3.7× a taxa por DBU na lista dos EUA.
7. "Pools são grátis." 0 DBUs enquanto ocioso, mas as cobranças de instância da AWS continuam; defina min_idle_instances de propósito.
8. "Workers em spot, driver em spot." Nunca: driver sempre on-demand (first_on_demand >= 1), e o spot só abate a coluna da AWS.
9. "Dynamic Allocation + autoscaling da Databricks = mais segurança." Explicitamente advertido contra: churn de executores e NODES_LOST.
10. "Memória maior = nó maior, sem reinício." Clusters clássicos não têm autoscaling vertical; mudar o tipo de nó significa reinício.
11. "Os padrões da policy se aplicam automaticamente." Não via Clusters API: você precisa passar apply_policy_default_values: true.
12. "Apagamos a policy, então o gasto parou." O compute existente continua rodando e fica não-editável (exceto para usuários unrestricted).
13. "%pip install no notebook significa que o job tem o pacote." Bibliotecas vinculadas ao notebook "do not persist": declare deps em nível de task/cluster/environment.
14. "A taxa de DBU é meu custo total." No clássico ela é metade da fatura; a metade do EC2/EBS/NAT/S3 vive só no AWS Cost Explorer.

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

📋 Caso A: Comcast (comunicações e mídia, Cloud: AWS) Desafio. Petabytes de telemetria e bilhões de interações de voz de mais de 20 milhões de remotes de voz; pipelines frágeis e dor de ingestão de arquivos pequenos, com centenas de modelos implantados em nuvem, on-prem e edge. Stack na AWS. Databricks com Delta Lake para ingestão e otimização de arquivos pequenos, MLflow gerenciado e autoscaling com instâncias spot: Cloud: AWS na página da história (https://www.databricks.com/customers/comcast, página sem data, acesso em 2026-10); também listada entre os clientes "already leveraging Databricks on AWS" (https://www.databricks.com/company/newsroom/press-releases/databricks-strengthens-scope-of-work-with-aws, 2022-05-10). Resultado relatado. "Redução de 10x nos custos gerais de compute para processar dados · Redução de 90% nos recursos de DevOps necessários"; "Delta Lake has enabled Comcast to optimize data ingestion, replacing 640 machines with 64 while improving performance" (https://www.databricks.com/customers/comcast, sem data, acesso em 2026-10; origem da história em 2019). Como mapeia para esta lição. Seções 8 to 10: workers spot mais autoscaling horizontal e right-sizing estrutural são exatamente as alavancas do exemplo resolvido E2: a economia veio de qual forma de compute rodava o trabalho, não de um desconto. ⏳ Nota temporal: uma história de origem de 2019 ainda exibida em 2026: ensine-a como o que a Comcast relatou na época, não como um 10× garantido.

📋 Caso B: Addepar (gestão de patrimônio, Cloud: AWS) Desafio. Times de engenharia e de dados em silos, entrega de pipeline lenta e custo de infraestrutura crescente em uma plataforma que modela mais de US$ 8 trilhões em investimentos. Stack na AWS. Databricks rodando na AWS com Unity Catalog, notebooks compartilhados e Databricks SQL: tag Cloud: AWS na página da história. Resultado relatado. "A Addepar modela mais de US$ 8 trilhões em investimentos no Databricks rodando na AWS. Notebooks compartilhados, Unity Catalog e acesso colaborativo a dados juntam os times de engenharia e de dados em um só lugar, acelerando a entrega de pipelines em 5x e cortando custos de infraestrutura em US$ 2 milhões" (https://www.databricks.com/customers/addepar/aws, página sem data, acesso em 2026-10). Como mapeia para esta lição. Seções 6 e 10: uma redução de US$ 2 milhões em infraestrutura com velocidade de entrega 5× é o que "governança e padronização de compute" parecem em uma fatura: compute compartilhado e governado por policy vence o sprawl de um-cluster-por-notebook, que é o problema de personal-compute policy da seção 6 resolvido em escala de empresa. ⏳ Nota temporal: página sem data, acesso em out 2026; os US$ 2 milhões são custo de infraestrutura, não custo de DBU.

---

---

Perguntas de Prática (Practice Questions)