Otimização de Desempenho na Databricks/AWS: Liquid Clustering, Layout de Arquivos, Skew e Ajuste de Warehouse

Consultas lentas no lakehouse quase nunca são "o Spark é lento". Elas são uma camada específica se comportando mal: arquivos pequenos demais no S3, uma coluna de filtro cujos intervalos min/max se sobrepõem em todos os arquivos, uma única chave de join quente carregando 38% das linhas, ou um warehouse com o tamanho certo e a quantidade errada. Esta lição ensina a pilha na ordem em que você deve consertá-la, disposição → estatísticas → planejamento/runtime → serving, e ela ensina a versão de 2026 dessa pilha, não a de 2019.

Essa distinção importa mais do que qualquer knob isolado. A documentação atual da Databricks é direta: "A Databricks recomenda usar liquid clustering em vez de partições, ZORDER ou outras abordagens de disposição de dados" (docs .../tables/operations/optimize, última atualização 2026-03-31, espelho 2026-09-11), e "Recomendações de ajuste manual não se aplicam a tabelas gerenciadas do Unity Catalog, que usam ajuste automático de tamanho de arquivo" (docs .../tables/tune-file-size, 2026-09-11). Enquanto isso, a camada do motor continua se auto-ajustando: AQE está ativo por padrão desde o DBR 7.3, Photon é o motor de execução padrão nos SQL warehouses da Databricks, e a Databricks relata que "em 2025, o Databricks SQL entregou desempenho até 40% mais rápido em cargas de trabalho de produção, com melhorias aplicadas automaticamente" (blog, 2026-01-28).

Então o enquadramento honesto para outubro de 2026 é: o ajuste manual é mais valioso em tabelas externas, cargas de trabalho legadas de hive-metastore e clusters fora do padrão, e entender qual camada está quebrada antes de mexer em qualquer coisa. Cada fato desta lição vem das páginas de documentação AWS da Databricks sobre optimize, tamanho de arquivo, partições, clustering, data skipping, AQE, hints, predictive optimization, caching, comportamento de warehouse e query profile (todas acessadas ou datadas em outubro de 2026), além de blogs datados de engenharia da Databricks. Nenhuma taxa de DBU aparece aqui, custo é o assunto da lição 15.

Nesta lição você vai:

• percorrer a pilha de quatro camadas e aprender qual sintoma pertence a qual camada antes de tocar em uma única configuração;
• dimensionar arquivos contra os três alvos oficiais, 128 MB do auto-optimize, a faixa de autotune de 256 MB → 1 GB e o teto manual de OPTIMIZE de 1 GiB, e calcular as contagens de arquivo na mão;
• aplicar a escada de particionamento (< 1 TB nunca · 1 to 100 TB clustering · ≥ 100 TB talvez) e a proteção de ≥ 1 GB por partição, e então ver o anti-padrão de alta cardinalidade falhar na aritmética;
• ir a fundo no liquid clustering: CLUSTER BY, CLUSTER BY AUTO, ≤ 4 chaves, limiares de clustering na escrita, OPTIMIZE incremental vs OPTIMIZE FULL, chaves hierárquicas, idempotência do bin packing e os pisos de DBR com as suas datas;
• rodar uma comparação resolvida de OPTIMIZE vs CLUSTER BY, a mesma tabela de 8 TB, o SQL legado de partição+ZORDER ao lado do SQL de liquid clustering, e ler o gráfico de latência antes/depois;
• diagnosticar skew de join a partir de evidência real de profile e subir a escada documentada: hint de broadcast → split de skew do AQE → salting, com a trilha dos consertos errados ao lado;
• configurar o AQE com os padrões verificados (200 partições de shuffle, broadcast de 30 MB em runtime, advisory de 64 MB, fator de skew 5×);
• julgar o Photon por carga de trabalho, onde ele vence, onde Python UDFs o derrotam, e dimensionar um Databricks SQL warehouse com a doutrina de resize-vs-scale mais os níveis de cache;
• fazer profiling como operador: o query profile para warehouses, a Spark UI para clusters, e um cálculo de partições de shuffle que você faz no papel;
• estudar três histórias nomeadas de desempenho de clientes na AWS, ler a caixa de atualização de 2026 e praticar com doze questões no estilo de exame mais quatro verificações interativas.

---

1. A pilha de quatro camadas, e como escolher uma camada

Toda latência de consulta deste curso é decidida em quatro camadas, nesta ordem. Conserte-as de cima para baixo e meça de novo após cada mudança: nunca duas mudanças de uma vez, ou você não consegue atribuir o ganho.

