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

As tabelas Delta no Microsoft Fabric podem dar suporte ao Spark, ao endpoint de análise SQL, ao Power BI Direct Lake, ao Warehouse e a outras experiências do Fabric a partir de dados armazenados no OneLake. O desempenho ótimo entre cargas de trabalho depende de dois fatores:

• A carga de trabalho que cria e mantém a tabela.
• Os mecanismos que consomem a tabela.

As tabelas Lakehouse são comumente gerenciadas pelo Spark, Fabric pipeline atividade Copy ou Dataflow Gen2. O Spark é o gravador mais comum e oferece a maior variedade de controles de layout e manutenção. O espelhamento de armazéns de dados e de bancos de dados gerencia automaticamente seus layouts físicos. Catálogos espelhados mantêm o layout gerenciado no sistema fonte. Os requisitos do consumidor são geralmente compatíveis, mas o Power BI Direct Lake possui requisitos adicionais de armazenamento para desempenho ideal.

Use uma tabela compartilhada sempre que seus requisitos forem compatíveis. Para as exceções que justificam outra tabela, veja Quando criar outra tabela.

Entenda a responsabilidade pelo layout

Comece identificando qual carga de trabalho é responsável pela estrutura física da tabela. Os controles na tabela a seguir são os principais controles relevantes para o layout e manutenção da tabela de carga cruzada, e não uma lista exaustiva das capacidades de cada motor.

Orientação entre cargas de trabalho

A tabela a seguir resume a abordagem recomendada por produtor e consumidor.

Otimizar tabelas Lakehouse

As tabelas Delta Lakehouse exigem uma estratégia de manutenção explícita, independentemente de Spark, Pipeline atividade Copy ou Dataflow Gen2 escrevê-las. O Spark é o principal exemplo nesta seção porque oferece os controles de layout e manutenção mais amplos do Fabric.

Use os padrões de runtime do Spark

Quando o Spark grava a tabela, use o tempo padrão do Fabric Spark 2.0 ou posterior:

• Mantenha o tamanho adaptativo do arquivo alvo ativado. Ele seleciona automaticamente um alvo para cada tabela, de 128 MB a 1 GB.
• Mantenha os alvos de compactação em nível de arquivo ativados para evitar reescrever arquivos que atingiram um alvo adaptativo anterior.
• Mantenha os vetores de exclusão ativados.
• Não imponha um número máximo arbitrário de linhas por arquivo. A largura das linhas varia, então um limite de linha pode criar arquivos excessivamente pequenos para tabelas estreitas.

No ambiente de execução do Fabric Spark 1.3, tamanho de arquivo de destino adaptável, destinos de compactação no nível do arquivo e vetores de exclusão estão disponíveis como configurações opcionais.

Quando o Pipeline atividade Copy ou o Dataflow Gen2 escrevem a tabela, inspecione o layout de arquivos resultante e programe a manutenção separadamente. Não presuma que esses redatores aplicam padrões de runtime do Spark.

• Os pipelines do Fabric podem orquestrar uma atividade de manutenção do Lakehouse após as gravações.

Prevenir e compactar arquivos pequenos

Para tabelas escritas pelo Spark, prefira autocompactação. Esse recurso avalia a fragmentação da tabela após as gravações e executa compactação apenas quando necessário. Isso elimina a necessidade de uma verificação separada da saúde da mesa antes da manutenção.

Use as seguintes orientações para exceções e recursos complementares:

OPTIMIZE compacta arquivos e elimina automaticamente os vetores de exclusão de um arquivo quando mais de 5% de seus registros são referenciados por vetores de exclusão. Use REORG TABLE ... APPLY (PURGE) apenas quando você precisar eliminar fisicamente registros abaixo desse limite ou atender a um requisito específico de conformidade.

Execute VACUUM em um cronograma separado para remover arquivos não referenciados após o período de retenção. VACUUM Recupera o armazenamento, mas não melhora o layout do arquivo ativo.

Organize os dados para pular arquivos

