Manutenção e otimização de tabela entre cargas de trabalho no Microsoft Fabric

As tabelas delta no Microsoft Fabric atendem a vários mecanismos de consumo, cada um com diferentes características de desempenho e requisitos de otimização. Este guia fornece uma estrutura abrangente para entender como as tabelas escritas por um mecanismo são consumidas por outras pessoas e como otimizar as estratégias de manutenção de tabela adequadamente.

Entender a relação entre padrões de gravação e desempenho de leitura entre diferentes mecanismos é essencial para criar plataformas de dados eficientes. O objetivo é garantir que os produtores de dados criem layouts de tabela que otimizem o desempenho de leitura para consumidores a jusante, independentemente de esses consumidores usarem o Spark, o endpoint de análise do SQL, o Power BI Direct Lake ou o Warehouse.

Matriz de cenário de gravação e leitura

A tabela a seguir resume as características de desempenho esperadas para combinações comuns de gravação e leitura, juntamente com estratégias de otimização recomendadas. Use essa matriz para identificar seu cenário e entender as diretrizes relevantes.

Método Write	Mecanismo de leitura	Lacunas esperadas	Estratégia recomendada
Lote do Spark	Spark	Sem lacunas	As configurações de gravação padrão do Spark são suficientes
Processamento em Lote do Spark	Ponto de extremidade de análise SQL	Sem lacunas	Habilitar compactação automática e otimizar gravação
Streaming do Spark	Spark	Arquivos pequenos possíveis	Compactação automática e otimização de gravação com OPTIMIZE agendado
Streaming do Spark	Ponto de extremidade de análise SQL	Arquivos pequenos e pontos de verificação	Compactação automática, otimização-gravação, divisão de camadas de medalhão
Armazém	Spark	Sem lacunas	Otimização gerenciada pelo sistema lida com o layout
Armazém	Ponto de extremidade de análise SQL	Sem lacunas	Otimização gerenciada pelo sistema lida com layout

Layouts de arquivo ideais por mecanismo

Diferentes mecanismos de consumo têm layouts de arquivo ideais diferentes. Entender esses alvos ajuda você a configurar adequadamente as operações de gravação e os trabalhos de manutenção.

Orientações para o endpoint de análise SQL e o Fabric Data Warehouse

Para otimizar o desempenho com o endpoint de análise SQL e o Warehouse, use as seguintes configurações:

Tamanho do arquivo de destino: cerca de 400 MB por arquivo
Tamanho do grupo de linha: cerca de 2 milhões de linhas por grupo de linha
Ordem V: melhora o desempenho de leitura em 10%

Um warehouse usa esses critérios para descobrir candidatos à compactação:

A sobrecarga do arquivo de tabela é superior a 10%
As linhas logicamente excluídas da tabela ultrapassam 10%
O tamanho da tabela é maior que 1.024 linhas

Durante a execução da compactação, o processo seleciona candidatos com base nesses critérios:

Qualquer arquivo é menor que 25% do tamanho ideal (com base na contagem de linhas)
Qualquer ficheiro tem mais de 20% de linhas apagadas.

Spark

O Spark é robusto ao ler vários tamanhos de arquivo. Para um desempenho ideal:

Tamanho do arquivo de destino: 128 MB a 1 GB, dependendo do tamanho da tabela
Tamanho do grupo de linhas: 1 milhão a 2 milhões de linhas por grupo de linhas
V-Order: não é necessário para melhorar o desempenho de leitura do Spark (pode adicionar de 15 a 33% sobrecarga na escrita)

O Spark lê o benefício do tamanho do arquivo de destino adaptável, que se ajusta automaticamente com base no tamanho da tabela:

Tabelas abaixo de 10 GB: meta de 128 MB
Tabelas acima de 10 TB: alvo de até 1 GB

Power BI Direct Lake

Para obter um desempenho ideal do Direct Lake:

Tamanho do grupo de linhas de destino: 8 milhões ou mais linhas por grupo de linhas para melhor desempenho
Ordem V: essencial para uma melhoria de 40 a 60% em consultas em cache frio
Contagem de arquivos: minimizar a contagem de arquivos para reduzir a sobrecarga de transcodificação
Tamanhos de arquivo consistentes: importante para o desempenho previsível da consulta

Os modelos semânticos do Direct Lake têm o melhor desempenho quando:

Os dados da coluna são ordenados por V para compactação compatível com VertiPaq
Os grupos de linhas são suficientemente grandes para uma eficiente mesclagem de dicionário.
Os vetores de exclusão são minimizados por meio da compactação regular

Para obter mais informações, consulte Noções básicas sobre o desempenho da consulta do Direct Lake.