Duas realidades de 2026 remolduram essa tabela. Primeiro, as camadas 3 e 4 cada vez mais se auto-ajustam: AQE está ligado por padrão (spark.databricks.optimizer.adaptive.enabled = true), Photon roda por padrão nos SQL warehouses da Databricks, e as tabelas gerenciadas ganham ajuste automático de tamanho de arquivo. Segundo, a camada 2 não tem teto em tabelas gerenciadas: para tabelas externas do Unity Catalog, as estatísticas são coletadas nas primeiras 32 colunas; em tabelas gerenciadas da UC, "o predictive optimization coleta estatísticas de pulsação de arquivo nas colunas mais usadas nos seus filtros de consulta, em vez de um conjunto fixo de colunas, de modo que essas tabelas não têm limite de 32 colunas" (docs .../tables/data-skipping, 2026-06-18).

O resto desta lição é essa pilha, camada por camada.

---

2. Camada 1: dimensionamento de arquivos e o problema dos arquivos pequenos no S3

Arquivos pequenos machucam porque cada arquivo custa um round-trip de LIST/GET do S3, uma task do Spark e a análise do rodapé do Parquet. Como o próprio guia da Databricks coloca, parte do custo é simplesmente "o tempo gasto só para abrir e fechar esses arquivos minúsculos" (guia discover, 2026-05-06). No S3 não existe camada de bloco: o arquivo é a unidade de paralelismo, a unidade de estatísticas e a unidade que o VACUUM recupera.

2.1 Três alvos oficiais, uma faixa saudável

Três números diferentes são todos "oficiais", e ensiná-los como um número só é o clássico erro de tutorial desatualizado:

Duas consequências que evitam os dois erros de layout mais comuns:

1. 1 GiB é um teto, não uma meta para tabelas pequenas. Compactar uma tabela de 300 GB em arquivos de 1 GiB deixa ~300 arquivos e destrói o paralelismo do scan podado.
2. Aumentar um alvo nunca mescla nada por si só. "Quando o tamanho de arquivo alvo de uma tabela cresce, os arquivos existentes não são re-otimizados em arquivos maiores pelo comando OPTIMIZE" (tune-file-size, 2026-09-11): você precisa rodar OPTIMIZE depois.

2.2 Exemplo resolvido E1: como é a saída de 8 TB de Auto Loader

A lição de E1 não é a faixa de 15 to 25×; é que contagem de arquivo e forma do arquivo são números diferentes. Uma média de 440 MB com mediana de 20 MB significa que o motor ainda paga o overhead de uma task por arquivo na maior parte da tabela.

2.3 Três mecanismos combatem arquivos pequenos, em ordem crescente de autoridade

1. Escritas otimizadas (autoOptimize.optimizeWrite / spark.databricks.delta.optimizeWrite.enabled) fazem shuffle antes de escrever para que cada partição emita arquivos de ~128 MB. Elas estão ligadas por padrão para MERGE, UPDATE/DELETE com subconsultas, CTAS/INSERT em SQL warehouses, e "No Databricks Runtime 13.3 LTS e superior, todas as tabelas registradas no Unity Catalog têm escritas otimizadas habilitadas para instruções CTAS e operações INSERT em tabelas particionadas". O custo é real: "Gravar menos arquivos grandes é mais eficiente … mas você ainda pode ver um aumento na latência de escrita porque os dados são embaralhados antes de serem gravados."
2. Auto compaction (autoOptimize.autoCompact) "roda sincronamente no cluster que faz a escrita, depois que a escrita tem sucesso, e só compacta arquivos que ainda não foram compactados antes". No histórico da tabela ela aparece como uma operação OPTIMIZE com operationParameters.auto = true. Para MERGE, UPDATE e DELETE ela é obrigatória: "Você não pode desligar essa funcionalidade."
3. OPTIMIZE agendado ou previsto: "Para tabelas maiores que 1 TB, a Databricks recomenda rodar OPTIMIZE em um agendamento", clássicamente "diariamente, de preferência à noite, quando os preços de spot estão baixos" e em um job cluster separado, e para tabelas quentes com liquid clustering, "agendar um job OPTIMIZE a cada uma ou duas horas" (docs de clustering, 2026-09-25), porque o clustering é incremental e a maioria das execuções é rápida.

Auto compaction e escritas otimizadas "não substituem completamente o OPTIMIZE" (tune-file-size, 2026-09-11), e se o predictive optimization estiver habilitado, "a Databricks recomenda desabilitar quaisquer jobs OPTIMIZE agendados" para você parar de pagar duas vezes (docs de clustering).

⚠️ AVISO, não brigue com o caminho de escrita usando as próprias mãos. "Se você usa escritas otimizadas, a Databricks recomenda que você não rode coalesce(n) ou repartition(n) imediatamente antes de uma escrita para controlar a quantidade de arquivos gravados" (tune-file-size, 2026-09-11), você paga dois shuffles para um trabalho só. Igualmente: nunca desligue a auto compaction no nível de sessão e esqueça. Ela não pode ser desabilitada para MERGE/UPDATE/DELETE, mas um false no nível de sessão desliga silenciosamente ela para appends e CTAS nessa carga de trabalho.