Use liquid clustering quando padrões recorrentes de filtragem ou processamento se beneficiam de ignorar arquivos. Tabelas com clusterização líquida exigem OPTIMIZEou compactação automática para organizar os dados gravados recentemente.

Evite particionar por padrão. Use-o quando um requisito específico justificar os tradeoffs operacionais, como isolar escritores concorrentes que atualizam, excluem ou mescem dados entre partições disjuntas. Para mais informações, veja Quando usar particionamento.

Para tabelas particionadas existentes, considere a Ordem Z quando predicados seletivos comumente filtram nas mesmas colunas dentro de uma partição.

Otimize as tabelas gerenciadas pelo Warehouse

Fabric Data Warehouse gerencia o layout físico da tabela Delta independentemente do método de ingestão.

Use os controles estratégicos que o Warehouse expõe para ajustar o layout dos dados:

• Aplique agrupamento de dados a tabelas grandes quando as consultas usarem repetidamente predicados seletivos nas mesmas colunas.
• Mantenha V-Order ativado para cargas de trabalho voltadas para leitura e mistas. A V-Order está ativada por padrão.
• Considere desativar V-Order para cargas de trabalho de data warehouse com uso intensivo de gravação.

Para orientações completas sobre o Armazém, consulte as diretrizes de desempenho em Fabric Data Warehouse.

Otimizar dados espelhados

Sua capacidade de melhorar o layout físico depende se o Fabric replica os dados ou faz referência a arquivos fonte:

• Espelhamento de banco de dados: O Fabric replica os dados de origem em tabelas Delta no OneLake e gerencia o layout e a manutenção dos arquivos V-Order. Você não pode configurar diretamente o tamanho de arquivo de destino, a limpeza de vetores de exclusão, o clustering líquido, o particionamento nem o V-Order no destino espelhado.
• Catálogos espelhados: O Fabric sincroniza metadados e usa atalhos do OneLake para referenciar dados de origem no local. O Fabric não reescreve nem mantém esses arquivos. Melhore a disposição física e a limpeza do sistema de origem quando os recursos com suporte permitirem. Essas mudanças são visíveis por meio dos atalhos, sem que outra cópia seja criada no Fabric.

Para dados espelhados no banco de dados:

• Use predicados seletivos e evite colunas desnecessárias em consultas do Spark e SQL.
• Projete modelos semânticos e medidas DAX do Power BI para consumo eficiente de Direct Lake.

Para catálogos espelhados:

• Use os recursos de manutenção e layout de tabelas compatíveis com a plataforma de origem.
• Avalie o arquivo fonte e a distribuição por grupos de linhas para os consumidores do Fabric que consultam os atalhos.
• Para Direct Lake, avalie a criação de uma camada adicional de disponibilização, com modelagem dimensional e V-Ordered, quando o layout de origem não puder atender aos requisitos de desempenho.

Para espelhar conceitos, tipos e fontes suportadas, veja O que é o Espelhamento no Fabric? e Como funciona o espelhamento de metadados.

Aplicar otimização específica para o consumidor

O Spark e o endpoint de análise de SQL apresentam bom desempenho na mesma arquitetura adaptativa de lakehouse. Use tamanho de arquivo alvo adaptativo, evite a criação excessiva de arquivos pequenos e aplique liquid clustering quando os predicados medidos se beneficiarem de uma eliminação de arquivos aprimorada. Não ative o V-Order somente por causa do desempenho do Spark ou do endpoint de análise SQL. Para detalhes específicos do motor, veja considerações de desempenho de endpoints em análise SQL.

Lago Direto do Power BI

O Direct Lake usa as mesmas tabelas Delta subjacentes, mas adiciona recomendações relacionadas à transcodificação e enquadramento incremental:

• Layout de arquivo e de grupos de linhas: Evite grupos de linhas pequenos e uma distribuição desigual dos grupos de linhas, o que cria mais segmentos de coluna VertiPaq e aumenta a sobrecarga de transcodificação.
• V-Order: Siga a recomendação específica do produtor na orientação de carga de trabalho cruzada. Para tabelas gravadas pelo Spark consumidas principalmente por meio do Direct Lake, ative V-Order ou use o readHeavyForPBIperfil de recursos.
• Padrões de atualização: Prefira padrões de atualização amigáveis para anexar sempre que possível para preservar arquivos Parquet existentes e suportar enquadramento incremental.

