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.

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 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. De engine paralleliseert scans op Parquet-bestandsniveau. Te veel kleine bestanden verhogen de overhead van bestanden en metadata, terwijl te weinig grote bestanden de scanparalleliteit kunnen beperken.

Voor tabellen geschreven door Spark gebruik je de standaardinstellingen in Fabric Spark runtime 2.0 of later. Deze runtimes maken standaard adaptieve doelbestandsgrootte mogelijk om de meest optimale doelbestandsgrootte per tabel te selecteren, van 128 MB voor kleinere tabellen tot 1 GB voor de grootste tabellen. Vermijd het instellen van statische doelen of willekeurige limieten op rijen bovenop de standaardconfiguraties. Een rijlimiet houdt geen rekening met de rijbreedte en kan resulteren in kleine bestanden voor smalle tabellen.

Als je Fabric Spark runtime 1.3 gebruikt, schakel dan adaptieve doelwitbestandsgrootte en bestandsniveau-compactiedoelen in, die beschikbaar zijn als opt-in functies.

Je hebt geen V-Order nodig voor verbeterde prestaties van SQL-analyse-endpoints, want Spark schrijft parquetbestanden die Snappy-gecomprimeerd zijn om zowel lees- als schrijf-I/O te verminderen.

Standaard schrijfinstellingen vervangen het onderhoud van de tabel niet. Gebruik de volgende werkwijzen om een gezonde lay-out te behouden terwijl tabellen veranderen:

• Schakel automatische verdichting in voor workloads waarbij de periodieke toegevoegde synchrone schrijflatentie acceptabel is. Automatische verdichting is een Spark-functie die alleen draait als er te veel kleine bestanden in een tabel staan.
• Plan periodieke OPTIMIZE taken voor workloads waarbij de periodiek toegevoegde latentie door automatische compactie niet voldoet aan de SLA's voor gegevensupdates.
• Voer VACUUM uit volgens je retentie- en tijdreisvereisten om bestanden te verwijderen waar het Delta-log niet meer naar verwijst. VACUUM Vermindert de opgeslagen opslag, maar verbetert de indeling van het actieve bestand niet.
• Vermijd partitionering met hoge kardinaliteit en aangepaste schrijversconfiguraties die veel kleine bestanden creëren.

Als je geen automatische verdichting gebruikt, gebruik dan een datapipeline en de sys.sp_get_table_health_metrics T-SQL stored procedure voordat je het uitvoert OPTIMIZE, om tabellen te identificeren die onderhoud nodig hebben. Raadpleeg voor een handleiding Lakehouse-tabellen optimaliseren op basis van statuscontroles.

Overwegingen voor partitiegrootte

De keuze van partitiekolom voor een Delta-tabel in een lakehouse beïnvloedt ook de tijd die nodig is om wijzigingen te synchroniseren naar het SQL-analyse-endpoint. 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 beste praktijken voor het onderhoud en partitioneren van Delta-tabellen. 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 eindigen met een groot aantal Parquet-bestanden in een Delta-tabel om een of meer redenen:

• 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 notitieboek om een rapport af te drukken met details over de grootte en details van partities die een Delta-tabel ondersteunen.

1. Geef eerst het ABFSS-pad voor je Delta-tabel 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.
2. Het script geeft alle partities voor de Delta-tabel uit.
3. Het script doorloopt elke partitie om de totale grootte en het aantal bestanden te berekenen.
4. 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.

Verwante inhoud

• Onderhoud en optimalisatie van tabellen tussen werkbelastingen
• Delta Lake-tabeloptimalisatie en V-orde
• Tabelcompressie
• Bestandsgrootte afstemmen
• Toepassingen van Lakehouse SQL-analyse-eindpunten