• 📚 Você sabia? O OPTIMIZE é seguro por construção: "A otimização de bin-packing é idempotente, ou seja, se ela rodar duas vezes no mesmo dataset, a segunda execução não tem efeito", e "Como o OPTIMIZE não faz nenhuma mudança de dados na tabela, uma leitura antes e depois de um OPTIMIZE tem os mesmos resultados. Rodar OPTIMIZE em uma tabela que é fonte de streaming não afeta nenhuma stream atual ou futura com essa tabela como fonte" (docs.../operations/optimize, 2026-03-31). O ZORDER, por contraste, nunca foi idempotente: era incremental e precisava ser reexecutado.

---

3. Camada 1, particionamento: a escada e a proteção de ≥ 1 GB

A orientação atual de particionamento é mais nova do que a maioria dos tutoriais e mais direta do que a maioria dos times espera: "A maioria das tabelas na Databricks com menos de 100 TB de dados não precisa de particionamento" (docs .../tables/partitions, 2026-07-01).

A segunda proteção é por partição: "verifique que cada partição contém pelo menos 1 GB de dados. Tabelas com menos partições e maiores tendem a superar tabelas com muitas partições menores" (mesma página). Contagem de partição é contagem de diretórios no seu bucket, então cada nível extra de cardinalidade multiplica chamadas LIST, entradas de _delta_log, varreduras de planejamento do OPTIMIZE e superfície de conflito do MERGE.

Não particione quando: a tabela estiver abaixo de 1 TB; a coluna de filtro tiver alta cardinalidade (user_id, event_id: clusterize em vez disso); os padrões de acesso mudarem (o particionamento "é estático e se manifesta como uma hierarquia de sistema de arquivos. Não existe um jeito fácil de mudar partições", página de best practices); a coluna for um timestamp que explodir em milhões de instantes (clusterize o timestamp bruto no lugar disso); ou você fosse particionar por um campo struct (PARTITIONED BY trata um struct como expressão, não como referência de coluna).

3.1 Exemplo resolvido E2, o anti-padrão de alta cardinalidade, em aritmética

O particionamento mantém exatamente dois papéis legítimos em 2026: movimentos de ciclo de vida por partição (DELETE/DROP PARTITION em uma coluna de data em escala ≥ 100 TB) e filtro de partição do Delta Sharing em tabelas compartilhadas: que é também o motivo de converter uma tabela compartilhada particionada para clustering ser bloqueado.

---

4. Liquid clustering, a fundo

"O liquid clustering é uma técnica de otimização de disposição de dados que substitui o particionamento da tabela e o ZORDER" (docs .../tables/clustering, última atualização 2026-09-25), e "você pode redefinir as chaves de clustering sem reescrever os dados existentes". Essa última cláusula é o design inteiro: o particionamento assenta uma hierarquia de sistema de arquivos que você não consegue mudar barato; o clustering guarda um conjunto declarado de chaves nos metadados da tabela e deixa o OPTIMIZE colocar fisicamente os intervalos juntos de forma incremental.

4.1 A superfície de declaração e os pisos de DBR

Carregue esses números de versão com as suas datas: são os números que provas e revisões de arquitetura perguntam:

4.2 Clustering na escrita: como o streaming aterrissa pré-clusterizado

Você não precisa esperar por um job noturno. Quando a escrita é grande o suficiente, o clustering roda durante a escrita, por contagem de chaves (tabelas gerenciadas da UC / outras tabelas Delta):

É por isso que um CTAS ou um micro-batch de streaming pode aterrissar fisicamente clusterizado sem nenhum manutenção agendada, e é por isso que o OPTIMIZE em uma tabela clusterizada costuma ser rápido: ele só reescreve o que ainda precisa de clustering.

4.3 O ciclo de vida, incluindo os dois momentos caros

Dois momentos nesse diagrama custam dinheiro de verdade e tempo de calendário de verdade:

⚠️ AVISO: declarar chaves é grátis; fazer dados antigos baterem com elas não é. "O comportamento padrão não aplica clustering a dados escritos anteriormente": você precisa rodar OPTIMIZE <table> FULL, o que "pode levar horas" em uma tabela grande não clusterizada (docs de clustering, 2026-09-25). Orce isso como um job de migração único, no seu próprio cluster (instâncias compute-optimized, spot à noite), não como uma etapa de um pipeline de release. E nunca afirme "habilitar o clustering reescreveu a minha tabela": ALTER TABLE … CLUSTER BY é metadado; o OPTIMIZE FULL é a reescrita.

