Incremental Liquid Clustering no Microsoft Fabric: Mais rápido, inteligente e verdadeiramente incremental

TL;DR: O Incremental Liquid Clustering no Microsoft Fabric reduz o custo de manutenção de clustering ao reescrever apenas arquivos novos ou desorganizados, eliminando o crescimento linear do algoritmo tradicional. Benchmarks mostram até 8,9x de aceleração em operações OPTIMIZE e qualidade de data skipping comparável ou superior. Disponível no Fabric Runtime 2.0 sem alterações de configuração.

Liquid Clustering vem transformando a forma como times de dados gerenciam a organização de tabelas no lakehouse, substituindo partições rígidas do estilo Hive por um layout flexível que se adapta às cargas de trabalho. Porém, até agora, toda execução de OPTIMIZE reescrevia muito mais dados do que o necessário, tornando o custo de clustering imprevisível e cada vez mais alto conforme as tabelas cresciam.

Com o Incremental Liquid Clustering, o Microsoft Fabric resolve esse desequilíbrio. O algoritmo identifica e processa apenas os arquivos que realmente precisam de reorganização: dados recém-adicionados sem metadados de clustering, arquivos pequenos que precisam de compactação e arquivos com vetores de exclusão acumulados. Arquivos já bem clusterizados e com tamanho saudável são ignorados.

Por que isso importa?

Liquid Clustering reduz custos de consulta ao organizar os dados para que as queries leiam apenas os arquivos necessários. Uma tabela bem clusterizada significa menos arquivos escaneados, menos I/O e resultados mais rápidos. Mas manter esse layout tem um custo: cada OPTIMIZE gasta compute reescrevendo arquivos.

O algoritmo padrão do Delta Lake open source reescreve todos os dados dentro de grupos de arquivos clusterizados até que ultrapassem 100 GB, em cada OPTIMIZE, independentemente de os arquivos já estarem bem organizados. Adicione 1 KB a uma tabela de 99 GB? Ele reescreve mais de 99 GB. Isso faz o custo crescer com o tamanho da tabela, não com o volume de dados novos — e para tabelas grandes, o custo de manutenção pode superar os ganhos de desempenho que o clustering proporciona.

O Incremental Liquid Clustering corrige essa equação: mesmo desempenho em consultas, fração do custo de manutenção.

Como funciona?

Em vez de reescrever tudo, o OPTIMIZE agora identifica e processa apenas arquivos que realmente precisam de clustering:

• Arquivos não clusterizados: dados recém-adicionados sem metadados de clustering.
• Arquivos pequenos: abaixo do tamanho alvo, que devem ser compactados.
• Arquivos com deletion vectors: com acúmulo de exclusões acima do limite de limpeza.

Arquivos já bem clusterizados e com tamanho saudável são ignorados. Os novos dados são roteados para grupos existentes de arquivos clusterizados, mantendo a continuidade do layout sem reescrever o que já está no lugar certo. O resultado é uma operação de clustering em tempo constante, que escala com o tamanho dos dados novos, não com o da tabela.

O que é Auto Reclustering?

Se apenas arquivos novos são clusterizados, a qualidade pode degradar silenciosamente à medida que novos dados se sobrepõem a faixas existentes. O Incremental Liquid Clustering inclui Auto Reclustering para lidar com isso: o algoritmo identifica clusters de arquivos sobrepostos e seletivamente reclusteriza os arquivos degradados à medida que os limites de sobreposição são excedidos. A qualidade permanece alta conforme os dados evoluem, sem intervenção manual.

Qual o desempenho? Até 8,9x mais rápido

Os benchmarks a seguir cobrem três padrões de carga de trabalho que representam as formas mais comuns de ingestão de dados em tabelas Delta, cada um executando 200 iterações de write, OPTIMIZE e uma consulta seletiva final para testar a qualidade do clustering:

• Streaming Ingest: pequenos appends contínuos sem sobreposição (telemetria IoT, clickstream, logs).
• Analytics Table: appends com sobreposição total (tabelas dimensão, datasets com atualizações em toda faixa de chave).
• ETL Pipeline: operações MERGE com sobreposição parcial (cargas incrementais via CDC, atualizações de pedidos, sincronia de clientes).

Carga de trabalho	Padrão (média)	Incremental (média)	Aceleração
Streaming Ingest (append, sem sobreposição)	32,3s	3,7s	8,9x
Analytics Table (append, sobreposição total)	34,3s	6,3s	5,5x
ETL Pipeline (merge, sobreposição parcial)	29,7s	6,1s	4,9x

