Manutenção e otimização de tabelas de carga de trabalho cruzadas no Microsoft Fabric

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

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

As tabelas Lakehouse são normalmente geridas pelo Spark, Fabric pipeline atividade Copy ou Dataflow Gen2. O Spark é o editor mais comum e oferece as opções mais abrangentes de esquema e manutenção. O armazém de dados e o espelhamento da base de dados gerem automaticamente as suas estruturas físicas. Os catálogos espelhados mantêm o layout gerido no sistema de origem. Os requisitos do consumidor são geralmente compatíveis, mas o Power BI Direct Lake tem requisitos adicionais de armazenamento para um desempenho ótimo.

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

Compreender a titularidade do layout

Comece por identificar que carga de trabalho é responsável pela estrutura física da tabela. Os controlos na tabela seguinte são os controlos-chave relevantes para a disposição e manutenção da tabela de carga cruzada, não uma lista exaustiva das capacidades de cada motor.

Orientação entre cargas de trabalho

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

Otimizar tabelas Lakehouse

As tabelas Delta do Lakehouse requerem uma estratégia de manutenção explícita, independentemente de serem escritas pelo Spark, pela atividade Copy do Pipeline ou pelo Dataflow Gen2. O Spark é o principal exemplo nesta secção porque fornece os controlos de layout e manutenção mais amplos em Fabric.

Usar os valores de execução padrão do Spark

Quando o Spark escreve a tabela, utilize as predefinições do Fabric Spark runtime 2.0 ou posterior:

• Mantenha o tamanho adaptativo do ficheiro de destino ativado. Seleciona automaticamente um alvo para cada tabela, de 128 MB a 1 GB.
• Mantenha os alvos de compactação ao nível do ficheiro ativados para evitar reescrever ficheiros que atingiram um alvo adaptativo anterior.
• Mantém os vetores de eliminação ativados.
• Não imponha um número máximo arbitrário de linhas por ficheiro. A largura das linhas varia, por isso um limite de linhas pode criar ficheiros demasiado pequenos para tabelas estreitas.

No runtime 1.3 do Fabric Spark, o tamanho de ficheiro de destino adaptativo, os objetivos de compactação ao nível do ficheiro e os vetores de eliminação estão disponíveis como definições de adesão opcional.

Quando o Pipeline atividade Copy ou o Dataflow Gen2 escrevem a tabela, inspecionem o layout resultante do ficheiro e programem a manutenção separadamente. Não presuma que estes escritores aplicam os padrões de execução do Spark.

• Os pipelines do Fabric podem orquestrar uma atividade de manutenção do Lakehouse após a escrita.

Prevenir e compactar ficheiros pequenos

Para tabelas escritas pelo Spark, prefira autocompactação. Esta funcionalidade avalia a fragmentação da tabela após escritas e executa compactação apenas quando necessário. Elimina a necessidade de uma verificação separada do estado da tabela antes das operações de manutenção.

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

OPTIMIZE compacta ficheiros e purga automaticamente os vetores de eliminação de um ficheiro quando mais de 5% dos seus registos são referenciados por vetores de eliminação. Use REORG TABLE ... APPLY (PURGE) apenas quando tiver de purgar fisicamente registos abaixo desse limite ou cumprir um requisito específico de conformidade.

Executa VACUUM num calendário separado para remover ficheiros não referenciados após o período de retenção. VACUUM Recupera o armazenamento mas não melhora o layout ativo dos ficheiros.

Organizar os dados para o salto de ficheiros

Utilize clusterização líquida quando padrões recorrentes de filtragem ou processamento beneficiam de uma melhor omissão de ficheiros. Tabelas clusterizadas líquidas requerem OPTIMIZEou autocompactação para organizar dados recém-escritos.

Evita o particionamento por defeito. Utilize-o quando um requisito específico justifica os compromissos operacionais, como isolar escritores concorrentes que atualizam, eliminam ou fundem dados entre partições disjuntas. Para mais informações, veja Quando usar particionamento.

Para tabelas particionadas existentes, considere Z-Order quando predicados seletivos filtram normalmente pelas mesmas colunas dentro de uma partição.

Otimizar tabelas geridas em armazém de dados

Fabric Data Warehouse gere a disposição física da tabela Delta independentemente do método de ingestão.

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

• Aplique agrupamento de dados a tabelas grandes quando as consultas utilizam repetidamente predicados seletivos nas mesmas colunas.
• Mantenha o V-Order ativado para cargas de trabalho orientadas à leitura e mistas. A V-Order está ativada por defeito.
• Considere desativar a V-Order para cargas de trabalho de armazém de dados com utilização intensiva de escrita.

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

