CLUSTER BY AUTO no Databricks: pare de escolher chaves de clustering na mão

Durante anos, otimizar o layout físico de uma tabela no lakehouse foi uma tarefa artesanal: você olhava as queries mais frequentes, decidia por quais colunas os dados eram mais filtrados, aplicava PARTITIONED BY ou ZORDER, e voltava meses depois para reajustar quando o padrão de acesso mudava. Funcionava — mas era uma decisão que envelhecia e virava dívida técnica silenciosa.

O Automatic Liquid Clustering, acionado pela palavra-chave CLUSTER BY AUTO, muda esse jogo: o próprio Databricks passa a escolher e a manter as chaves de clustering das tabelas gerenciadas do Unity Catalog, sem intervenção manual.

Um passo atrás: partição, ZORDER e Liquid Clustering

Para entender o AUTO, vale relembrar a evolução:

• Particionamento (PARTITIONED BY) divide os dados em pastas por valor de coluna. Ótimo em teoria, mas fácil de errar: cardinalidade alta gera o problema dos "small files"; cardinalidade baixa não ajuda no pruning. E a escolha é rígida — mudar exige reescrever a tabela.
• ZORDER reorganiza os dados dentro dos arquivos por múltiplas colunas, melhorando o data skipping. Só que roda dentro do OPTIMIZE e precisa ser mantido manualmente.
• Liquid Clustering substitui os dois. É flexível (você troca as chaves sem reescrever a tabela), lida bem com skew e com colunas de alta cardinalidade, e evita o problema dos arquivos pequenos.

O CLUSTER BY AUTO é o passo seguinte: em vez de você indicar as colunas do Liquid Clustering, o motor decide por você.

O que o CLUSTER BY AUTO faz

Ao marcar uma tabela gerenciada do Unity Catalog com CLUSTER BY AUTO, você delega a seleção das chaves ao Predictive Optimization. Ele:

1. Analisa o histórico real de queries sobre a tabela (quais colunas aparecem em filtros e joins).
2. Seleciona as chaves de clustering mais eficazes para aquele workload.
3. Mantém a tabela sozinho, rodando OPTIMIZE, VACUUM e ANALYZE de forma automática.
4. Readapta as chaves ao longo do tempo — se o padrão de acesso mudar, o clustering acompanha.

Ou seja: a otimização deixa de ser um evento pontual e passa a ser um processo contínuo e gerenciado.

Como usar — os 3 passos

1. Tabela nova

CREATE TABLE sales (
  id BIGINT,
  ts TIMESTAMP
)
CLUSTER BY AUTO;

2. Tabela que já existe (não particionada ou já em Liquid)

ALTER TABLE sales CLUSTER BY AUTO;

3. Converter uma tabela particionada

Para migrar uma tabela particionada para clustering automático a partir das colunas de partição atuais:

ALTER TABLE sales REPLACE PARTITIONED BY WITH CLUSTER BY AUTO;

Depois disso, você não precisa mais chamar OPTIMIZE na mão — o Predictive Optimization cuida da manutenção.

Requisitos

• Databricks Runtime 15.4 LTS ou superior.
• Tabela gerenciada no Unity Catalog (managed table) — Delta Lake ou Iceberg gerenciado.
• Predictive Optimization habilitado (ligado por padrão em contas novas; o rollout para contas existentes se completou ao longo de 2026).

Para confirmar que o AUTO está ativo:

DESCRIBE DETAIL sales;      -- observe clusteringColumns
SHOW TBLPROPERTIES sales;   -- clusterByAuto = true

As clusteringColumns podem mudar com o tempo — isso é esperado e é justamente o mecanismo de readaptação funcionando.

Quando usar — e quando NÃO usar

Bons casos para o AUTO:

• Tabelas gerenciadas médias e grandes com padrões de query que evoluem.
• Times que não querem (ou não têm tempo de) manter estratégias de ZORDER/partição manualmente.
• Tabelas onde a chave "óbvia" de ontem já não corresponde aos filtros de hoje.

Casos em que talvez não valha a pena:

• Tabelas muito pequenas, onde o data skipping tem pouco impacto — o custo de manutenção não se paga.
• Tabelas com particionamento já muito bem definido e estável, onde o ganho marginal é baixo.
• Cenários com requisitos regulatórios de layout físico específico (ex.: expurgo por partição de data), em que você precisa de controle explícito.

Nesses casos você ainda pode usar Liquid Clustering com chaves fixas (CLUSTER BY (coluna)) em vez do AUTO.

Como monitorar

• Acompanhe a evolução das clusteringColumns via DESCRIBE DETAIL.
• Verifique os históricos de operações de manutenção (as execuções de OPTIMIZE/VACUUM disparadas pelo Predictive Optimization) para entender frequência e custo.
• Compare tempos de query e volume de dados lido (data skipping) antes e depois de ativar o AUTO — é a métrica que realmente importa.

Conclusão

O CLUSTER BY AUTO tira do engenheiro de dados uma decisão que sempre foi chute educado e a transforma em um processo governado e adaptativo. O resultado prático é duplo: menos manutenção manual e menos dívida técnica de layout físico — porque a tabela deixa de ficar "presa" à melhor decisão que você conseguiu tomar seis meses atrás. Para a maioria das tabelas gerenciadas do Unity Catalog, ativar o AUTO é uma linha de SQL com retorno alto: leituras mais rápidas e menor TCO, sem esforço recorrente.