Considerações de 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 no espaço de trabalho.

Um processo em segundo plano é responsável por verificar se há alterações no lakehouse e por manter o ponto de extremidade de análise SQL atualizado para todas as alterações confirmadas nos lakehouses em um espaço de trabalho. O processo de sincronização é gerenciado de forma transparente pela plataforma Microsoft Fabric. Quando uma alteração é detectada em um 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 do lakehouse. Em condições normais de operação, o atraso entre um lakehouse e o 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 são discutidos neste artigo. O processo em segundo plano é executado somente quando o endpoint de análises SQL está ativo e é suspenso após 15 minutos de inatividade.

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

O ponto de extremidade de análise SQL gerencia as tabelas geradas automaticamente para que os usuários do workspace 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 de 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, confira Tipos de dados no Microsoft Fabric.

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

A quantidade de tempo necessária para atualizar a tabela está relacionada ao nível de otimização das tabelas Delta. Para obter mais informações, revise Otimização de tabela e V-Order do Delta Lake para saber mais sobre os principais cenários e ter um guia detalhado sobre como manter eficientemente tabelas Delta para máximo desempenho.

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

Você também pode forçar programaticamente uma atualização da verificação automática de metadados usando a API REST de atualização de metadados do endpoint SQL.

Diretrizes

A descoberta automática de metadados rastreia as alterações confirmadas nos lakehouses e é uma instância única por espaço de trabalho do Fabric. Se você estiver observando uma latência maior para alterações na sincronização entre os lakehouses e o endpoint de análises SQL, isso pode ocorrer devido a um grande número de lakehouses em um único workspace. Nesse cenário, considere migrar cada lakehouse para outro espaço de trabalho, uma vez que isso permitirá dimensionar a descoberta automática de metadados.
Os arquivos Parquet são imutáveis por design. Quando houver 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, em algum momento, esse padrão criará uma sobrecarga de leitura e isso afetará o tempo necessário para sincronizar as alterações no ponto de extremidade de análise SQL. Para resolver esse problema, agende operações regulares de manutenção de tabelas do 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 ter criado uma nova tabela no lakehouse, mas ela ainda não está listada no endpoint de análise do SQL. Ou talvez você tenha inserido um grande número de linhas em uma tabela em um lakehouse, mas esses dados ainda não estão visíveis no endpoint de análise SQL. Recomendamos iniciar uma sincronização de metadados sob demanda, acionada pela opção Atualizar na faixa de opções do editor de consultas SQL ou pela API REST de atualização de metadados do ponto de extremidade SQL. Essa opção força uma sincronização de metadados sob demanda, em vez de esperar que a sincronização de metadados em segundo plano seja concluída.
Nem todos os recursos Delta são compreendidos pelo processo de sincronização automática. 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 tabelas durante o processamento de ETL (Extração, Transformação e Carga), pode 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 é fortemente influenciado pelo layout físico dos arquivos parquet subjacentes.

Um grande número de pequenos arquivos parquet cria sobrecarga e afeta negativamente o desempenho das consultas. Para garantir um desempenho previsível e eficiente, recomendamos manter o armazenamento de tabelas para que cada arquivo parquet contenha dois milhões de linhas. Essa contagem de linhas fornece um nível equilibrado de paralelismo sem fragmentar o conjunto de dados em fatias excessivamente pequenas.

Além das diretrizes de contagem de linhas, o tamanho do arquivo é igualmente importante. O endpoint de análise SQL tem o melhor desempenho quando os arquivos parquet são suficientemente grandes para minimizar a sobrecarga de tratamento de arquivos, mas não tão grandes a ponto de limitar a eficiência de varredura paralela. Para a maioria das cargas de trabalho, manter arquivos parquet individuais próximos a 400 MB atinge o melhor equilíbrio. Para obter esse equilíbrio, use as seguintes etapas:

Defina maxRecordsPerFile como 2.000.000 antes que ocorram alterações de dados.
Execute suas alterações de dados (ingestão de dados, atualizações, exclusões).
Defina maxFileSize como 400 MB.
Execute OPTIMIZE. Para obter detalhes sobre como usar OPTIMIZE, consulte as operações de manutenção de tabela.

O script a seguir fornece um modelo para estas etapas e deve ser executado em um lakehouse:

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 arquivo saudáveis, os usuários devem executar periodicamente operações de otimização Delta, como OPTIMIZE, especialmente para tabelas que sofrem gravações incrementais frequentes, atualizações e exclusões. Essas operações de manutenção compactam arquivos pequenos em arquivos de tamanho adequado, ajudando a garantir que o ponto de extremidade de análise do SQL possa processar consultas com eficiência.

Observação

Para obter orientação sobre a manutenção geral das tabelas lakehouse, consulte Executar manutenção de tabela ad hoc em uma tabela Delta usando Lakehouse.

Considerações de tamanho da partição

A escolha da coluna de partição para uma tabela delta em um lakehouse também afeta o tempo necessário para sincronizar as 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 (principalmente ou inteiramente composta de valores exclusivos) resulta em um número grande de partições. Um número grande 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 resulte 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 que avalie partições, consulte Amostra de script para obter detalhes da partição.

Um grande volume de arquivos parquet de tamanho pequeno aumenta o tempo necessário para sincronizar as alterações entre um lakehouse e seu ponto de extremidade de análise SQL associado. Você pode acabar com um número grande de arquivos 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á ser particionada em excesso. 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 arquivos pequenos, dependendo da frequência e do tamanho das alterações gravadas em um lakehouse. Por exemplo, pode haver um pequeno volume de alterações chegando até a casa do lago, resultando em pequenos arquivos parquet. Para resolver esse problema, recomendamos implementar a manutenção regular de tabelas do lakehouse.

Amostra de script para obter detalhes da partição

Use o notebook a seguir para imprimir um relatório detalhando o tamanho e os detalhes das partições que sustentam 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 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 para a tabela delta.
O script itera 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.

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']}")

Comentários

Esta página foi útil?

Last updated on 2026-01-27