Desenhar e implementar uma estratégia de clustering

Otimizar a forma como os dados são fisicamente organizados no disco afeta diretamente o desempenho das consultas e a eficiência do armazenamento. Quando desenha uma estratégia de clustering para as suas tabelas Delta Lake, determina como o motor de consulta localiza e recupera dados relevantes. A abordagem correta pode reduzir drasticamente a quantidade de dados analisados durante as consultas, diminuindo tanto os tempos de resposta como os custos de computação.

O Azure Databricks fornece várias técnicas complementares para organização de dados. Compreender quando aplicar clusterização líquida, ordenação Z ou vetores de eliminação ajuda a tomar decisões que equilibrem desempenho, esforço de manutenção e compatibilidade com as suas tabelas existentes.

Compreender os fundamentos do esquema de omissão de dados

Antes de examinar técnicas específicas de agrupamento, é importante compreender o mecanismo subjacente que todos utilizam: o salto de dados. A Delta Lake recolhe automaticamente estatísticas para cada ficheiro de dados, incluindo valores mínimos e máximos, contagens nulas e contagens de registos para cada coluna. Quando executas uma consulta com condições de filtro, o motor de consulta verifica primeiro essas estatísticas e salta ficheiros que não podem conter registos correspondentes.

Por exemplo, se consultar dados de vendas de janeiro de 2026, e as estatísticas de um determinado ficheiro mostrarem que contém apenas registos de março de 2026, o motor ignora esse ficheiro completamente sem ler o seu conteúdo. Esta otimização acontece automaticamente, mas a sua eficácia depende de quão bem os seus dados estão organizados.

O salto de dados torna-se poderoso quando registos relacionados são armazenados juntos nos mesmos ficheiros. Se os registos de cada mês estiverem dispersos aleatoriamente por todos os ficheiros, o motor não pode saltar nenhum ficheiro porque cada ficheiro contém registos de cada mês. Existem técnicas de clustering para resolver exatamente este problema.

Implementar clustering líquido para novas tabelas

O agrupamento líquido é a abordagem recomendada para organizar dados em novas tabelas Delta Lake, estando também disponível em Pré-visualização Pública para tabelas Apache Iceberg geridas no Unity Catalog (Databricks Runtime 16.4 LTS e superiores). Ao contrário do particionamento tradicional, o agrupamento líquido permite-lhe alterar a sua estratégia de clusterização sem reescrever dados existentes. Esta flexibilidade é valiosa quando os padrões de consulta evoluem ou quando não tem a certeza de quais as colunas que serão filtradas com mais frequência.

Para permitir o agrupamento de líquidos, use a CLUSTER BY cláusula ao criar uma tabela:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

Você pode especificar até quatro chaves de clustering. Escolha colunas que apareçam frequentemente nos seus filtros de consulta. A ordem das chaves de agrupamento importa menos do que selecionar as colunas certas, pois o agrupamento líquido otimiza para todas as chaves especificadas simultaneamente.

Depois de criar uma tabela clusterizada, execute o OPTIMIZE comando para aplicar clustering aos seus dados:

OPTIMIZE sales.transactions;

O agrupamento de líquidos é incremental. Cada OPTIMIZE execução agrupa apenas os dados que precisam de reorganização, tornando a manutenção regular eficiente. Databricks recomenda agendar OPTIMIZE tarefas a cada uma ou duas horas para tabelas com inserções ou atualizações frequentes.

Alterar as chaves de agrupamento quando necessário

Uma vantagem significativa do agrupamento líquido em relação ao particionamento é a possibilidade de modificar a sua estratégia de clustering. Se os seus padrões de consulta mudarem, atualize as chaves de agrupamento com uma ALTER TABLE instrução:

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

As operações subsequentes OPTIMIZE utilizam a nova abordagem de agrupamento. Dados previamente escritos não são automaticamente reescritos. Para aplicar um novo agrupamento a todos os dados existentes, execute:

OPTIMIZE sales.transactions FULL;

Ativar a seleção automática de chaves de agrupamento

O Azure Databricks pode selecionar inteligentemente chaves de clustering com base nos seus padrões reais de consulta. O agrupamento automático de líquidos analisa o histórico de carga de trabalho e escolhe colunas que proporcionam o maior benefício de salto de dados:

CREATE TABLE sales.orders CLUSTER BY AUTO;

Pode ativar o agrupamento automático em tabelas existentes:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

A agrupação automática de líquidos requer que a otimização preditiva seja ativada. O Azure Databricks avalia periodicamente se diferentes chaves de clustering melhorariam o desempenho e ajusta a estratégia em conformidade.

Migrar da ordenação Z para a clusterização líquida

A ordenação Z é uma técnica legada que organiza dados para colocar informação relacionada nos mesmos ficheiros. Embora o agrupamento líquido seja recomendado para novas tabelas, vais encontrar tabelas existentes que usam ordenação Z e precisas de compreender ambas as abordagens.

A ordenação Z utiliza o comando OPTIMIZE com uma cláusula ZORDER BY:

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

A ordenação Z difere do agrupamento líquido em vários aspetos importantes:

Quando herdas uma tabela ordenada por Z, tens duas opções. Continue a usar a ordenação Z para maior consistência, ou migre para agrupamento líquido para maior flexibilidade. Para migrar, primeiro ative o agrupamento líquido na tabela não particionada existente:

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

Depois, execute uma otimização completa para reorganizar todos os dados existentes:

OPTIMIZE sales.legacy_transactions FULL;

Gerir vetores de eliminação para atualizações eficientes

Os vetores de apagamento abordam um aspeto diferente da organização dos dados: a forma como a Delta Lake lida com registos modificados ou eliminados. ** Por padrão, quando atualiza ou elimina uma única linha num ficheiro Parquet, o Delta Lake tem de reescrever o ficheiro inteiro. Para tabelas com modificações frequentes, isto gera uma sobrecarga significativa.

Com os vetores de eliminação ativados, o Delta Lake marca as linhas modificadas como eliminadas num ficheiro de metadados separado, em vez de reescrever imediatamente o ficheiro Parquet. As leituras subsequentes aplicam estas eliminações em tempo real, combinando o ficheiro original com o vetor de eliminação para devolver resultados precisos.

Os vetores de eliminação estão ativados por defeito para novas tabelas criadas com Databricks Runtime 14.1 ou superior. Pode ativá-los explicitamente em tabelas existentes:

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

Vetores de eliminação são aplicados fisicamente quando os ficheiros de dados são reescritos durante:

• Um OPTIMIZE comando
• Gatilhos de autocompactação
• Uma REORG TABLE ... APPLY (PURGE) operação

Para cenários de conformidade em que precisa de garantir que os dados eliminados são fisicamente removidos, execute uma REORG operação seguida de VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

Os vetores de eliminação também permitem concorrência ao nível das linhas, permitindo que múltiplas transações concorrentes modifiquem diferentes linhas na mesma tabela sem conflitos. Esta funcionalidade é particularmente valiosa para tabelas com elevados volumes de atualização.