⚠️ IMPORTANTE, o OPTIMIZE reescreve arquivos, então ele alimenta o VACUUM. Toda reclusterização apaga e adiciona arquivos; as versões antigas sobrevivem apenas durante delta.deletedFileRetentionDuration (padrão de 7 dias). Defina essa propriedade antes de habilitar o predictive optimization: "Se você definir delta.deletedFileRetentionDuration para menos de 7 dias, o predictive optimization ainda retém os arquivos de dados por um mínimo de 7 dias quando roda VACUUM FULL" (docs de predictive optimization, 2026-09-11), e nunca rode VACUUM na mesma etapa de job que leitores ou streams de longa duração.

4.4 Exemplo resolvido E3: adotando clustering em uma tabela em produção

Por que um predicado no passo 4/5? OPTIMIZE <table> WHERE <predicate> limita a compactação/reclusterização a um subconjunto: mais barato, e ele encolhe a janela de conflito com escritores concorrentes, o mesmo motivo pelo qual as best practices empurram predicados de poda para dentro do MERGE... ON.

• 📚 Você sabia? O DESCRIBE HISTORY também é a sua trilha de auditoria de manutenção: a auto compaction, o liquid clustering e o Z-ordering "aparecem todos no histórico da tabela como operações OPTIMIZE", e você só os distingue através de operationParameters.{auto, clusterBy, zOrderBy, predicate} (docs.../tables/history, 2026-09-11). Um dashboard que conta "execuções de OPTIMIZE" portanto superconta a auto compaction em larga margem: filtre por auto = 'false' para as execuções manuais.

---

5. Exemplo resolvido E4: OPTIMIZE vs CLUSTER BY, lado a lado

Mesma tabela, mesmos 8 TB, duas gerações de doutrina de layout. É essa a comparação para a qual a lição existe.

O que mudou entre os dois caminhos:

Leia esse gráfico como uma escada causal: escritas otimizadas e bin packing (camada 1, tamanho de arquivo) compram um ganho sólido mas limitado porque a poda ainda não consegue provar nada; CLUSTER BY (camada 1 + camada 2 juntas) é o que faz o filtro de customer_id excluir >95% dos arquivos. A última barra é rotulada como ilustrativa porque é um esboço de arquitetura de referência restrito à faixa publicada de leitura de 2 to 12× da Databricks, não um número da sua tabela: meça a sua no query profile.

5.1 Camada 2: por que o clustering é o que faz o skipping funcionar

O Delta grava estatísticas por arquivo no momento do commit: "valores mínimo e máximo, contagens de nulos e total de registros" (docs de data skipping, 2026-06-18), e no momento da consulta o motor pula qualquer arquivo cujas estatísticas provem que o predicado não pode casar. O clustering não muda o que pode ser pulado, "o modelo poda em granularidade de arquivo. Não existe um atalho em nível de diretório para perder" (blog da Databricks, 2026-01-06), ele muda quanto é pulado, ao deixar os intervalos da chave fisicamente contíguos.

O skipping falha silenciosamente quando: o predicado não é sargable (WHERE lower(col) = …, WHERE date_add(col, 1) = …); a coluna de filtro não tem estatísticas; os valores são distribuídos de forma uniforme por todos os arquivos; ou você combina colunas de um jeito que o min/max não consegue provar. Knobs de estatísticas: delta.dataSkippingNumIndexedCols (posicional) e delta.dataSkippingStatsColumns (DBR 13.3 LTS+, lista explícita, substitui o numérico), e "atualizar essas propriedades não recalcula automaticamente as estatísticas dos dados existentes". Por fim: "A Databricks recomenda que você não use ZORDER BY em colunas que não têm estatísticas coletadas, porque isso é ineficaz e usa recursos de computação desnecessários."

---

6. Camada 3, joins: AQE, broadcast, skew e salting

6.1 Os padrões do AQE com os quais você realmente está rodando

O AQE está ligado por padrão e faz quatro coisas: converter sort-merge join em broadcast em runtime, coalescer partições pós-shuffle, dividir (e, se necessário, replicar) partições enviesadas, e propagar relações vazias (docs de AQE, página datada de 2023-10-12, ainda atual em out 2026).

Regra prática para dimensionar o shuffle: "cada task deveria processar aproximadamente 128MB a 200MB de dados" (guia discover, 2026-05-06). E mantenha o AQE ligado: "É recomendado manter o AQE habilitado" (best practices, 2026-09-11).

6.2 Exemplo resolvido E5: um join noturno de 52 minutos, diagnosticado

A trilha dos consertos errados: os três aparecem em código de produção e nenhum deles ajuda:

• SET spark.sql.shuffle.partitions = 2000: não divide nada; a chave quente ainda cai em exatamente uma partição.
• .repartition("cust_id"): a mesma falha, mais um shuffle extra.
• Um hint de skew quando o AQE já disparou: overhead para um conserto que já aconteceu; "A otimização de skew join tem algum overhead, então é melhor usá-la só quando necessário" (docs aposentadas de skew-join, página atualizada em 2024-05-13).

