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.

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 Microsoft 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 só corre quando o endpoint de análise SQL está ativo e para após 15 minutos de inatividade.

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. Tens a opção de iniciar a sincronização de metadados a pedido.
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.

Um grande número de pequenos ficheiros Parquet cria sobrecarga e afeta negativamente o desempenho das consultas. Para garantir um desempenho previsível e eficiente, mantenha o armazenamento de tabelas para 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 Parquet são suficientemente grandes para minimizar a sobrecarga de gestão de ficheiros, mas não tão grande que limite a eficiência da varredura paralela. Para a maioria das cargas de trabalho, manter ficheiros Parquet individuais perto de 400 MB é o melhor equilíbrio. Para alcançar este equilíbrio, utilize os seguintes passos:

Definido 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 4 GB.
Execute OPTIMIZE. Para obter detalhes sobre como utilizar OPTIMIZE, consulte Executar a manutenção de tabelas a partir do Lakehouse.

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 (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

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

Para manter tamanhos de ficheiros saudáveis, execute periodicamente operações de otimização Delta como OPTIMIZE, especialmente para tabelas que recebem inserções, atualizações e eliminações incrementais 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.

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

A escolha da coluna de partição para uma tabela delta em uma arquitetura lakehouse também afeta o tempo necessário para sincronizar alterações no endpoint 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. Use uma coluna que resulte numa partição de pelo menos (ou perto de) 1 GB. Siga as melhores práticas para manutenção e otimização de tabelas delta. Para um script Python para avaliar partições, veja Sample script para detalhes das partições.

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. Pode acabar por ter um grande número de arquivos de parquet numa tabela delta por um ou mais motivos:

Se escolher uma partição para uma tabela Delta com um elevado número de valores únicos, a tabela é particionada por cada valor único e pode estar sobreparticionada. 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 em streaming também podem resultar em pequenos ficheiros, dependendo da frequência e do tamanho das alterações que são gravadas num armazém de dados lakehouse. Por exemplo, pode haver um pequeno volume de alterações a chegar ao lakehouse, resultando em pequenos ficheiros de parquet. Para resolver este problema, implemente a manutenção regular das tabelas do lakehouse.

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, 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 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.

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

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

Para cada tabela Delta na sua Lakehouse, o endpoint de análise SQL gera automaticamente uma tabela no esquema apropriado. O motor endpoint de análise SQL baseia-se no motor Fabric Data Warehouse.

Para mais informações, consulte a sincronização de metadados dos endpoints de análise SQL. Também pode forçar programaticamente uma atualização da análise automática de metadados usando a API REST de metadados do endpoint Refresh SQL.

Comentários

Esta página foi útil?

Last updated on 2026-05-26