Considerações sobre o desempenho do endpoint de análise SQL

O endpoint de análise SQL permite que você consulte dados no lakehouse usando a linguagem T-SQL e o protocolo TDS. Ele aproveita o motor Fabric Data Warehouse.

Dica

Para obter orientações abrangentes sobre como otimizar tabelas Delta para uso em terminais de análise SQL, incluindo recomendações de tamanho de arquivo e de grupo de linhas, consulte Manutenção e otimização de tabelas entre cargas de trabalho.

Cada lakehouse tem um ponto de extremidade de análise SQL. O número de pontos de extremidade de análise SQL em um espaço de trabalho corresponde ao número de lakehouses e bancos de dados espelhados provisionados nesse mesmo espaço de trabalho.

Um processo em segundo plano é responsável por examinar o lakehouse em busca de alterações e manter o endpoint de análise SQL atualizado com todas as alterações confirmadas nos lakehouses em um espaço de trabalho. A plataforma Fabric gerencia o processo de sincronização de forma transparente. Quando uma alteração é detectada em um data lakehouse, um processo em segundo plano atualiza os metadados, e o ponto de extremidade de análise SQL reflete as alterações efetuadas nas tabelas do data lakehouse. Em condições normais de operação, a latência entre um lakehouse e um ponto de extremidade de análise SQL é inferior a um minuto. O tempo real pode variar de alguns segundos a minutos, dependendo de muitos fatores que este artigo discute. O processo em segundo plano roda enquanto o endpoint de análise SQL está ativo e para após 15 minutos sem atividade de consulta.

Orientação

A descoberta automática de metadados rastreia as alterações comprometidas nos lakehouses e é uma instância singular por espaço de trabalho do Fabric. Se você observar um aumento na latência para que as alterações sejam sincronizadas entre os lakehouses e o endpoint de análise SQL, isso pode ocorrer devido a um grande número de lakehouses em um espaço de trabalho. Nesse cenário, considere migrar cada lakehouse para um espaço de trabalho separado, pois essa abordagem permite que a descoberta automática de metadados escale.
Os arquivos Parquet são imutáveis por design. Quando há uma operação de atualização ou exclusão, uma tabela Delta adiciona novos arquivos Parquet com o conjunto de alterações, o que aumenta o número de arquivos ao longo do tempo, dependendo da frequência de atualizações e exclusões. Se você não agendar a manutenção, esse padrão acabará criando uma sobrecarga nas leituras, e isso afetará o tempo necessário para sincronizar as alterações com o endpoint de análise SQL. Para resolver esse problema, agende operações regulares de manutenção da tabela lakehouse.
Em alguns cenários, você pode observar que as alterações confirmadas em um lakehouse não são visíveis no endpoint de análise SQL associado. Por exemplo, você pode criar uma nova tabela no lakehouse, mas ela ainda não está listada no endpoint de análise SQL. Ou você pode gravar um grande número de linhas em uma tabela de um lakehouse, mas os dados ainda não estão visíveis no endpoint de análise SQL. Você pode iniciar a sincronização de metadados sob demanda no Portal do Fabric ou usar a API REST para atualizar os metadados do endpoint de análise SQL.
O processo de sincronização automática não dá suporte a todos os recursos delta. Para obter mais informações sobre a funcionalidade suportada de cada mecanismo no Fabric, consulte a interoperabilidade do formato de tabela Delta Lake.
Se houver um volume extremamente grande de alterações de tabela durante o processamento de ETL (Extração de Transformação e Carga), ocorrerá um atraso esperado até que todas as alterações sejam processadas.

Otimizando tabelas lakehouse para consultar o ponto de extremidade de análise do SQL

Quando o endpoint de análise SQL lê tabelas armazenadas em um lakehouse, o desempenho da consulta depende fortemente do layout físico dos arquivos Parquet subjacentes. O motor paraleliza varreduras no nível do arquivo Parquet. Arquivos pequenos demais aumentam a sobrecarga de arquivos e metadados, enquanto poucos arquivos grandes podem limitar o paralelismo de varredura.