• 📚 Você sabia? Você lê as decisões do AQE direto do plano físico: CustomShuffleReader com a propriedade Coalesced significa que as partições foram mergeadas após o shuffle, SortMergeJoin com isSkew=true significa que o AQE dividiu uma partição quente, e um LocalTableScan significa que o AQE provou um lado do join vazio e cortou o caminho (docs de AQE, 2023-10-12). Três strings que valem grepar no plano de qualquer consulta lenta antes de você mudar uma única configuração.

---

7. Photon: julgue-o pela carga de trabalho, não pelo slogan

Photon é o motor vetorial em C++ que processa dados em lotes colunares, e "o Photon é usado por padrão nos SQL warehouses da Databricks" (best practices, 2026-09-11). A evidência publicada, com as suas ressalvas:

Os vereditos por carga de trabalho:

• SQL pesado / BI / dashboards: os maiores ganhos (scans, joins e agregações vetorizados). Já ligado por padrão nos SQL warehouses.
• ETL / Spark batch: sólido, porém menor; caminhos dominados por MERGE são dominados no lugar pelo low shuffle merge (GA desde o DBR 10.4 LTS, "até 5x … em média na ordem de 2-3x").
• Código com muito Python e UDFs, o Photon não consegue acelerar a execução de Python UDFs: "Serialização é necessária para transferir dados entre Python e Spark. Isso desacelera significativamente as consultas" (best practices). O movimento vencedor é reescrever em SQL nativo (ou pandas UDFs se uma UDF for inevitável) primeiro, Photon depois. (Este é um raciocínio a partir da orientação documentada de UDFs, não um benchmark de Python publicado.)
• Loops de treino de ML construídos sobre RDDs/gráfico/código próprio, o Photon é em grande parte irrelevante ali.

---

8. Camada 4: dimensionamento de warehouse e os níveis de cache

8.1 Resize vs scale out: dois sintomas, dois knobs

A doutrina de dimensionamento da Databricks (docs de comportamento de warehouse, acessados em 2026-10; blog de alta concorrência, 2025-02-09): resize (aumentar o tamanho) quando as consultas precisam de mais memória por consulta (agregações, joins multi-tabela: observe o spill de disco); scale out (adicionar clusters) quando as consultas esperam (observe a fila). "Se as consultas estão fazendo spill para disco, aumente o tamanho do cluster. Verifique os spills no query profile." Warehouses clássicos e pro têm "um limite fixo de um cluster para cada 10 consultas simultâneas", a profundidade da fila é limitada com dureza em 1.000 consultas para todo tipo de warehouse, e um limiar prático de alerta é pico de consultas enfileiradas > 10 que não resolve quando o autoscaling dispara.

8.2 Exemplo resolvido E6: dimensionando um warehouse de 60 analistas

Para a maioria das cargas de trabalho "a Databricks recomenda usar um SQL warehouse serverless", e o conselho de dimensionamento dele é contraintuitivo mas correto: "Comece com um único warehouse maior e deixe os recursos serverless gerenciarem concorrência e desempenho. Geralmente é mais eficiente reduzir o tamanho se necessário do que começar pequeno e escalar para cima."

8.3 Quatro caches, quatro vidas úteis

Regras que evitam os bugs clássicos de cache: cache de resultado precisa de consultas determinísticas, um predicado no estilo NOW() nunca atinge ele; SET use_cached_result = false o contorna (só para teste/benchmark); o cache de disco "funciona por padrão com todos os tipos de instância que têm SSDs locais", e em compute clássico isso significa escolher workers com SSD; "Nos SQL warehouses e no Databricks Runtime 14.2 e superior, o comando CACHE SELECT é ignorado", o disk cache aprimorado é usado no lugar dele.

⚠️ AVISO, o cache do Spark é a armadilha, não o padrão. "usar locais incorretos em uma consulta pode consumir toda a memória disponível e desacelerar significativamente as consultas. Como regra prática, evite o cache do Spark" (best practices, 2026-09-11), e a página de best practices do Delta diz sem rodeios "Não use o cache do Spark com o Delta Lake" (atualizada em 2026-09-11). DataFrames cacheados comem memória de executor que shuffle e joins depois despejam em disco, a assinatura reveladora é spill subindo enquanto a aba Storage mostra grandes blocos cacheados. Os usos legítimos são estreitos: um dataset não-Delta verdadeiramente imutável e escaneado repetidamente dentro de uma única sessão, sempre pareado com unpersist(); além do prewarming de um cluster frio antes da correria da manhã.