Para tabelas escritas pelo Spark, define spark.sql.parquet.native.writer.maxRowGroupRowCount o número máximo de linhas por grupo de linhas quando o motor de execução nativo grava os arquivos Parquet. O valor padrão é 0, que não impõe um máximo. Se a análise mostrar que o dimensionamento dos grupos de linhas está afetando o desempenho do Direct Lake, defina um limite testado antes de escrever ou reescrever a tabela. Por exemplo:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Não defina o limite apenas para atingir uma contagem específica de linhas. Largura de linha, compressão, distribuição de arquivos e paralelismo de capacidade também afetam o desempenho. Use o Delta Analyzer para avaliar o layout resultante.

Para orientações detalhadas sobre enquadramento, transcodificação, grupos de linhas, padrões de atualização e Delta Analyzer, consulte Entenda o desempenho das consultas do Direct Lake.

Aplique as diretrizes às camadas medallion

Bronze, Prata e Ouro descrevem o propósito e o refinamento dos dados. Eles não determinam se o layout é gerenciado pelo usuário ou pelo sistema, e não exigem cópias separadas para cada consumidor.

Resolver problemas de layout e manutenção

Use remediação consciente do produtor. Aplique comandos de manutenção do Spark às tabelas lakehouse quando o modo de destino der suporte a essas operações. Trate os sinais como indicadores, e não como limiares universais, e valide-os em relação ao padrão de escrita da tabela e ao desempenho do consumidor.

Para dados espelhados, siga as medidas de correção específicas do produtor em Otimizar dados espelhados. O espelhamento de banco de dados é gerenciado pelo sistema; Para catálogos espelhados, aplique manutenção suportada na plataforma de origem.

Para tabelas do lakehouse, as opções de inspeção suportadas pelo Spark incluem:

• Execute DESCRIBE DETAIL para inspecionar a contagem de arquivos, o tamanho total e a propriedade avaliada delta.targetFileSize.adaptive .
• Corra DESCRIBE HISTORY para revisar padrões de escrita e histórico de manutenção.
• Use o Delta Analyzer quando precisar de uma análise detalhada dos grupos de linhas do Direct Lake e dos padrões de atualização.

Inspecionar o tamanho médio dos arquivos

Use DESCRIBE DETAIL para calcular o tamanho médio do arquivo como um indicador inicial do layout da tabela:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Uma média pode esconder o descompasso entre partições ou arquivos recentes e previamente compactados. Se a média indicar um possível problema de layout, inspecione os arquivos de Parquet individuais ou use o Delta Analyzer para avaliar a distribuição antes de alterar as configurações de manutenção.

Quando criar outra tabela

Não crie outra tabela física apenas porque múltiplos motores Fabric consomem os dados.

Crie outra tabela quando ela tiver um propósito independente, como:

• Uma transformação ou agregação que altera o grão ou o significado comercial dos dados.
• Requisitos diferentes de segurança, retenção ou qualidade dos dados.
• Um requisito de latência ou atualização que a tabela compartilhada não consegue cumprir.
• Um layout específico para o consumidor, cujo benefício medido supera seus custos de armazenamento, processamento, linhagem e governança.

Conteúdo relacionado

• Ajuste o tamanho dos arquivos de dados da tabela Delta
• Compactação das tabelas Delta
• Vetores de exclusão para tabelas Delta
• Aplicar agrupamento líquido em tabelas Delta
• Particionamento para tabelas Delta
• Otimize tabelas Delta Lake com V-Order
• Considerações de desempenho do endpoint de análise SQL
• Entenda o desempenho de consulta do Direct Lake
• diretrizes de desempenho no Fabric Data Warehouse
• Agrupamento de dados no Fabric Data Warehouse
• O que é Espelhamento no Tecido?