Delen via

Prestatieoverwegingen voor SQL Analytics-eindpunten

  • Artikel

Van toepassing op:✅ SQL Analytics-eindpunt in Microsoft Fabric

Met het SQL Analytics-eindpunt kunt u query's uitvoeren op gegevens in het lakehouse met behulp van 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 Lakehouse op wijzigingen en het up-to-date houden van het SQL Analytics-eindpunt voor alle wijzigingen die zijn doorgevoerd in Lakehouses in een werkruimte. Het synchronisatieproces wordt transparant beheerd door het Microsoft Fabric-platform. Wanneer een wijziging wordt gedetecteerd in een lakehouse, worden metagegevens van een achtergrondproces bijgewerkt en het SQL-analyse-eindpunt de wijzigingen die zijn doorgevoerd in lakehouse-tabellen. 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 een aantal factoren die in dit artikel worden weergegeven.

Automatisch gegenereerd schema in het SQL Analytics-eindpunt van Lakehouse

Het SQL Analytics-eindpunt beheert de automatisch gegenereerde tabellen, zodat de werkruimtegebruikers ze niet kunnen wijzigen. Gebruikers kunnen het databasemodel verrijken door hun eigen SQL-schema's, weergaven, procedures en andere databaseobjecten toe te voegen.

Voor elke Delta-tabel in uw Lakehouse genereert het SQL Analytics-eindpunt automatisch een tabel in het juiste schema. Zie Gegevenstypen in Microsoft Fabric voor automatisch gegenereerde schemagegevenstypen voor het SQL-analyse-eindpunt.

Tabellen in het SQL-analyse-eindpunt worden met een kleine vertraging gemaakt. Zodra u een Delta Lake-tabel in het lake hebt gemaakt of bijgewerkt, wordt de SQL Analytics-eindpunttabel die verwijst naar de Delta Lake-tabel automatisch gemaakt/vernieuwd.

De hoeveelheid tijd die nodig is om de tabel te vernieuwen, is gerelateerd aan hoe geoptimaliseerd de Delta-tabellen zijn. Raadpleeg de optimalisatie van Delta Lake-tabellen en V-Order voor meer informatie over belangrijke scenario's en een uitgebreide handleiding over het efficiënt onderhouden van Delta-tabellen voor maximale prestaties.

U kunt handmatig een vernieuwing van het automatisch scannen van metagegevens afdwingen in de Fabric-portal. Selecteer op de pagina voor het SQL Analytics-eindpunt de knop Vernieuwen in de werkbalk Explorer om het schema te vernieuwen. Ga naar Uw SQL Analytics-eindpunt opvragen en zoek de knop Vernieuwen, zoals wordt weergegeven in de volgende afbeelding.

Schermopname van de Fabric-portal met de knop Schema vernieuwen van SQL Analytics-eindpunt.

Richtlijn

  • 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 sql Analytics-eindpunt, kan dit worden veroorzaakt door een groot aantal lakehouses in één werkruimte. In een dergelijk scenario kunt u overwegen om elk lakehouse naar een afzonderlijke werkruimte te migreren, omdat hierdoor automatische detectie van metagegevens kan worden geschaald.
  • 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 wordt verhoogd, afhankelijk van de frequentie van updates en verwijderingen. Als er geen onderhoud gepland is, resulteert dit patroon in een leesoverhead en heeft dit invloed op de tijd die nodig is om wijzigingen in het SQL-analyse-eindpunt te synchroniseren. Om dit te verhelpen, plant u normale 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 hebt bijvoorbeeld een nieuwe tabel in Lakehouse gemaakt, maar deze wordt niet vermeld in het SQL-analyse-eindpunt. Of misschien hebt u een groot aantal rijen doorgevoerd in een tabel in een lakehouse, maar deze gegevens zijn niet zichtbaar in het SQL-analyse-eindpunt. We raden u aan om een synchronisatie van metagegevens op aanvraag te starten, geactiveerd vanuit de optie Vernieuwen van het lint van de SQL-queryeditor. Deze optie dwingt een synchronisatie van metagegevens op aanvraag af in plaats van te wachten op de synchronisatie van metagegevens op de achtergrond.
  • Niet alle Delta-functies worden begrepen door het automatische synchronisatieproces. Zie Delta Lake Interoperability voor meer informatie over de functionaliteit die door elke engine in Fabric wordt ondersteund.
  • Als er een extreem grote hoeveelheid tabellen verandert tijdens de ETL-verwerking (Extract Transform and Load), kan een verwachte vertraging optreden totdat alle wijzigingen worden verwerkt.

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. We raden u aan een kolom te gebruiken die zou resulteren in een partitie van ten minste (of dicht bij) 1 GB. We raden u aan best practices te volgen voor onderhoud van deltatabellen; optimalisatie. Zie Voorbeeldscript 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. U kunt om een of meer redenen een groot aantal Parquet-bestanden in een Delta-tabel tegenkomen:

  • Als u een partitie kiest voor een deltatabel met een groot aantal unieke waarden, wordt deze gepartitioneerd door elke unieke waarde en is deze mogelijk te veel gepartitioneerd. Kies een partitiekolom die geen hoge kardinaliteit heeft en resulteert in een afzonderlijke partitiegrootte van ten minste 1 GB.
  • Batch- en streaminggegevensopnamesnelheden kunnen er ook toe leiden dat kleine bestanden worden gemaakt, afhankelijk van de frequentie en grootte van wijzigingen die naar een lakehouse worden geschreven. Er kunnen bijvoorbeeld kleine hoeveelheden wijzigingen zijn die naar het lakehouse komen en dit zou leiden tot kleine parquet-bestanden. Om dit te verhelpen, raden we u aan regelmatig lakehouse-tabelonderhoud te implementeren.

Voorbeeldscript voor partitiedetails

Gebruik het volgende notebook om een rapportdetailgrootte en details van partities af te drukken die ten grondslag liggen aan een deltatabel.

  1. Eerst moet u het ABSFF-pad voor uw deltatabel opgeven in de variabele delta_table_path.
    • U kunt het ABFSS-pad van een deltatabel ophalen vanuit de Fabric-portalverkenner. Klik met de rechtermuisknop op de tabelnaam en selecteer vervolgens COPY PATH in de lijst met opties.
  2. Het script voert alle partities voor de deltatabel 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.

Het volledige script kan worden gekopieerd uit 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']}")

Gerelateerde inhoud