Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O cluster líquido é uma estratégia flexível de layout de dados para tabelas Delta no Microsoft Fabric. Substitui o particionamento estático ao estilo Hive e a manutenção manual da Ordem Z por clusters declarativos e favoráveis às alterações. Defines em que colunas agrupar, e o Fabric Spark Runtime trata automaticamente do layout físico dos dados.
Use este artigo para:
- Compreenda como funciona o agrupamento líquido e quando o deve usar.
- Compare o agrupamento de líquidos com o particionamento e a ordem Z.
- Configura o agrupamento nas tuas tabelas.
- Compreenda o agrupamento incremental de líquidos (Runtime 2.0+).
- Ajuste o comportamento do clustering com as configurações da sessão.
O que é o agrupamento de líquidos?
O agrupamento líquido organiza os dados em ficheiros da tabela Delta para que as linhas com valores semelhantes nas colunas de agrupamento sejam colocadas próximas umas das outras. O layout permite um salto melhorado de ficheiros durante a execução da consulta: quando uma consulta filtra nas colunas de clustering, o motor lê apenas os ficheiros cujos intervalos de valores correspondem ao predicado, saltando o resto.
Ao contrário da particionação, agrupamento líquido:
- Não cria estruturas físicas de diretórios para cada valor de coluna.
- Não exige que escolhas as colunas de agrupamento na altura da criação da tabela (podem ser alteradas mais tarde).
- Processa colunas de alta cardinalidade sem criar potenciais problemas causados por ficheiros pequenos resultantes de milhares de partições minúsculas.
- Aplica otimização de layout durante
OPTIMIZE, não no momento da escrita.
Vantagens em relação à partição e à Ordem Z
O agrupamento líquido oferece vantagens significativas tanto em relação à partição ao estilo Hive como à Z-Order em termos de flexibilidade, manutenção e gestão de padrões de dados em evolução.
Em comparação com o particionamento no estilo Hive
| Aspeto | Particionamento estilo colmeia | Agrupamento de líquidos |
|---|---|---|
| Granularidade | Um diretório por valor distinto (ou combinação) | Intervalos de valores ao nível do ficheiro, sem diretórios |
| Alta cardinalidade | Cria milhares de pequenos ficheiros/diretórios | Funciona naturalmente; agrupa os dados em ficheiros com a dimensão adequada |
| Alterações nas colunas | Requer reescrita total da tabela |
ALTER TABLE ... CLUSTER BY aplica-se ao próximo OPTIMIZE |
| Percurso de escrita | A coluna de partição tem de ser conhecida no momento da escrita | Qualquer coluna pode ser colocada em cluster posteriormente |
| Problema de ficheiros pequenos | Comum com streaming ou inserções frequentes | Gerido pela OPTIMIZE compactação |
Em comparação com Z-Order
| Aspeto | Ordem Z | Agrupamento de líquidos |
|---|---|---|
| Alterações nas colunas | Tem de voltar a executar OPTIMIZE ZORDER BY (...) com novas colunas |
ALTER TABLE ... CLUSTER BY persiste a definição |
| Apoio incremental | Sem modo incremental; usar WHERE para limitar o âmbito manualmente |
O modo incremental (Runtime 2.0+) processa automaticamente apenas ficheiros novos, alterados ou não saudáveis |
| Metadata | Sem definição persistente de coluna | Agrupamento de colunas armazenadas em metadados de tabela |
| Disposição de múltiplas colunas | Curva Z-order aplicada durante a otimização | Ordem Z para uma coluna de agrupamento; Curva de Hilbert para 2+ colunas, fornecendo uma localização de dados otimizada |
O agrupamento líquido utiliza a Ordem Z para layouts de coluna única e a curva de Hilbert para 2+ colunas — uma melhoria em relação à Ordem Z, que aplica apenas a curva da Ordem Z para agrupamento multidimensional. A clusterização líquida envolve ambos os algoritmos numa estrutura incremental consciente dos metadados que reduz os custos de manutenção contínua.
Crie uma tabela agrupada por líquidos
Defina as colunas de clustering utilizando a cláusula CLUSTER BY ao criar a tabela:
-- Create a new clustered table
CREATE TABLE dbo.sales (
order_id BIGINT,
order_date DATE,
region STRING,
amount DECIMAL(10,2)
) CLUSTER BY (order_date, region);
-- Create from query results
CREATE TABLE dbo.sales_clustered
CLUSTER BY (order_date, region)
AS SELECT * FROM raw_sales;
-- Enable on existing table
ALTER TABLE dbo.sales_txn CLUSTER BY (order_date, region);
Alterar colunas de agrupamento
Ao contrário da particionação, pode mudar as colunas de agrupamento a qualquer momento sem reescrever os dados:
-- Change clustering columns
ALTER TABLE sales CLUSTER BY (region, product_category);
-- Remove clustering (table becomes unclustered)
ALTER TABLE sales CLUSTER BY NONE;
Após mudar as colunas de agrupamento, o novo layout aplica-se na execução seguinte OPTIMIZE . Os ficheiros existentes mantêm o seu layout anterior até serem reagrupados.
Aplicar agrupamento com OPTIMIZE
O agrupamento é aplicado durante o OPTIMIZE comando. Não é necessário especificar colunas na OPTIMIZE instrução, pois a definição de agrupamento é armazenada nos metadados da tabela:
-- Cluster the table using the defined clustering columns
OPTIMIZE sales;
-- Recluster partial Z-Cubes and Z-Cubes with different clustering keys or clustering providers
OPTIMIZE sales FULL;
Usa OPTIMIZE FULL quando mudas chaves de clustering e quiseres reconstruir Z-Cubes que não seguem a estratégia atual de clustering. Um Z-Cube é a unidade lógica que o agrupamento líquido usa para agrupar ficheiros que partilham as mesmas colunas de agrupamento. Os dados são agrupados num único Z-Cube até que as chaves de cluster mudem ou a quantidade de dados ultrapasse os 100 GB.
Sugestão
A partir do Fabric Runtime 2.0, o motor de execução Nativa suporta a execução de OPTIMIZE em tabelas clusterizadas líquidas, oferecendo um desempenho de clustering multidimensional 30–50% mais rápido. Os tempos de execução anteriores regressam à execução normal não acelerada do Spark.
Como funciona o agrupamento líquido
Quando se executa OPTIMIZE numa tabela em clusters líquidos, acontece o seguinte:
-
Seleção de ficheiros: O motor seleciona ficheiros que precisam de agrupamento.
- No Runtime 2.0+ (estratégia de clustering incremental), são selecionados apenas ficheiros não agrupados, não saudáveis, pequenos ou com vetor de eliminação.
- No Runtime 1.3, todos os ficheiros dentro de cada Z-Cube com menos de 100 GB são selecionados, independentemente de já estarem bem agrupados.
- Empacotamento de bins: Ficheiros selecionados são agrupados em bins que visam um tamanho ótimo de ficheiro de saída.
- Reparticionamento: Os dados dentro de cada compartimento são reparticionados utilizando uma curva de preenchimento de espaço (curva de Hilbert para várias colunas, ordenação Z para uma única coluna).
- Escrita de ficheiros: Os dados reparticionados são escritos como ficheiros novos com intervalos de valores apertados em colunas de agrupamento.
- Atualização de metadados: O registo Delta regista a substituição do ficheiro, marcando os novos ficheiros com metadados de clustering.
O resultado são ficheiros com intervalos de valores não sobrepostos (ou minimamente sobrepostos) em colunas de agrupamento, permitindo ao motor saltar ficheiros que não correspondem aos predicados da consulta.
Atenção
Fabric Runtime 1.3 (Delta 3.2): use o agrupamento de líquidos com cautela. Neste tempo de execução, o agrupamento líquido utiliza uma estratégia completa de reescrita do Z-Cube — cada ficheiro dentro de um Z-Cube é reescrito em cada execução. Um Z-Cube é preservado (omitido) apenas quando o seu tamanho excede 100 GB. Para tabelas com menos de 100 GB, a reescrita completa significa que cada OPTIMIZE execução reescreve todos os dados das tabelas, mesmo quando os dados já estão bem agrupados. Isto causa uma amplificação severa de escrita.
- Não utilize a compactação automática com agrupamento líquido no Runtime 1.3. Cada gatilho de autocompactação pode causar uma reescrita completa da tabela em vez de apenas agrupar os dados novos/alterados.
- Evite executar
OPTIMIZEapós cada operação de escrita. Em Runtime 1.3, limite o agrupamento a execuções estratégicas e intencionais e aceite uma atualização menos frequente do agrupamento entre elas.
O agrupamento incremental de líquidos, que elimina esta amplificação de escrita, só está disponível a partir do Fabric Runtime 2.0.
Agrupamento incremental de líquidos
A partir do Fabric Runtime 2.0 (Delta 4.1), o clustering liquid utiliza, por predefinição, uma estratégia de clustering incremental. A estratégia incremental é uma melhoria significativa em relação ao comportamento padrão de agrupamento.
Importante
O agrupamento incremental de líquidos está disponível apenas no Fabric Runtime 2.0 e versões posteriores. Em ambientes de execução anteriores, OPTIMIZE usa o comportamento padrão (reescrita completa), em que todos os ficheiros dentro de um Z-Cube são reescritos em cada execução.
Porque é importante a estratégia de agrupamento incremental
O algoritmo de clustering padrão reescreve todos os ficheiros dentro de um Z-Cube (até 100 GB) em cada OPTIMIZE execução, independentemente de já estarem bem agrupados. Para uma tabela que recebe pequenos apendimentos, o custo de agrupamento cresce linearmente com o tamanho da tabela, e não com a quantidade de dados novos.
O modo incremental resolve o problema da reescrita completa ao selecionar apenas ficheiros que realmente precisam de clustering:
- Ficheiros não agrupados: Dados recém-escritos sem metadados de clustering
- Ficheiros pequenos: Ficheiros abaixo do limiar de tamanho alvo dos ficheiros
- Ficheiros com vetores de eliminação: Ficheiros com eliminações acumuladas que excedem o limiar de limpeza
Ficheiros já bem agrupados e com tamanho adequado são completamente ignorados.
Reagrupamento automático
O agrupamento incremental de líquidos inclui a deteção automática de sobreposição, conhecida como reagrupamento automático, para manter a qualidade do agrupamento ao longo do tempo. À medida que novos dados chegam, podem criar sobreposição entre intervalos de valores de ficheiros, degradando a eficácia do salto de dados. O reagrupamento automático deteta intervalos de valores sobrepostos entre ficheiros e reagrupa seletivamente apenas os ficheiros afetados.
O reagrupamento automático corre automaticamente como parte de OPTIMIZE sempre que há dados novos ou alterados no cluster. Não são necessárias intervenções manuais nem reagrupamentos completos programados. A estratégia de agrupamento incremental mantém uma qualidade de agrupamento quase ótima à medida que os dados evoluem.
Reverter ao comportamento de reescrita total
Se precisar de desativar a estratégia de clustering incremental e usar o comportamento de reescrita completa, defina a seguinte configuração:
SET spark.microsoft.delta.optimize.clustering.strategy.incremental = FALSE;
OPTIMIZE sales;
Alternativamente, use OPTIMIZE FULL para um reagrupamento completo único sem alterar as definições da sessão:
OPTIMIZE sales FULL;
Note
A estratégia de agrupamento incremental permite intencionalmente pequenos desvios do layout teoricamente ótimo para alcançar reduções significativas na amplificação de escrita. A execução de OPTIMIZE FULL reduz essa diferença ao reconstruir integralmente os Z-Cubes até ao ótimo teórico, mas com um custo de escrita mais elevado.
Referência de configuração
As seguintes configurações de sessão controlam o comportamento do agrupamento líquido no Fabric Runtime 2.0+.
Agrupamento incremental
| Configuração | Tipo | Predefinição | Description |
|---|---|---|---|
spark.microsoft.delta.optimize.clustering.strategy.incremental |
booleano | true |
Interruptor principal para o agrupamento incremental. Quando true, OPTIMIZE processa apenas ficheiros não clusterizados, não saudáveis, pequenos e de vetor de eliminação. Quando false, todos os ficheiros para Z-Cubes com menos de 100 GB são reescritos (comportamento padrão). |
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster |
booleano | true |
Permite a deteção automática e reagrupamento de ficheiros com intervalos de dados sobrepostos. Só se aplica quando o clustering incremental está ativado. |
Ajuste automático do reagrupamento
Estas configurações controlam a sensibilidade e o âmbito do reagrupamento automático. Os valores padrão são adequados para a maioria das cargas de trabalho. Ajuste-os apenas quando precisar de alterar o equilíbrio entre a qualidade do agrupamento e a amplificação de escrita.
| Configuração | Tipo | Predefinição | Description |
|---|---|---|---|
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOffendingFiles |
Int | 4 |
Número mínimo de ficheiros sobrepostos necessários para desencadear o reagrupamento. Valores mais baixos reagrupam mais cedo (melhor desempenho de consultas, custo de escrita mais elevado). Deve ser ≥ 2. |
spark.microsoft.delta.optimize.clustering.strategy.incremental.autoRecluster.minOverlapThreshold |
Double | 0.75 |
Limiar de pontuação de sobreposição da dimensão de agrupamento. Pares de ficheiros com pontuação acima deste valor são considerados sobrepostos. Deve estar dentro do intervalo (0,25, 1,0]. Valores mais baixos são mais agressivos. |
Escolher colunas de agrupamento
Para melhores resultados, escolha colunas de agrupamento com base nos seus padrões de filtro de consulta mais comuns:
-
Escolha 1 a 4 colunas que aparecem frequentemente nas
WHEREorações. Mais colunas reduzem a capacidade de ignorar ficheiros por coluna da curva de enchimento do espaço e aumentam o tempo necessário para agrupar os dados. - Considere a cardinalidade da coluna. Colunas de baixa cardinalidade produzem menos intervalos de valores distintos, o que reduz o benefício de saltar ficheiros quando combinado com chaves de clustering de alta cardinalidade.
-
A ordem das colunas não tem impacto no agrupamento. A ordem das colunas especificadas a seguir
CLUSTER BYnão tem impacto no agrupamento multidimensional resultante.
Tipos de coluna suportados
Nem todos os tipos de colunas podem ser usados como chaves de agrupamento. O motor avalia o tipo de dados de cada coluna para determinar a elegibilidade.
Sempre elegíveis (tipos atómicos):
-
NumericType(ByteType,ShortType,IntegerType,LongType,FloatType,DoubleType, )DecimalType DateTypeTimestampTypeTimestampNTZTypeStringType
Elegível condicionalmente:
Note
Os seguintes tipos podem ser ativados a partir do Fabric Spark Runtime 2.0 (Delta 4.1)
-
StructType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledestá ativado, e todos os campos folha são eles próprios tipos elegíveis. -
ArrayType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledestá ativado, e o tipo de elemento é elegível. -
MapType: quandospark.microsoft.delta.clusteredTable.complexTypes.enabledestá ativado, e tanto os tipos de chave como de valor são ordenáveis e elegíveis.
Não elegível:
BinaryTypeBooleanTypeNullType
Para os tipos elegíveis equivalentes usados em estatísticas ao nível de ficheiro, veja Salto de ficheiros—Tipos de dados elegíveis.
Interação com outras funcionalidades
| Feature | Comportamento |
|---|---|
| Partitioning | Incompatível. Para fins de salto de ficheiros, recomenda-se o agrupamento líquido em vez do particionamento. |
| Z-Order | Incompatível. Para fins de salto de ficheiros, recomenda-se o agrupamento líquido em vez do Z-Order. |
| Otimização rápida | Compatível a partir do Runtime 2.0. Em tempos de execução mais antigos, a otimização rápida não tem efeito nas tabelas clusterizadas de líquidos. Durante OPTIMIZE, salta o agrupamento quando não há ficheiros pequenos suficientes ou dados insuficientes para produzir um ficheiro de saída de tamanho saudável. |
| Tamanho adaptativo do ficheiro alvo | Compatível. O tamanho alvo do ficheiro definido pela avaliação adaptativa é usado como o tamanho alvo para clustering. |
| Otimizar a escrita | Compatível. Produz ficheiros consolidados na escrita que são depois agrupados durante OPTIMIZE. |
| Compactação automática | Não utilize com liquid clustering no Runtime 1.3 ou em versões anteriores. Nesses ambientes de execução, cada acionamento da autocompactação reescreve todos os dados em Z-Cubes com menos de 100 GB, causando uma forte amplificação de escrita. No Runtime 2.0+, a autocompactação é compatível: o clustering incremental garante que apenas ficheiros novos ou pouco saudáveis são reescritos. A compactação automática gere a consolidação de pequenos ficheiros; OPTIMIZE gere a disposição do agrupamento. |
| Vetores de exclusão | Os ficheiros que excedem o limiar de linhas eliminadas são selecionados para agrupamento, independentemente do seu estado de agrupamento. |
| V-Order | Compatível. V-Order e liquid clustering operam em eixos diferentes (estrutura interna do ficheiro vs. intervalos de valores entre ficheiros). Ambos podem ser aplicados em conjunto. |
Melhores práticas
-
Execute
OPTIMIZEregularmente após escritas em lote ou de acordo com uma programação para tabelas de transmissão em fluxo — mas apenas em Runtime 2.0+, onde a estratégia de clustering incremental torna as execuções frequentes pouco dispendiosas. Na versão 1.3 do Runtime e nas anteriores, cada execução deOPTIMIZEreescreve todos os dados nos Z-Cubes com menos de 100 GB, pelo que as execuções devem ser deliberadas e pouco frequentes. -
Use
OPTIMIZE FULLcom moderação. Reserve-o para depois de alterar as colunas de agrupamento ou quando precisar de uma reposição pontual da qualidade. - Monitorize a qualidade do agrupamento verificando métricas de análise de consultas (ficheiros digitalizados vs. ficheiros totais) na interface do Spark ou nos planos de consulta.
- Combine com a otimização da escrita para cargas de trabalho de streaming, para garantir que cada micro-batch produza um número gerível de ficheiros para clustering.