• 📚 Você sabia? O disk cache é o Delta cache renomeado: "O disk cache (antes conhecido como 'Delta cache') guarda cópias de dados remotos nos discos locais (por exemplo, SSD) das máquinas virtuais… A maneira recomendada (e mais fácil) de usar disk caching é escolher um tipo de worker com volumes SSD" (best practices, 2026-09-11). E como o autoscaling descomissiona workers, "se o autoscaling está habilitado, há alguma instabilidade com o cache": job clusters sensíveis a cache querem scale-down conservador ou pools.

---

9. Profiling: o query profile e a Spark UI

Profiling é o que faz a pilha virar um loop em vez de uma lista de verificação. Escolha a ferramenta pelo tipo de compute: query profile para SQL warehouses e serverless, Spark UI para clusters clássicos e de jobs.

O que cada sinal diz, e a única resposta documentada:

Dois detalhes de acesso que economizam um ticket de suporte: acessar o profile exige dono da consulta "ou pelo menos a permissão CAN MONITOR no SQL warehouse", e "Um query profile não está disponível para consultas que rodam a partir do cache de consulta. Para contornar o cache de consulta, faça uma mudança trivial na consulta, como mudar ou remover o LIMIT."

9.1 Exemplo resolvido E7: dimensionando spark.sql.shuffle.partitions no papel

Uma ressalva de streaming: spark.sql.shuffle.partitions "não pode ser alterado entre reinicializações de consulta a partir da mesma localização de checkpoint" (docs de AQE): escolha-o antes do primeiro start de uma streaming query.

• 📚 Você sabia? Uma consulta servida pelo result cache não tem query profile nenhum: "Query profile is not available" na UI geralmente significa a sua consulta foi rápida porque estava cacheada, não que o profiling está quebrado. Durante benchmarks, SET use_cached_result = false (docs.../query-caching, acessado em 2026-10), e mantenha o nondeterminismo no estilo NOW() fora das consultas de BI que você quer cacheadas em produção.

---

10. A camada de automação: predictive optimization e materialized views

Dois recursos de 2026 tiram trabalho do seu runbook, mas só se você souber o que eles substituem.

Predictive optimization "roda automaticamente OPTIMIZE, VACUUM e ANALYZE em tabelas gerenciadas do Unity Catalog (Delta Lake e Iceberg)", está "habilitado por padrão para contas criadas em ou depois de 11 de novembro de 2024" com o rollout gradual das contas existentes "esperado para ser concluído até agosto de 2026", roda em compute serverless cobrado como um SKU de jobs serverless, e, a pegadinha, "o OPTIMIZE não roda ZORDER quando executado pelo predictive optimization. Em tabelas que usam Z-order, o predictive optimization ignora arquivos Z-ordered." Ele se aplica apenas a tabelas gerenciadas; tabelas externas continuam com a escada manual das seções 2 to 4. Observe-o com DESCRIBE TABLE EXTENDED … AS JSON → predictive_optimization_evaluations, o filtro "Automatic runs" do Catalog Explorer History, ou system.storage.predictive_optimization_operations_history.

Materialized views são a contraparte da camada de serving: "uma view onde resultados pré-computados ficam disponíveis para consulta e podem ser atualizados para refletir mudanças na entrada. Todas as materialized views são suportadas por um pipeline de ETL", criadas "usando um SQL warehouse Pro ou Serverless, ou dentro de um pipeline", atualizadas por pipelines serverless do Lakeflow, com a saída cacheada materializada em armazenamento de nuvem. A elegibilidade para refresh incremental é verificável antes de você commitar: EXPLAIN CREATE MATERIALIZED VIEW … (DBR 17.3+) relata "a Materialized View pode ser atualizada de forma incremental" ou não: um filtro/projeção/agregação sobre Delta se qualifica, LIMIT e fontes não-Delta (INPUT_NOT_IN_DELTA) não se qualificam, e uma expectation dentro da definição força um refresh completo. Tanto materialized views quanto streaming tables aceitam liquid clustering: "O liquid clustering se aplica a streaming tables e materialized views."

---

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