Para tabelas escritas pelo Spark, use as configurações padrão no tempo de execução do Fabric Spark 2.0 ou posterior. Esses ambientes de execução habilitam por padrão o tamanho adaptativo do arquivo de destino para selecionar, por tabela, o tamanho de arquivo de destino ideal, variando de 128 MB para tabelas menores a 1 GB para as tabelas maiores. Evite definir alvos estáticos ou limite arbitrário de contagem de linhas em cima das configurações padrão. Um limite de linha não leva em conta a largura da linha e pode criar arquivos pequenos para tabelas estreitas.

Se você estiver usando o runtime do Fabric Spark 1.3, habilite o tamanho de arquivo de destino adaptável e os alvos de compactação no nível do arquivo, que estão disponíveis como recursos opcionais.

O V-Order beneficia principalmente o Power BI Direct Lake e, embora possa melhorar a compressão para algumas cargas de trabalho, geralmente não é exigido ou recomendado por padrão para o desempenho ideal de endpoints de análise SQL.

As configurações padrão de escrita não substituem a manutenção da tabela. Use as práticas a seguir para preservar um layout adequado à medida que as tabelas mudam:

Ative a compactação automática para cargas de trabalho onde a latência periódica adicionada de escrita síncrona é aceitável. Compactação automática é um recurso do Spark que só roda quando há muitos arquivos pequenos em uma tabela.
Programe trabalhos periódicos OPTIMIZE para cargas de trabalho onde a latência periódica adicionada pela compactação automática não atende aos SLA de atualização de dados.
Execute VACUUM de acordo com seus requisitos de retenção e viagem no tempo para remover arquivos que o log Delta não menciona mais. VACUUM Reduz o armazenamento retido, mas não melhora o layout ativo dos arquivos.
Evite particionamento de alta cardinalidade e configurações personalizadas de escritor que geram muitos arquivos pequenos.

Se você não usar a compactação automática, para identificar as tabelas que precisam de manutenção, use um pipeline de dados e o procedimento armazenado T-SQL sys.sp_get_table_health_metrics antes de executar OPTIMIZE. Para obter um tutorial, consulte Otimizar tabelas do Lakehouse com base em verificações de integridade.

Note

Para obter orientações sobre a manutenção geral das tabelas do lakehouse, consulte Executar a manutenção de tabela no Lakehouse.

Considerações sobre o tamanho das partições

O layout das partições afeta quanto tempo o endpoint de análise SQL leva para descobrir e sincronizar alterações. Um grande número de partições ou de pequenos arquivos Parquet aumenta a sobrecarga da verificação de metadados. Siga estas práticas:

Evite colunas de partição de alta cardinalidade, que podem criar uma partição para cada valor único. Escolha uma coluna que produza partições próximas ou maiores que 1 GB. Para mais informações, veja particionamento de tabelas Delta Lake.
A ingestão em lote e em fluxo pode criar arquivos pequenos quando as alterações são frequentes ou de pequena escala. Use a manutenção regular de tabelas do lakehouse para compactar esses arquivos.

Para avaliar o tamanho e a contagem de arquivos de cada partição, use o script de exemplo para detalhes da partição.

Amostra de script para obter detalhes da partição

Use o caderno a seguir para imprimir um relatório detalhando o tamanho e os detalhes das partições que sustentam uma tabela Delta.

Primeiro, forneça o caminho ABFSS para sua tabela Delta na variável delta_table_path.
- Você pode obter o caminho ABFSS de uma tabela delta no Explorer do portal do Fabric. Clique com o botão direito do mouse no nome da tabela e selecione COPY PATH na lista de opções.
O script gera todas as partições da tabela Delta.
O script itera através de cada partição para calcular o tamanho total e o número de arquivos.
O script gera os detalhes de partições, arquivos por partições e tamanho por partição em GB.

Você pode copiar o script completo do seguinte bloco de código:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Comentários

Esta página foi útil?

Last updated on 2026-09-16