Otimizar dados espelhados

A sua capacidade de melhorar o layout físico depende de o Fabric replicar os dados ou referenciar ficheiros fonte:

• Espelhamento de base de dados: O Fabric replica os dados de origem em tabelas Delta no OneLake e gere a disposição e a manutenção dos ficheiros V-Ordered. Não é possível configurar diretamente o tamanho alvo do ficheiro, a limpeza de vetores de eliminação, o agrupamento líquido, o particionamento ou a V-Order no destino espelhado.
• Catálogos espelhados: O Fabric sincroniza metadados e utiliza atalhos do OneLake para referenciar dados de origem no local. O Fabric não reescreve nem mantém estes ficheiros. Melhorar o layout físico e a limpeza no sistema de origem quando as funcionalidades suportadas o permitirem. Essas alterações são visíveis através dos atalhos sem criar outra cópia no Fabric.

Para dados espelhados na base de dados:

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

Para catálogos espelhados:

• Utilize os recursos suportados de manutenção de tabelas e de esquema da plataforma de origem.
• Avalie o ficheiro de origem e a distribuição por grupos de linhas para os utilizadores do Fabric que consultam os atalhos.
• Para o Direct Lake, avalie a criação de uma camada adicional para disponibilização, modelada dimensionalmente e V-Ordered, quando o esquema de origem não consegue satisfazer os 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 SQL têm um bom desempenho na mesma estrutura adaptativa de lakehouse. Use tamanho de ficheiro-alvo adaptativo, evite ficheiros excessivamente pequenos e aplique agrupamento líquido quando os predicados medidos beneficiam de um salto de ficheiros melhorado. Não ative V-Order apenas para melhorar o desempenho no Spark ou em pontos finais de análise de SQL. Para detalhes específicos do motor, veja considerações de desempenho em endpoints de análise SQL.

Power BI Direct Lake

O Direct Lake utiliza as mesmas tabelas Delta subjacentes, mas acrescenta recomendações relacionadas com transcodificação e enquadramento incremental:

• Disposição de ficheiros e grupos de linhas: Evite grupos de linhas pequenos e distribuição desigual dos grupos, pois isto 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 e consumidas principalmente no Direct Lake, ative V-Order ou utilize o readHeavyForPBIperfil de recursos.
• Padrões de atualização: Prefira padrões de atualização adequados para acrescentar sempre que possível para preservar ficheiros 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 escreve os ficheiros 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á a afetar 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 definas o limite apenas para atingir um número específico de linhas. Largura de linha, compressão, distribuição de ficheiros 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 Compreender o desempenho das consultas Direct Lake.

Aplique a orientação às camadas de medalhão

Bronze, Silver e Gold descrevem o propósito e o refinamento dos dados. Eles não determinam se o layout é gerido pelo utilizador ou pelo sistema, nem exigem cópias separadas para cada consumidor.

Resolver problemas de layout e manutenção

Utilize remediação com reconhecimento do produtor. Aplicar comandos de manutenção do Spark às tabelas do lakehouse quando o modo de destino suportar essas operações. Trate os sinais como indicadores em vez de limiares universais e valide-os em função do padrão de escrita da tabela e do desempenho do consumidor.

Para dados espelhados, siga o procedimento de correção específico do produtor em Otimizar dados espelhados. O espelhamento de bases de dados é gerido pelo sistema; Para catálogos espelhados, aplicar 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 o número de ficheiros, o tamanho total e a propriedade avaliada delta.targetFileSize.adaptive .
• Execute DESCRIBE HISTORY para analisar os padrões de gravação e o histórico de manutenção.
• Use o Delta Analyzer quando precisar de uma análise detalhada de grupos de linhas Direct Lake e de padrões de atualização.

Inspecionar o tamanho médio dos ficheiros

Use DESCRIBE DETAIL para calcular o tamanho médio do ficheiro 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 assimetrias entre partições ou entre ficheiros recentes e ficheiros compactados anteriormente. Se a média indicar um possível problema de layout, inspecione os ficheiros 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 tiver um propósito independente, tais como:

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

Conteúdo relacionado

• Ajuste o tamanho dos ficheiros de dados da tabela Delta
• Compactação de tabelas Delta
• Vetores de eliminação para tabelas Delta
• Aplicar agrupamento líquido em tabelas Delta
• Particionamento para tabelas Delta
• Otimizar tabelas Delta Lake com V-Order
• Considerações sobre o desempenho do endpoint de análise SQL
• Compreender o desempenho das consultas Direct Lake
• Diretrizes de desempenho no Fabric Data Warehouse
• Agrupamento de dados no Fabric Data Warehouse
• O que é espelhamento em malha?