Espelhamento

O espelhamento dimensiona automaticamente arquivos com base no volume da tabela:

Tamanho de tabela	Linhas por grupo de linhas	Linhas por arquivo
Pequeno (até 10 GB)	Dois milhões	10 milhões
Médio (10 GB a 2,56 TB)	4 milhões	60 milhões
Grande (mais de 2,56 TB)	8 milhões	80 milhões

Gravar padrões e configurações

Padrões de escrita no Spark

As gravações do Spark usam as seguintes configurações padrão:

Configuração	Valor padrão	DESCRIÇÃO
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Tamanho do arquivo de destino para gravações otimizadas
`spark.databricks.delta.optimizeWrite.enabled`	Varia de acordo com o perfil	Habilita a coalescagem automática de arquivos
`spark.databricks.delta.autoCompact.enabled`	Desabilitado	Habilita a compactação pós-gravação
`spark.sql.files.maxRecordsPerFile`	Unlimited	Máximo de registros por arquivo

Para configurar gravações do Spark para consumo de SQL subsequente:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Para obter mais informações sobre perfis de recursos e seus padrões, consulte Configurar configurações de perfil de recurso.

Padrões de gravação do armazém

O Warehouse otimiza automaticamente o layout de dados durante as gravações:

O V-Order está habilitado por padrão para otimização de leitura.
A compactação automática é executada como um processo em segundo plano.
O gerenciamento de ponto de verificação é tratado automaticamente.

O Warehouse produz arquivos otimizados para consumo de SQL sem intervenção manual. As tabelas escritas pelo Warehouse são otimizadas inerentemente para o endpoint de análise SQL e as leituras do Warehouse.

Operações de manutenção de tabela

Comando OPTIMIZE

O OPTIMIZE comando consolida arquivos pequenos em arquivos maiores:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Importante

O OPTIMIZE comando é um comando SQL do Spark. Você deve executá-lo em ambientes spark, como notebooks, definições de trabalho do Spark ou a interface de manutenção do Lakehouse. O endpoint de análise do SQL e o editor de consultas SQL do Armazém de Dados não dão suporte a esse comando.

Para obter mais informações, consulte Compactação de tabela.

Compactação automática

A compactação automática avalia automaticamente a integridade da partição após cada operação de gravação e dispara a otimização síncrona quando a fragmentação de arquivo é detectada:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Utilize compactação automática para pipelines de ingestão com gravações pequenas frequentes (streaming ou microbatch) para evitar o agendamento manual e manter os arquivos automaticamente compactados.

A compactação automática e a otimização de gravação normalmente produzem os melhores resultados quando usados juntos. A otimização da gravação reduz o número de arquivos pequenos gravados e a compactação automática manipula a fragmentação restante.

Para obter mais informações, consulte Compactação automática.

Otimizar gravação

A otimização da gravação reduz a sobrecarga de arquivos pequenos executando a compactação de pré-gravação, que gera menos arquivos maiores:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

A otimização da gravação é benéfica para:

Tabelas particionadas
Tabelas com pequenas inserções frequentes
Operações que tocam muitos arquivos (MERGE, UPDATE, DELETE)

A compactação de pré-gravação (otimização de gravação) geralmente é menos dispendiosa do que a compactação pós-gravação (otimização). Para obter mais informações, consulte Otimizar gravação.

Comando VACUUM

O VACUUM comando remove arquivos antigos que um log de tabela Delta não faz mais referência:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

O período de retenção padrão é de sete dias. A configuração de períodos de retenção mais curtos afeta os recursos de viagem no tempo da Delta e pode causar problemas com leitores ou gravadores simultâneos.

Para obter mais informações, consulte a manutenção da tabela Lakehouse.

Otimização do V-Order

O V-Order é uma otimização de tempo de gravação que aplica classificação, codificação e compactação compatíveis com VertiPaq aos arquivos Parquet:

Power BI Direct Lake: melhoria de 40 a 60% em consultas de cache frio
Endpoint de análise SQL e Armazém de Dados: aproximadamente 10% de melhoria no desempenho de leitura
Spark: Nenhum benefício inerente de leitura; escritas 15-33% mais lentas

Quando habilitar o V-Order

O V-Order oferece o maior benefício para:

Tabelas em camadas de ouro que servem o Power BI Direct Lake
Tabelas consultadas com frequência por meio do endpoint de análise SQL
Cargas de trabalho de leitura pesadas em que o desempenho de gravação é menos crítico

Quando evitar V-Order

Considere desativar o V-Order para:

Tabelas de camada bronze focadas na velocidade de ingestão
Pipelines de Spark para Spark em que o SQL e o Power BI não consomem os dados
Cargas de trabalho pesadas de escrita, nas quais a latência dos dados é crítica

Configurar o V-Order

O V-Order é desabilitado por padrão em novos workspaces do Fabric. Para habilitar:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Para aplicar seletivamente a Ordem V com base no consumo do Direct Lake, considere automatizar a ativação da Ordem V para tabelas utilizadas em modelos semânticos do Direct Lake. As tabelas não consumidas pelo Direct Lake podem permanecer sem V-Order para melhorar o desempenho de gravação.

Para obter mais informações, consulte a otimização da tabela Delta Lake e o V-Order.

Clustering líquido e ordem Z

Agrupamento líquido

O Clustering Líquido é a abordagem recomendada para a organização de dados. ** Ao contrário do particionamento tradicional, Liquid Clustering:

Adapta-se à alteração de padrões de consulta
Requer OPTIMIZE para aplicar a clusterização
Oferece melhor ignoramento de arquivos para consultas filtradas

Habilitar o Clustering Líquido ao criar a tabela.

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Ordem Z

O Z-Order coloca dados relacionados nos mesmos arquivos, para que você obtenha melhor desempenho de consulta em predicados de filtro.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Use o Z-Order quando:

Sua tabela é particionada porque o Clustering Líquido não funciona com tabelas particionadas.
Suas consultas geralmente filtram em duas ou mais colunas juntas.
Seus predicados são seletivos o suficiente para se beneficiarem do salto de arquivos.

Recomendações de arquitetura Medallion

A arquitetura de camadas em medalhão (camadas Bronze, Prata, Ouro) fornece uma estrutura de referência para otimizar estratégias de manutenção de tabelas com base na finalidade de cada camada.

Camada bronze (zona de destino)

As tabelas Bronze focam no desempenho de gravação e na ingestão de dados de baixa latência.

Prioridade de otimização: velocidade de ingestão em relação ao desempenho de leitura
Particionamento: Aceitável, mas desencorajado para novas implementações
Arquivos pequenos: aceitável, pois o foco está na velocidade de ingestão
V-Order: não recomendado (sobrecarrega a gravação)
Compactação automática: ativar para reduzir arquivos pequenos, mas pode ser sacrificada pela performance de ingestão
Vetores de exclusão: Habilitar para tabelas com padrões de mesclagem

Tabelas Bronze não devem ser servidas diretamente ao ponto de extremidade de análise do SQL ou aos usuários do Power BI Direct Lake.

Camada de prata (zona controlada)

Tabelas Silver equilibram o desempenho de leitura e gravação.

Prioridade de otimização: balancear entre a ingestão e o desempenho da consulta
Tamanhos de arquivo: moderado (128-256 MB) para dar suporte a operações de gravação e leitura
V-Order: opcional; habilite se o endpoint de análise SQL ou o consumo do Power BI for significativo
Clustering Líquido ou Z-Order: recomendado para otimizar o desempenho das consultas
Compactação automática e otimização de gravação: habilitar com base nos requisitos downstream
Vetores de exclusão: habilitar para tabelas com atualizações frequentes
OTIMIZAÇÃO Agendada: executar agressivamente para manter o layout do arquivo

Camada de ouro (zona de serviço)

As tabelas gold priorizam o desempenho de leitura para o consumo do usuário final:

Prioridade de otimização: ler o desempenho da análise
Tamanhos de arquivo: grande (400 MB a 1 GB) para um desempenho ideal do SQL e do Power BI
V-Order: é necessário para o Power BI Direct Lake; benéfico para o endpoint de análise SQL
Liquid Clustering: necessário para uma otimização no salto de arquivos
Otimizar gravação: necessário para tamanhos de arquivo consistentes
OTIMIZAÇÃO Agendada: executar agressivamente para manter o layout ideal

Otimize as tabelas de ouro de forma diferente com base no motor de consumo principal:

Mecanismo de consumo	Ordem V	Tamanho do arquivo de destino	Tamanho do grupo de linhas
Ponto de extremidade de análise SQL	Yes	400 MB	2 milhões de linhas
Power BI Direct Lake	Yes	400 MB a 1 GB	Mais de 8 milhões de linhas
Spark	Opcional	128 MB a 1 GB	1 a 2 milhões de linhas

Várias cópias de tabela

É aceitável manter várias cópias de tabelas otimizadas para padrões de consumo diferentes:

Uma tabela Silver otimizada para processamento do Spark
Uma tabela Gold otimizada para o endpoint de análise SQL e o Power BI Direct Lake
Pipelines de dados que transformam e organizam a estrutura apropriada em cada camada

