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

Aplica-se a:✅ Ponto de extremidade de análise SQL no Microsoft Fabric

O ponto de extremidade de análise SQL permite que você consulte dados no lakehouse usando a linguagem T-SQL e o protocolo TDS.

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 espaço de trabalho.

Um processo em segundo plano é responsável por verificar se há alterações no lakehouse e manter o endpoint de análise SQL atualizado para todas as alterações confirmadas no lakehouse em um espaço de trabalho. O processo de sincronização é gerenciado de forma transparente pela plataforma Microsoft Fabric. Quando uma alteração é detetada em uma lakehouse, um processo em segundo plano atualiza os metadados e o ponto de extremidade de análise SQL reflete as alterações comprometidas nas tabelas lakehouse. Em condições normais de operação, o atraso entre um lakehouse e um ponto de extremidade de análise SQL é inferior a um minuto. A duração real do tempo pode variar de alguns segundos a minutos, dependendo de muitos fatores discutidos neste artigo. O processo em segundo plano só corre quando o endpoint de análise SQL está ativo e é interrompido após 15 minutos de inatividade.

Esquema gerado automaticamente no ponto de extremidade de análise SQL do Lakehouse

O ponto de extremidade da análise SQL gerencia as tabelas geradas automaticamente para que os usuários do espaço de trabalho não possam modificá-las. Os usuários podem enriquecer o modelo de banco de dados adicionando seus próprios esquemas SQL, exibições, procedimentos e outros objetos de banco de dados.

Para cada tabela Delta em seu Lakehouse, o ponto de extremidade de análise SQL gera automaticamente uma tabela no esquema apropriado. Para tipos de dados de esquema gerados automaticamente para o ponto de extremidade de análise SQL, consulte Tipos de dados no Microsoft Fabric.

As tabelas no ponto de extremidade de análise SQL são criadas com um pequeno atraso. Depois de criar ou atualizar a tabela Delta Lake no lago, a tabela endpoint de análise SQL que faz referência à tabela Delta Lake é criada/atualizada automaticamente.

A quantidade de tempo que leva para atualizar a tabela está relacionada ao quão otimizadas as tabelas Delta são. Para obter mais informações, consulte a otimização da tabela Delta Lake e o V-Order para saber mais sobre os principais cenários e um guia detalhado sobre como manter eficientemente as tabelas Delta para obter o máximo desempenho.

Você pode forçar manualmente uma atualização da verificação automática de metadados no portal da malha. Na página do ponto de extremidade da análise SQL, selecione o botão Atualizar na barra de ferramentas do Explorer para atualizar o esquema. Vá para Consultar seu ponto de extremidade de análise SQL e procure o botão de atualização, conforme mostrado na imagem a seguir.

Você pode também forçar programaticamente uma atualização da análise automática de metadados usando a API REST de Refresh SQL para metadados de ponto de extremidade.

Orientação

A descoberta automática de metadados rastreia as alterações confirmadas em lakehouses e é uma única instância por espaço de trabalho de malha. Se está a observar um aumento da latência na sincronização das alterações entre os lakehouses e o endpoint de análise SQL, isso pode dever-se ao grande número de lakehouses num só espaço de trabalho. Nesse cenário, considere migrar cada lakehouse para um espaço de trabalho separado, pois isso permite que a descoberta automática de metadados seja dimensionada.
Os arquivos Parquet são imutáveis por design. Quando há uma operação de atualização ou exclusão, uma tabela Delta adicionará novos arquivos parquet com o conjunto de alterações, aumentando o número de arquivos ao longo do tempo, dependendo da frequência de atualizações e exclusões. Se não houver manutenção agendada, eventualmente, esse padrão criará uma sobrecarga de leitura e isso afetará o tempo necessário para sincronizar as alterações no ponto de extremidade da análise SQL. Para resolver isso, agende operações regulares de manutenção da mesa do lago.
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, você pode ter criado uma nova tabela no lakehouse, mas ela ainda não está listada no ponto de extremidade da análise SQL. Ou, pode ter inserido um grande número de linhas numa tabela num lakehouse, mas esses dados ainda não estão visíveis no endpoint de análise SQL. Recomendamos iniciar uma sincronização de metadados a pedido, acionada a partir da opção Atualizar no editor de consultas SQL ou pela API REST de metadados do ponto de extremidade SQL para Atualizar. Essa opção força uma sincronização de metadados sob demanda, em vez de aguardar a conclusão da sincronização de metadados em segundo plano.
Nem todos os recursos Delta são compreendidos pelo processo de sincronização automática. 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), um atraso é esperado 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 é fortemente influenciado pela disposição física dos ficheiros de parquet subjacentes.

