Projetar e implementar uma estratégia de clustering

Concluído(a)

Dica

Consulte a guia Texto e imagens para obter mais detalhes!

Otimizar como os dados são fisicamente organizados no disco afeta diretamente o desempenho da consulta e a eficiência de armazenamento. Ao projetar uma estratégia de clustering para suas tabelas delta lake, você determina como o mecanismo de consulta localiza e recupera dados relevantes. A abordagem certa pode reduzir drasticamente a quantidade de dados verificados durante consultas, reduzindo os tempos de resposta e os custos de computação.

O Azure Databricks fornece várias técnicas complementares para a organização de dados. Entender quando aplicar agrupamento líquido, ordenação Z ou vetores de exclusão auxilia na tomada de decisões que equilibram o desempenho, o esforço de manutenção e a compatibilidade com suas tabelas existentes.

Entender os conceitos básicos de ignorar dados

Antes de examinar técnicas de clustering específicas, é importante entender o mecanismo subjacente que todas usam: ignorar dados. O Delta Lake coleta automaticamente estatísticas para cada arquivo de dados, incluindo valores mínimos e máximos, contagens nulas e contagens de registros para cada coluna. Quando você executa uma consulta com condições de filtro, o mecanismo de consulta verifica essas estatísticas primeiro e ignora arquivos que não podem conter registros correspondentes.

Por exemplo, se você consultar dados de vendas para janeiro de 2026 e as estatísticas de um arquivo específico mostrarem que ele contém apenas registros a partir de março de 2026, o mecanismo ignorará esse arquivo inteiramente sem ler seu conteúdo. Essa otimização ocorre automaticamente, mas sua eficácia depende de quão bem seus dados são organizados.

Diagrama explicando os conceitos básicos de ignorar dados.

O salto de dados torna-se poderoso quando os registros relacionados são armazenados juntos nos mesmos arquivos. Se os registros de cada mês forem espalhados aleatoriamente por todos os arquivos, o mecanismo não poderá ignorar nenhum arquivo porque cada arquivo contém registros de cada mês. Existem técnicas de clustering para resolver exatamente esse problema.

Implementar clustering líquido para novas tabelas

O agrupamento líquido é a abordagem recomendada para organizar dados em novas tabelas do Delta Lake, além de estar disponível na versão preliminar pública para tabelas gerenciadas do Apache Iceberg no catálogo do Unity (Databricks Runtime 16.4 LTS e versões posteriores). Ao contrário do particionamento tradicional, o clustering líquido permite que você altere sua estratégia de clustering sem reescrever dados existentes. Essa flexibilidade é valiosa quando os padrões de consulta evoluem ou quando você não sabe quais colunas serão filtradas com mais frequência.

Observação

Para tabelas de Iceberg gerenciadas no catálogo do Unity, a especificação de uma cláusula PARTITION BY é interpretada como chaves de agrupamento líquido, não partições tradicionais no estilo Hive. Não há um comportamento de partição específico do Iceberg. Toda a otimização de layout é realizada através de agrupamento líquido.

Para habilitar o liquid clustering, use a cláusula CLUSTER BY 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 aparecem com frequência nos filtros de consulta. A ordem das chaves de agrupamento importa menos do que selecionar as colunas certas, pois o agrupamento líquido otimiza todas as chaves especificadas simultaneamente.

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

OPTIMIZE sales.transactions;

O clustering líquido é incremental. Cada OPTIMIZE cluster de execução só executa os dados que precisam de reorganização, tornando a manutenção regular eficiente. Databricks recomenda agendar OPTIMIZE trabalhos a cada uma ou duas horas para tabelas com inserções ou atualizações frequentes.

Dica

Para tabelas gerenciadas do Catálogo do Unity, habilite a otimização preditiva para automatizar OPTIMIZE operações. O Azure Databricks analisa os padrões de carga de trabalho e executa as operações de manutenção automaticamente.

Alterar chaves de clustering quando necessário