1. "O tamanho de arquivo alvo é 1 GiB." O OPTIMIZE manual bate no teto de 1 GiB; o auto-optimize mira 128 MB; o autotune escolhe 256 MB abaixo de 2,56 TB. Compactar uma tabela de 300 GB em arquivos de 1 GiB prejudica o paralelismo do scan podado.
2. Assumir que tabelas gerenciadas precisam de rituais manuais de OPTIMIZE. Autotune + predictive optimization são donos delas; um job cron noturno paga duas vezes.
3. Particionar uma tabela de 50 GB "por desempenho." Abaixo de 1 TB você não deveria particionar de forma alguma, e toda partição precisa de ≥ 1 GB.
4. ZORDER em uma coluna sem estatísticas, ou esperar que tabelas com ZORDER continuem mantidas sob o predictive optimization ("ignora arquivos Z-ordered").
5. Mudar chaves de clustering e esperar resultado instantâneo. Você precisa do OPTIMIZE FULL, e ele "pode levar horas" em uma tabela grande não clusterizada.
6. Chaves de clustering em excesso / de cardinalidade alta demais. Máximo de 4; abaixo de 10 TB chaves extras degradam filtros de coluna única; chaves hierárquicas devem ser de baixa cardinalidade.
7. A interação VACUUM ↔ clustering. Toda reclusterização apaga e adiciona; defina delta.deletedFileRetentionDuration antes de habilitar o predictive optimization (piso de 7 dias) e nunca faça vacuum junto com leitores de longa duração.
8. coalesce(n)/repartition(n) logo antes de uma escrita com escritas otimizadas ligadas: dois shuffles, um job.
9. Um autoOptimize.autoCompact = false no nível de sessão que você esqueceu: obrigatório para MERGE/UPDATE/DELETE, silenciosamente desligado para os seus appends.
10. spark.sql.shuffle.partitions = 2000 "porque o padrão é baixo demais." A regra é 128 to 200 MB por task; com AQE prefira auto ou comece alto e deixe a coalescência mergear.
11. Ir direto para um hint de skew quando o AQE já trata disso, ou salting antes de tentar broadcast. Se um dos lados couber em 10/30 MB, um hint BROADCAST apaga o shuffle: estritamente melhor do que dividi-lo.
12. Abuso do cache do Spark. "Como regra prática, evite o cache do Spark"; "Não use o cache do Spark com o Delta Lake".
13. Confusão com o result cache durante o debug. Uma consulta cacheada não tem profile; a latência do dashboard pode ser latência de cache.
14. Ler skew só pelo relógio de parede. O teste é Max > 1,5× p75 nos Summary Metrics, não "o job pareceu lento".
15. Assumir que o Photon conserta pipelines de Python UDF. Serialização domina; reescreva em SQL nativo primeiro.
16. Rodar OPTIMIZE … ZORDER BY em doze colunas, no meio do dia, no cluster interativo. Técnica legada, hora errada, cluster errado: use clustering, um job cluster de spot separado e um agendamento.

---

Veredito Comparativo: partição tradicional + ZORDER vs liquid clustering (AWS, em out de 2026)

• Partição tradicional + ZORDER, o playbook de 2019 to 2023, agora legado. Você declara uma hierarquia de diretórios estilo Hive (PARTITIONED BY (event_date)) para poda, e então periodicamente OPTIMIZE … ZORDER BY (hot_col) para colocar fisicamente uma coluna não-particionada junto nos arquivos. Funciona, e em ≥ 100 TB com uma chave de data genuinamente de baixa cardinalidade, o particionamento ainda pode pagar o seu custo para DELETE/DROP por partição e para o filtro de partição do Delta Sharing. Os custos: a hierarquia é "estática … não existe jeito fácil de mudar partições"; o ZORDER é uma reescrita que "não é idempotente mas é incremental" e é quebrada pelo MERGE (o low shuffle merge ameniza, mas não remove isso); o ZORDER precisa de estatísticas ou é "ineficaz e um desperdício de recursos"; colunas de alta cardinalidade não podem ser chaves de partição de forma alguma; e, o prego operacional, o predictive optimization nunca roda ZORDER e "ignora arquivos Z-ordered", então tabelas legadas com ZORDER param silenciosamente de serem mantidas.
• Liquid clustering, o padrão documentado para todas as tabelas novas. CLUSTER BY (até 4 chaves, estatísticas obrigatórias, protocolo 3/7) é só metadados para declarar ou mudar; o clustering na escrita aterrissa tráfego de CTAS e streaming já clusterizado nos limiares de 64 MB/256 MB/512 MB/1 GB (gerenciadas); o OPTIMIZE então faz clustering e bin packing juntos, de forma incremental, idempotente, em um cadência de 1 to 2 horas para tabelas quentes; o CLUSTER BY AUTO deixa a plataforma escolher as chaves com consciência de custo; e o predictive optimization mantém isso para você. Evidência: clustering 2,5× mais rápido que Z-order em uma carga de warehouse de 1 TB, com o particionamento Hive "uma ordem de magnitude mais lento" (blog, 2023-06-29), point queries até 12× e leituras 2 to 12× no GA (blog, 2024-05-22). Os custos: um OPTIMIZE FULL único quando as chaves são definidas ou mudadas (horas em uma tabela grande), incompatibilidade com particionamento/ZORDER existentes, e um teto de 4 chaves.
• Veredito em uma linha: tabela nova → CLUSTER BY (ou CLUSTER BY AUTO em uma tabela gerenciada) com predictive optimization ligado; tabela existente particionada/com ZORDER → migre com ALTER TABLE … REPLACE PARTITIONED BY WITH CLUSTER BY (18.1+) mais um OPTIMIZE FULL, mantendo particionamento apenas onde uma tabela ≥ 100 TB genuinamente precisa de movimentos de ciclo de vida por partição ou de sharing com filtro de partição. Cada número de versão nessa frase está datado na seção 4.1; carregue as datas, não só os números.