Um grande número de pequenos ficheiros de Parquet cria sobrecarga de processamento e afeta negativamente o desempenho das consultas. Para garantir um desempenho previsível e eficiente, recomendamos manter o armazenamento das tabelas de modo a que cada ficheiro Parquet contenha dois milhões de linhas. Esta contagem de linhas proporciona um nível equilibrado de paralelismo sem fragmentar o conjunto de dados em fatias excessivamente pequenas.

Para além da orientação para a contagem de linhas, o tamanho do ficheiro é igualmente importante. O endpoint de análise SQL tem melhor desempenho quando os ficheiros de parquet são suficientemente grandes para minimizar a sobrecarga de manuseamento de ficheiros, mas não tão grandes que limitem a eficiência da varredura paralela. Para a maioria das cargas de trabalho, manter ficheiros de parquet individuais perto de 400 MB é o melhor equilíbrio. Para alcançar este equilíbrio, utilize os seguintes passos:

Definir maxRecordsPerFile para 2.000.000 antes de ocorrerem alterações nos dados.
Realize as alterações dos seus dados (ingestão de dados, atualizações, eliminações).
Defina maxFileSize para 400 MB.
Execute OPTIMIZE. Para detalhes sobre a utilização de OPTIMIZE, consulte as operações de manutenção da tabela.

O script seguinte fornece um modelo para estes passos e deve ser executado numa casa de lago:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Para manter tamanhos de ficheiros saudáveis, os utilizadores devem executar periodicamente operações de otimização Delta, como OPTIMIZE, especialmente para tabelas que recebem escritas incrementais, atualizações e eliminações frequentes. Estas operações de manutenção compactam ficheiros pequenos em ficheiros de tamanho adequado, ajudando a garantir que o endpoint de análise SQL possa processar consultas de forma eficiente.

Observação

Para orientações sobre a manutenção geral de tabelas no Lakehouse, consulte Executar manutenção ad-hoc numa tabela Delta utilizando o Lakehouse.

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

A escolha da coluna de partição para uma tabela delta em uma casa de lago também afeta o tempo necessário para sincronizar alterações no ponto de extremidade de análise SQL. O número e o tamanho das partições da coluna de partição são importantes para o desempenho:

Uma coluna com alta cardinalidade (maioritariamente ou inteiramente feita de valores únicos) resulta num grande número de partições. Um grande número de partições afeta negativamente o desempenho da verificação de descoberta de metadados em busca de alterações. Se a cardinalidade de uma coluna for alta, escolha outra coluna para particionamento.
O tamanho de cada partição também pode afetar o desempenho. Nossa recomendação é usar uma coluna que resultaria em uma partição de pelo menos (ou perto de) 1 GB. Recomendamos seguir as melhores práticas para manutenção de tabelas delta; otimização. Para um script python para avaliar partições, consulte Script de exemplo para obter detalhes de partição.

Um grande volume de arquivos de parquet de pequeno porte aumenta o tempo necessário para sincronizar alterações entre um lakehouse e seu endpoint de análise SQL associado. Você pode acabar com um grande número de arquivos de parquet em uma tabela delta por um ou mais motivos:

Se você escolher uma partição para uma tabela delta com alto número de valores exclusivos, ela será particionada por cada valor exclusivo e poderá estar superparticionada. Escolha uma coluna de partição que não tenha uma cardinalidade alta e resulte em partições individuais de pelo menos 1 GB cada.
As taxas de ingestão de dados em lote e streaming também podem resultar em pequenos arquivos, dependendo da frequência e do tamanho das alterações que estão sendo gravadas em uma casa de lago. Por exemplo, pode haver um pequeno volume de alterações a chegar ao lakehouse, resultando em pequenos ficheiros de parquet. Para resolver isso, recomendamos a implementação da manutenção regular da mesa do lago.

Script de exemplo para detalhes da partição

Use o bloco de anotações a seguir para imprimir um relatório detalhando o tamanho e os detalhes das partições subjacentes a uma tabela delta.

Primeiro, você deve fornecer o caminho ABSFF para sua tabela delta na variável delta_table_path.
- Você pode obter o caminho ABFSS de uma tabela delta no Fabric portal 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 produz todas as partições para a 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.

O script completo pode ser copiado 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']}")

Feedback

Esta página foi útil?

Last updated on 2026-01-27