Prestatieoverwegingen voor SQL Analytics-eindpunten

Met het SQL-analyse-eindpunt kunt u query's uitvoeren op gegevens in lakehouse met behulp van het T-SQL-taal- en TDS-protocol.

Tip

Zie Onderhoud en optimalisatie van meerdere workloads voor uitgebreide richtlijnen voor het optimaliseren van Delta-tabellen voor het verbruik van SQL-analyse-eindpunten, inclusief aanbevelingen voor bestandsgrootte en rijgroepen.

Elk lakehouse heeft één SQL-analyse-eindpunt. Het aantal SQL-analyse-eindpunten in een werkruimte komt overeen met het aantal lakehouses en gespiegelde databases die zijn ingericht in die ene werkruimte.

Een achtergrondproces is verantwoordelijk voor het scannen van het lakehouse op wijzigingen en voor het up-to-date houden van het SQL-analyse-eindpunt met alle wijzigingen die zijn doorgevoerd in lakehouses binnen een werkruimte. Het Microsoft Fabric platform beheert het synchronisatieproces transparant. Wanneer een wijziging wordt gedetecteerd in een lakehouse, werkt een achtergrondproces de metagegevens bij en geeft het SQL-analyse-eindpunt de wijzigingen door die zijn doorgevoerd in de lakehouse-tabellen weer. Onder normale operationele omstandigheden is de vertraging tussen een lakehouse- en SQL-analyse-eindpunt minder dan één minuut. De werkelijke tijdsduur kan variëren van een paar seconden tot minuten, afhankelijk van veel factoren die in dit artikel worden besproken. Het achtergrondproces wordt alleen uitgevoerd wanneer het SQL Analytics-eindpunt actief is en stopt na 15 minuten inactiviteit.

Begeleiding

Automatische metagegevensdetectie houdt wijzigingen bij die zijn doorgevoerd in Lakehouses en is één exemplaar per Fabric-werkruimte. Als u een verhoogde latentie ziet voor wijzigingen in synchronisatie tussen Lakehouses en het SQL Analytics-eindpunt, kan dit worden veroorzaakt door een groot aantal lakehouses in één werkruimte. In zo’n scenario kunt u overwegen om elk lakehouse naar een aparte werkruimte te migreren, omdat deze aanpak ervoor zorgt dat automatische detectie van metagegevens kan worden opgeschaald.
Parquet-bestanden zijn standaard onveranderbaar. Wanneer er een update- of verwijderbewerking is, voegt een Delta-tabel nieuwe Parquet-bestanden toe met de wijzigingenset, waardoor het aantal bestanden in de loop van de tijd toeneemt, afhankelijk van de frequentie van updates en verwijderingen. Als u geen onderhoud plant, leidt dit patroon uiteindelijk tot extra leesoverhead. Deze situatie heeft invloed op de tijd die nodig is om wijzigingen naar het SQL-analyse-eindpunt te synchroniseren. Om dit probleem aan te pakken, plant u regelmatig onderhoudsbewerkingen voor lakehouse-tabellen.
In sommige scenario's ziet u mogelijk dat wijzigingen die zijn doorgevoerd in een lakehouse, niet zichtbaar zijn in het bijbehorende SQL-analyse-eindpunt. U kunt bijvoorbeeld een nieuwe tabel maken in Lakehouse, maar deze wordt nog niet vermeld in het SQL-analyse-eindpunt. U kunt ook een groot aantal rijen doorvoeren in een tabel in een lakehouse, maar deze gegevens zijn nog niet zichtbaar in het SQL-analyse-eindpunt. U kunt de synchronisatie van metagegevens op aanvraag starten.
Het automatische synchronisatieproces biedt geen ondersteuning voor alle Delta-functies. Zie de interoperabiliteit van delta lake-tabelindelingen voor meer informatie over de functionaliteit die door elke engine in Fabric wordt ondersteund.
Als er een extreem groot aantal tabelwijzigingen is tijdens de ETL-verwerking (Extract Transform and Load), treedt een verwachte vertraging op totdat alle wijzigingen worden verwerkt.

Lakehouse-tabellen optimaliseren voor het uitvoeren van query's op het SQL Analytics-eindpunt

Wanneer het SQL Analytics-eindpunt tabellen leest die zijn opgeslagen in een lakehouse, zijn queryprestaties sterk afhankelijk van de fysieke indeling van de onderliggende Parquet-bestanden.

Een groot aantal kleine Parquet-bestanden zorgt voor overhead en heeft negatieve invloed op de queryprestaties. Om voorspelbare en efficiënte prestaties te garanderen, onderhoudt u tabelopslag zodat elk Parquet-bestand twee miljoen rijen bevat. Dit aantal rijen biedt een evenwichtig parallelle uitvoering zonder de gegevensset te fragmenteren in overmatig kleine segmenten.

