Considerações sobre o desempenho do endpoint de SQL Analytics

O endpoint de análise SQL permite-lhe consultar dados no lakehouse utilizando a linguagem T-SQL e o protocolo TDS. Aproveita o motor Fabric Data Warehouse.

Tip

Para orientações abrangentes entre cargas de trabalho sobre a otimização de tabelas Delta para o consumo de endpoints de análise SQL, incluindo recomendações de tamanho de ficheiro e grupos de linhas, consulte Manutenção e otimização de tabelas de carga cruzada.

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

Um processo em segundo plano é responsável por examinar o lakehouse para detetar alterações e manter o endpoint de análise SQL atualizado com todas as alterações efetuadas aos lakehouses num espaço de trabalho. A plataforma Fabric gere de forma transparente o processo de sincronização. Quando uma alteração é detetada numa lakehouse, um processo em segundo plano atualiza os metadados e o ponto de extremidade de análise SQL reflete as alterações confirmadas nas tabelas da lakehouse. Em condições normais de operação, o atraso entre um lakehouse e um endpoint de análise SQL é inferior a um minuto. A duração real do tempo pode variar de alguns segundos a minutos, dependendo de vários fatores que este artigo aborda. O processo em segundo plano corre enquanto o endpoint de análise SQL está ativo e para após 15 minutos sem atividade de consulta.

Orientações

A descoberta automática de metadados regista as alterações efetuadas em data lakehouses e tem uma única instância em cada espaço de trabalho do Fabric. Se observar um aumento da latência na sincronização das alterações entre os lakehouses e o ponto final de análise SQL, isso pode dever-se a um grande número de lakehouses num único espaço de trabalho. Neste cenário, considere migrar cada lakehouse para um workspace separado, pois esta abordagem permite escalar a deteção automática de metadados.
Os arquivos Parquet são imutáveis por design. Quando há uma atualização ou operação de eliminação, uma tabela Delta adiciona novos ficheiros Parquet ao conjunto de alterações, o que aumenta o número de ficheiros ao longo do tempo, dependendo da frequência das atualizações e eliminações. Se não agendares manutenção, este padrão acaba por criar uma sobrecarga de leitura e esta condição afeta o tempo que demora a sincronizar as alterações para o endpoint de análise SQL. Para resolver este problema, programe operações regulares de manutenção de tabelas do lakehouse.
Em alguns cenários, 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, podes criar uma nova tabela no Lakehouse, mas ainda não está listada no endpoint de análise SQL. Ou podes confirmar um grande número de linhas numa tabela de um lakehouse, mas esses dados ainda não estão visíveis no endpoint de análise SQL. Pode iniciar a sincronização de metadados a pedido no portal Fabric ou utilizar a API REST para atualizar os metadados do ponto final de análise SQL.
O processo de sincronização automática não suporta todas as funcionalidades da Delta. Para obter mais informações sobre a funcionalidade suportada por cada mecanismo no Fabric, consulte a Interoperabilidade do formato de tabela Delta Lake.
Se houver um volume extremamente elevado de alterações nas tabelas durante o processamento de Extração, Transformação e Carga (ETL), é expectável que ocorra um atraso até que todas as alterações sejam processadas.

Otimizar tabelas lakehouse para consultas no endpoint de análises SQL

Quando o endpoint de análise SQL lê tabelas armazenadas num lakehouse, o desempenho das consultas depende fortemente do layout físico dos ficheiros Parquet subjacentes. O motor paraleliza as leituras ao nível dos ficheiros Parquet. Demasiados ficheiros pequenos aumentam a sobrecarga de ficheiros e metadados, enquanto poucos ficheiros grandes podem limitar o paralelismo de varredura.

Para tabelas escritas pelo Spark, use as definições padrão no runtime do Fabric Spark 2.0 ou posterior. Estes tempos de execução permitem por defeito o tamanho adaptativo do ficheiro-alvo para selecionar o tamanho de ficheiro-alvo mais ótimo por tabela, desde 128 MB para tabelas menores até 1 GB para as maiores tabelas. Evite definir alvos estáticos ou um limite arbitrário de contagem de linhas por cima das configurações padrão. Um limite de linhas não tem em conta a largura das linhas e pode criar ficheiros pequenos para tabelas estreitas.

Se estiver a usar o runtime do Fabric Spark 1.3, ative o tamanho de ficheiro alvo adaptativo e os alvos de compactação ao nível do ficheiro, que estão disponíveis como funcionalidades opt-in.

O V-Order é sobretudo benéfico para o Power BI Direct Lake e, embora possa melhorar a compressão em algumas cargas de trabalho, geralmente não é necessário nem recomendado por predefinição para um desempenho ideal do endpoint de análise SQL.

As configurações predefinidas de escrita não substituem a manutenção da tabela. Utilize as seguintes práticas para preservar uma disposição adequada à medida que as tabelas vão mudando:

Ative a compactação automática para cargas de trabalho onde a latência periódica adicionada de escrita síncrona é aceitável. A autocompactação é uma funcionalidade do Spark que só funciona quando há demasiados ficheiros pequenos numa tabela.
Programar tarefas periódicas OPTIMIZE para cargas de trabalho em que a latência periódica adicional da compactação automática não satisfaz os SLAs relativos à atualização de dados.
Execute VACUUM de acordo com os requisitos de retenção e de deslocação temporal para remover ficheiros que o registo Delta já não referencia. VACUUM reduz o armazenamento retido, mas não melhora o layout ativo dos ficheiros.
Evite particionamento de alta cardinalidade e configurações personalizadas de escrita que criam muitos ficheiros pequenos.

Se não usar a compactação automática, para identificar as tabelas que precisam de manutenção, utilize 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 nas verificações de estado.

Note

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

Considerações sobre o tamanho da partição

O layout das partições afeta quanto tempo o endpoint de análise SQL demora a descobrir e sincronizar alterações. Um grande número de partições ou de pequenos ficheiros Parquet aumenta a sobrecarga da análise 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 superiores a 1 GB. Para mais informações, veja Particionamento de tabelas Delta Lake.
A ingestão em lote e em fluxo pode criar ficheiros pequenos quando as alterações são frequentes ou de pequena dimensão. Utilize a manutenção regular das tabelas do lakehouse para compactar estes ficheiros.

Para avaliar o tamanho e o número de ficheiros de cada partição, use o script de exemplo para detalhes das partições.

Script de exemplo para detalhes da partição

Use o seguinte caderno 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 a sua tabela Delta na variável delta_table_path.
- Você pode obter o caminho ABFSS de uma tabela delta no portal Fabric Explorer. Clique com o botão direito do rato no nome da tabela e, em seguida, selecione COPY PATH a partir da 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 produz os detalhes de partições, arquivos por partições e tamanho por partição em GB.

Pode copiar o script completo a partir 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