---

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

---

Casos Reais

📋 Caso A: Comcast (comunicações e mídia, Nuvem: AWS) Desafio. Petabytes de telemetria e bilhões de interações de voz de mais de 20 milhões de remotas de voz, com pipelines frágeis, dor de ingestão de arquivos pequenos e centenas de modelos para implantar em nuvem, on-prem e edge. Stack na AWS. Databricks, Delta Lake para ingest/enriquecimento/otimização de arquivos pequenos, MLflow gerenciado, autoscaling + spot instances, notebooks, Tableau a jusante: Cloud: AWS na página da história. Resultado relatado. "10x de redução nos custos globais de compute para processar dados · 90% de redução nos recursos de DevOps necessários"; "O Delta Lake permitiu à Comcast otimizar a ingestão de dados, substituindo 640 máquinas por 64 enquanto melhorava o desempenho"; implantação de modelo "de semanas para minutos" (https://www.databricks.com/customers/comcast, página sem data, acessada em 2026-10). A Comcast também é citada entre clientes "already leveraging Databricks on AWS" no press release do AWS Marketplace da Databricks (2022-05-10), e a telemetria RDK dela é descrita como "petabytes de dados, coletados a cada 15 minutos de 70 milhões de dispositivos" (databricks.com/blog, 2021-05-10). Mapeia para esta lição. Seções 2 e 8, o destaque é um ganho estrutural: o tratamento de arquivos do Delta colapsou 640 máquinas em 64 antes de qualquer ajuste de consulta, que é exatamente a ordenação de camada primeiro que esta lição ensina, mais spot instances para a janela de compactação. ⏳ Nota temporal: origem da história 2019, página sem data acessada em out de 2026: um resultado de cliente relatado, não uma garantia de 2026.

📋 Caso B: Rivian (veículos elétricos, Nuvem: AWS) Desafio. Mais de 70.000 veículos na estrada "gerando terabytes de dados todos os dias", com ferramentas legadas que "lutavam para escalar pipelines de forma custo-eficiente", alimentando ML de manutenção preditiva e de previsão de carga. Stack na AWS. Databricks SQL, Delta Lake, Unity Catalog, e, explicitamente, "Liquid Clustering para disposição de dados" ao lado de "Unity Catalog para governança de dados, Delta Tables para armazenamento" para ML de previsão de carga em tempo real (databricks.com/blog, 2025-07-09); Cloud: AWS na página da história. Resultado relatado. "50% better runtime performance" (https://www.databricks.com/your-ai/customers/rivian, 2024-05-30); "mais de 1.000 usuários de plataforma, um aumento de 75% em relação a um ano atrás" (https://www.databricks.com/customers/rivian, sem data, acessada em 2026-10). Mapeia para esta lição. Seções 4 e 5: a Rivian é o exemplo nomeado na AWS exatamente da alavanca que o exemplo resolvido E4 desta lição exercita: a telemetria de veículos é de alta cardinalidade, cresce rápido e é consultada por colunas de filtro, que é a lista documentada de casos ideais para clustering ("consultas que filtram em colunas de alta cardinalidade", "tabelas de crescimento rápido", "tabelas com padrões de acesso variados ou em mudança"). ⏳ Nota temporal: a cifra de 50% é de 2024-05-30; a menção ao stack de liquid clustering é de 2025-07-09.

📋 Caso C: Punchh (fidelidade de varejo / tecnologia para restaurantes, Nuvem: AWS) Desafio. MySQL da AWS superado, um warehouse caro demais para manter, e relatórios do Tableau lentos por joins executados do zero a cada relatório: "Quando você faz join de 12 tabelas em tempo real toda vez que um relatório é executado por um cliente, o custo para gerar o relatório pode ser alto." Stack na AWS. Databricks SQL, Delta Lake bronze/silver/gold, notebooks, Tableau por cima: Cloud: AWS na página da história. Resultado relatado. "10x Faster time-to-insight · 30% Lower operational costs · 12% Increase in customer satisfaction" (https://www.databricks.com/customers/punchh, página sem data, acessada em 2026-10; origem da história 2021). Mapeia para esta lição. Seções 8 e 10, o join mais barato é o que você não roda: uma tabela gold pré-joinada (ou uma materialized view com refresh incremental) vence tanto um join de 12 vias no momento do relatório quanto qualquer resize de warehouse que teria forçado tudo na marra. ⏳ Nota temporal: história de origem 2021 ainda exibida em 2026: ensine o mecanismo, date as métricas.

---

---

Perguntas de Prática (Practice Questions)