O armazenamento é barato em relação à computação. Otimizar tabelas para seus padrões de consumo fornece uma melhor experiência do usuário do que tentar atender a todos os consumidores de um único layout de tabela.

Identificar a saúde da tabela

Antes de otimizar tabelas, avalie a integridade da tabela atual para entender as necessidades de otimização.

Inspecionar os arquivos Parquet diretamente

Você pode explorar a pasta de tabelas no OneLake para inspecionar os tamanhos dos arquivos Parquet individuais. Tabelas saudáveis têm tamanhos de arquivo distribuídos de forma uniforme. Procurar por:

Tamanhos de arquivo consistentes: os arquivos devem ter aproximadamente o mesmo tamanho (dentro de 2x um do outro).
Nenhum arquivo extremamente pequeno: arquivos com menos de 25 MB indicam fragmentação.
Nenhum arquivo extremamente grande: arquivos com mais de 2 GB podem reduzir o paralelismo.

A distribuição de tamanho de arquivo irregular geralmente indica compactação ausente ou padrões de gravação inconsistentes em diferentes trabalhos.

OTIMIZAR A EXECUÇÃO SECA no SQL do Spark

Use a opção DRY RUN para visualizar quais arquivos estão qualificados para otimização sem executar a compactação:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

O comando retorna uma lista de arquivos que seriam reescritos durante a otimização. Use isso para:

Avalie o escopo da otimização antes de executá-la.
Entenda a fragmentação de arquivo sem modificar a tabela.
Estimar o tempo de otimização com base no número de arquivos afetados.

Distribuição de tamanho do arquivo

Use a seguinte abordagem para analisar os tamanhos de arquivo e a distribuição:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

A distribuição pode ser distorcida, pois arquivos próximos ao cabeçalho da tabela ou de uma partição específica podem não ser otimizados.

Você pode avaliar a distribuição executando uma consulta que agrupa pelas chaves de particionamento ou de clustering da tabela.

Determinar as necessidades de otimização

Com base no mecanismo de consumo, compare os tamanhos de arquivo reais com os tamanhos de destino:

Engine	Tamanho do arquivo de destino	Se os arquivos forem menores	Se os arquivos forem maiores
Ponto de extremidade de análise SQL	400 MB	Execute `OPTIMIZE`	Arquivos são aceitáveis
Direct Lake do Power BI	400 MB a 1 GB	Execute `OPTIMIZE VORDER`	Arquivos são aceitáveis
Spark	128 MB a 1 GB	Habilitar a compactação automática	Arquivos são aceitáveis

Histórico de tabelas e log de transações

Examine o histórico de tabelas para entender os padrões de gravação e a frequência de manutenção:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Práticas recomendadas de configuração

Usar propriedades de tabela em configurações de sessão

As propriedades da tabela persistem entre sessões e garantem um comportamento consistente em todos os trabalhos e escritores.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

As configurações de nível de sessão só se aplicam à sessão atual do Spark e podem causar gravações inconsistentes se sessões diferentes usarem configurações diferentes.

Habilitar o tamanho do arquivo de destino adaptável

O tamanho do arquivo de destino adaptável ajusta automaticamente os destinos de tamanho do arquivo com base no tamanho da tabela:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Este recurso:

Começa com arquivos menores (128 MB) para tabelas pequenas
Escalona até 1 GB para tabelas com mais de 10 TB
Reavalia automaticamente durante as operações de OPTIMIZE

Habilitar destinos de compactação no nível do arquivo

Impedir a reescrita de arquivos compactados anteriormente quando os tamanhos de destino forem alterados:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Resumo das recomendações

Camada	Compactação automática	Otimizar gravação	Ordem V	Agrupamento líquido	OTIMIZAÇÃO Agendada
Bronze	Habilitar (opcional)	Enable	Não	Não	Opcional
Prata	Enable	Enable	Opcional	Yes	Agressivo
Ouro	Enable	Enable	Yes	Yes	Agressivo

Para cenários específicos, use as seguintes recomendações:

Spark-to-Spark: foco na otimização do tamanho do arquivo; V-Order opcional.
Spark-to-SQL: habilitar otimização-gravação e compactação automática; direcionar arquivos de 400 MB com 2 milhões de grupos de linhas.
Ingestão de streaming: habilitar a compactação automática; agendar trabalhos adicionais OPTIMIZE para consumidores do SQL.
Power BI Direct Lake: Habilitar Ordem-V; o alvo é mais de 8 milhões de grupos de linhas; executar OPTIMIZE VORDER.

Comentários

Esta página foi útil?

Last updated on 2026-02-13