Uma vantagem significativa da aglomeração líquida em relação ao particionamento é a capacidade de modificar a sua estratégia de aglomeração. Se os padrões de consulta forem alterados, atualize as chaves de clustering com uma instrução ALTER TABLE :

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

As operações subsequentes OPTIMIZE usam a nova abordagem de clusterização. Os dados gravados anteriormente não são reescritos automaticamente. Para aplicar o novo clustering a todos os dados existentes, execute:

OPTIMIZE sales.transactions FULL;

Habilitar a seleção automática de chave de agrupamento

O Azure Databricks pode selecionar chaves de clustering de forma inteligente com base em seus padrões de consulta reais. O agrupamento líquido automático analisa o histórico de carga de trabalho e escolhe as colunas que oferecem o maior benefício ao ignorar de dados:

CREATE TABLE sales.orders CLUSTER BY AUTO;

Você pode habilitar o clustering automático em tabelas existentes:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

O agrupamento automático de líquidos requer que a otimização preditiva esteja ativada. O Azure Databricks avalia periodicamente se chaves de clustering diferentes melhorariam o desempenho e ajustariam a estratégia adequadamente.

Migrar da ordenação Z para o agrupamento líquido

A ordenação Z é uma técnica herdada que organiza os dados para colocar informações relacionadas nos mesmos arquivos. Embora a aglomeração líquida seja recomendada para novas tabelas, você encontrará tabelas existentes que usam a ordenação Z e precisará entender ambas as abordagens.

A ordenação Z usa o comando OPTIMIZE com a cláusula ZORDER BY:

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

A ordenação Z difere do agrupamento líquido de várias maneiras importantes:

Aspecto Agrupamento líquido Ordenação Z
Flexibilidade de chave Alterar chaves sem reescrita de dados Alterar chaves requer reescrita completa
Desempenho de gravação Agrupamento em gravação para operações qualificadas Aplicado somente durante o OPTIMIZE
Gravações simultâneas Suporte para concorrência em nível de linha Concorrência no nível da transação
Compatibilidade Requer o Databricks Runtime 13.3 LTS ou superior Com suporte em todos os ambientes de execução

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

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

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

OPTIMIZE sales.legacy_transactions FULL;

Importante

O agrupamento "líquido" não é compatível com o particionamento. Para tabelas particionadas, avalie se os benefícios do clustering líquido justificam a migração para uma estrutura de tabela não particionada.

Gerenciar vetores de exclusão para atualizações eficientes

Os vetores de exclusão abordam um aspecto diferente da organização de dados: como o Delta Lake lida com registros modificados ou excluídos. Por padrão, quando você atualiza ou exclui uma única linha em um arquivo Parquet, o Delta Lake deve reescrever todo o arquivo. Para tabelas com modificações frequentes, isso cria uma sobrecarga significativa.

Com os vetores de exclusão habilitados, o Delta Lake marca linhas modificadas como excluídas em um arquivo de metadados separado em vez de reescrever o arquivo Parquet imediatamente. As leituras subsequentes aplicam essas exclusões em tempo real, combinando o arquivo original com o vetor de exclusão para retornar resultados precisos.

Os vetores de exclusão são habilitados por padrão para novas tabelas criadas com o Databricks Runtime 14.1 ou superior. Você pode habilitá-las explicitamente em tabelas existentes:

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

Os vetores de exclusão são aplicados fisicamente quando os arquivos de dados são reescritos durante:

  • Um OPTIMIZE comando
  • Gatilhos de compactação automática
  • Operação REORG TABLE ... APPLY (PURGE)

Para cenários de conformidade em que você precisa garantir que os dados excluídos sejam removidos fisicamente, execute uma REORG operação seguida por VACUUM:

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

Os vetores de exclusão também habilitam a simultaneidade em nível de linha, permitindo que várias transações simultâneas modifiquem linhas diferentes na mesma tabela sem conflitos. Essa funcionalidade é particularmente valiosa para tabelas com grandes volumes de atualização.