Naast richtlijnen voor het tellen van rijen is de bestandsgrootte even belangrijk. Het SQL-analyse-eindpunt presteert het beste wanneer Parquet-bestanden groot genoeg zijn om de overhead voor het verwerken van bestanden te minimaliseren, maar niet zo groot dat parallelle scanefficiëntie wordt beperkt. Voor de meeste werkbelastingen zorgt het houden van afzonderlijke Parquet-bestanden dicht bij 400 MB voor de beste balans. Gebruik de volgende stappen om dit evenwicht te bereiken:

Ingesteld maxRecordsPerFile op 2.000.000 voordat gegevenswijzigingen plaatsvinden.
Uw gegevenswijzigingen uitvoeren (gegevensopname, updates, verwijderingen).
Ingesteld maxFileSize op 4 GB.
Voer OPTIMIZEuit. Zie OPTIMIZE voor meer informatie over het gebruik.

Het volgende script bevat een sjabloon voor deze stappen en moet worden uitgevoerd op een 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 (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

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

Als u de bestandsgrootte in orde wilt houden, voert u periodiek Delta-optimalisatiebewerkingen uit, zoals OPTIMIZE, met name voor tabellen die regelmatig incrementele invoegingen, updates en verwijderingen ontvangen. Deze onderhoudsbewerkingen comprimeren kleine bestanden in de juiste grootte, waardoor het SQL Analytics-eindpunt query's efficiënt kan verwerken.

Note

Zie Tabelonderhoud uitvoeren vanuit Lakehouse voor hulp bij algemeen onderhoud van Lakehouse-tabellen.

Overwegingen voor partitiegrootte

De keuze van de partitiekolom voor een deltatabel in een Lakehouse is ook van invloed op de tijd die nodig is om wijzigingen in het SQL Analytics-eindpunt te synchroniseren. Het aantal en de grootte van partities van de partitiekolom zijn belangrijk voor prestaties:

Een kolom met een hoge kardinaliteit (meestal of volledig gemaakt van unieke waarden) resulteert in een groot aantal partities. Een groot aantal partities heeft een negatieve invloed op de prestaties van de scan voor metagegevensdetectie op wijzigingen. Als de kardinaliteit van een kolom hoog is, kiest u een andere kolom voor partitionering.
De grootte van elke partitie kan ook van invloed zijn op de prestaties. Gebruik een kolom die resulteert in een partitie van ten minste (of dicht bij) 1 GB. Volg de aanbevolen procedures voor onderhoud en optimalisatie van deltatabellen. Zie Sample-script voor partitiedetails voor een Python script voor het evalueren van partities.

Een groot aantal kleine Parquet-bestanden verhoogt de tijd die nodig is om wijzigingen tussen een lakehouse en het bijbehorende SQL-analyse-eindpunt te synchroniseren. Je kunt om een of meer redenen een groot aantal parquet-bestanden in een delta-tabel tegenkomen:

Als u een partitie kiest voor een Delta-tabel met een groot aantal unieke waarden, wordt de tabel gepartitioneerd door elke unieke waarde en is deze mogelijk te veel gepartitioneerd. Kies een partitiekolom die geen hoge kardinaliteit heeft, en dat resulteert in afzonderlijke partities die ten minste 1 GB groot zijn.
Batch- en streamingdataopnamesnelheden kunnen leiden tot de creatie van kleine bestanden, afhankelijk van de frequentie en grootte van wijzigingen die naar een lakehouse worden geschreven. Er kan bijvoorbeeld een klein aantal wijzigingen naar het lakehouse worden gestuurd, wat resulteert in kleine parquet-bestanden. Om dit probleem op te lossen, voert u regelmatig onderhoud van lakehouse-tabellen uit.

Voorbeeldscript voor partitiedetails

Gebruik het volgende notebook om een rapport af te drukken dat de grootte en details van de partities beschrijft die deel uitmaken van een deltatabel.

Geef eerst het ABFSS-pad op voor uw deltatabel in de variabele delta_table_path.
- U kunt het ABFSS-pad van een deltatabel ophalen vanuit de Fabric portal Explorer. Klik met de rechtermuisknop op de tabelnaam en selecteer vervolgens COPY PATH in de lijst met opties.
Het script voert alle partities voor de deltatabel uit.
Het script doorloopt elke partitie om de totale grootte en het aantal bestanden te berekenen.
Het script voert de details uit van partities, bestanden per partitie en grootte per partitie in GB.

U kunt het volledige script kopiëren vanuit het volgende codeblok:

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

Automatisch gegenereerd schema in het SQL Analytics-eindpunt van Lakehouse

Voor elke Delta-tabel in uw Lakehouse genereert het SQL Analytics-eindpunt automatisch een tabel in het juiste schema. De eindpuntengine van SQL Analytics is gebaseerd op de Fabric Data Warehouse-engine.

Zie de synchronisatie van metagegevens van SQL Analytics-eindpunten voor meer informatie. U kunt ook programmatisch een vernieuwing van het automatisch scannen van metagegevens afdwingen met behulp van de REST API voor metagegevens van SQL-eindpunt vernieuwen.

Feedback

Is deze pagina nuttig?

Last updated on 2026-05-26