Essas médias subestimam o problema. O algoritmo padrão apresenta crescimento ilimitado dentro de grupos de 100 GB — conforme as tabelas acumulam dados, o tempo de otimização escala linearmente com o tamanho da tabela, não com o lote. Nas iterações 150–200, o algoritmo padrão chega a picos de 54 a 65 segundos por execução, enquanto o incremental se mantém abaixo de 10 segundos. A qualidade do clustering permanece comparável: reescrever arquivos já clusterizados não melhora o data skipping, apenas desperdiça compute.

Como o Fabric se compara à concorrência?

O Incremental Liquid Clustering do Fabric foi comparado com a implementação de liquid clustering de outro fornecedor nos mesmos três padrões de carga de trabalho, medindo duração da otimização e qualidade do clustering. O código-fonte para reprodução está disponível no GitHub.

Nas três cargas, o Fabric clusteriza dados 1,6x mais rápido em média, escaneando 11% menos arquivos por consulta seletiva. A diferença é mais acentuada em cargas com merge, onde o Fabric é mais de 3x mais rápido — exatamente o padrão que a maioria dos usuários de Apache Spark utiliza.

Para cargas de merge, o gráfico de dispersão por iteração mostra o quadro completo. O outro fornecedor degrada drasticamente a partir da iteração 100, enquanto o Fabric se mantém consistente e rápido.

O Fabric alcança qualidade de data skipping comparável ou superior em todos os três padrões, com mais de 11% menos arquivos escaneados por consulta no cenário de append com sobreposição total.

Como começar?

O Incremental Liquid Clustering está disponível no Fabric Runtime 2.0 com Delta 4.1 e Spark 4.1. É ativado por padrão, sem necessidade de alteração de configuração. Basta executar OPTIMIZE nas tabelas com Liquid Clustering e o novo algoritmo assume automaticamente.

Copiar# Criar uma tabela com Liquid Clustering (ou alterar uma existente)
spark.sql("""
    CREATE TABLE events CLUSTER BY (event_date, region)
    AS SELECT * FROM ...
""")

# OPTIMIZE agora usa Incremental Liquid Clustering automaticamente
spark.sql("""
    OPTIMIZE events
""")

Caso precise de um recluster completo (por exemplo, após alterar chaves de clustering), execute:

Copiarspark.sql("""
    OPTIMIZE events FULL
""")

O que isso significa para suas cargas de trabalho?

• Pipelines de streaming e near-real-time: OPTIMIZE em segundos, não minutos, mesmo com tabelas de centenas de gigabytes. Manutenção de clustering compatível com SLAs.
• Pipelines ETL e batch: custos de compute drasticamente menores para otimização pós-carga. O mesmo cluster atende mais tabelas.
• Tabelas analíticas: alta performance de consulta com data skipping mantida automaticamente conforme os dados evoluem. Sem ajuste manual ou reclusters periódicos.

Próximos passos

O Incremental Liquid Clustering é um grande passo em direção a um lakehouse auto-otimizável. Ao combinar seleção inteligente de arquivos com manutenção automática de qualidade, o Fabric elimina o trade-off entre qualidade do clustering e custo. Teste hoje no Fabric Runtime 2.0 e experimente um clustering que escala com seus dados, não contra eles.

Perguntas Frequentes

• O Incremental Liquid Clustering funciona em tabelas já existentes com Liquid Clustering?
  Sim. Basta executar OPTIMIZE normalmente. O novo algoritmo assume automaticamente para todas as tabelas clusterizadas no Fabric Runtime 2.0, sem necessidade de migração ou alteração de schema.

• Preciso mudar minha configuração ou código para ativar o Incremental Liquid Clustering?
  Não. Ele está habilitado por padrão no Fabric Runtime 2.0. Não é necessário alterar nenhum parâmetro. O comando OPTIMIZE passa a usar o algoritmo incremental automaticamente.

• Como o custo de manutenção de clustering é afetado?
  O custo passa a escalar com o volume de dados novos, não com o tamanho total da tabela. Em cargas de trabalho ELT com merge, o tempo de OPTIMIZE caiu de até 65s para menos de 10s por iteração, reduzindo significativamente o consumo de compute.

• E se eu precisar refazer o clustering completo (por exemplo, após alterar chaves de clustering)?
  Ainda é possível forçar um recluster completo executando OPTIMIZE FULL. Isso reescreve todos os arquivos, ignorando a lógica incremental.

---

Artigo originalmente publicado por Miles Cole em Azure Updates - Latest from Azure Charts.