Überlegungen zur Leistung des SQL-Analyseendpunkts

Gilt für:✅ SQL-Analyseendpunkt in Microsoft Fabric

Über den SQL-Analyseendpunkt können Sie Daten im Lakehouse mithilfe der T-SQL-Sprache und des TDS-Protokolls abfragen.

Tipp

Für umfassende Anleitungen zur Optimierung von Delta-Tabellen über mehrere Workloads hinweg für die Nutzung durch den SQL-Analytics-Endpunkt, einschließlich Empfehlungen zur Dateigröße und Zeilengruppen, siehe Wartung und Optimierung von Tabellen über Workloads hinweg.

Jedes Lakehouse hat einen SQL-Analyseendpunkt. Die Anzahl der SQL-Analyseendpunkte in einem Arbeitsbereich entspricht der Anzahl der Lakehouses und gespiegelten Datenbanken, die in diesem Arbeitsbereich bereitgestellt werden.

Ein Hintergrundprozess ist dafür verantwortlich, das Lakehouse auf Änderungen zu scannen und den SQL-Analyse-Endpunkt für alle in einem Arbeitsbereich an Lakehouses vorgenommenen Änderungen aktuell zu halten. Der Synchronisierungsprozess wird von der Microsoft Fabric-Plattform transparent verwaltet. Wenn eine Änderung in einem Lakehouse erkannt wird, aktualisiert ein Hintergrundprozess die Metadaten, und der SQL-Analyseendpunkt spiegelt die erfolgten Änderungen an den Lakehouse-Tabellen wider. Unter normalen Betriebsbedingungen beträgt die Verzögerung zwischen einem Lakehouse und dem SQL-Analyseendpunkt weniger als eine Minute. Die tatsächliche Zeitdauer kann je nach vielen Faktoren, die in diesem Artikel behandelt werden, von einigen Sekunden bis zu Minuten variieren. Der Hintergrundprozess wird nur ausgeführt, wenn der SQL-Analyseendpunkt aktiv ist und nach 15 Minuten Inaktivität angehalten wird.

Automatisch generiertes Schema im SQL-Analyseendpunkt des Lakehouse

Der SQL-Analyseendpunkt verwaltet die automatisch generierten Tabellen, sodass die Arbeitsbereichsbenutzer*innen sie nicht ändern können. Benutzer*innen können das Datenbankmodell anreichern, indem sie ihre eigenen SQL-Schemas, Ansichten, Prozeduren und andere Datenbankobjekte hinzufügen.

Der SQL-Analyseendpunkt generiert für jede Deltatabelle in Ihrem Lakehouse automatisch eine Tabelle im passenden Schema. Informationen zu automatisch generierten Schemadatentypen für den SQL-Analyseendpunkt finden Sie unter Datentypen in Microsoft Fabric.

Tabellen im SQL-Analyseendpunkt werden leicht verzögert erstellt. Nachdem Sie die Tabelle "Delta Lake" im See erstellt oder aktualisiert haben, wird automatisch die SQL-Analyse-Endpunkttabelle erstellt/aktualisiert, die auf die Tabelle mit dem Delta-See verweist.

Der Zeitaufwand für die Aktualisierung der Tabelle hängt vom Optimierungsgrad der Delta-Tabellen ab. Weitere Informationen finden Sie unter Optimierung und V-Order für Delta Lake-Tabellen, um mehr über die wichtigsten Szenarien zu erfahren. Sie erhalten auch eine ausführliche Anleitung, wie Delta-Tabellen effizient verwaltet werden können, um die maximale Leistung zu erzielen.

Die Aktualisierung der automatischen Metadatenüberprüfung können Sie im Fabric-Portal manuell erzwingen. Wählen Sie auf der Seite für den SQL-Analyseendpunkt die Schaltfläche Aktualisieren in der Explorer-Symbolleiste, um das Schema zu aktualisieren. Gehen Sie zu Abfrage Ihres SQL-Analyseendpunkts, und suchen Sie nach der Schaltfläche "Aktualisieren", wie in der folgenden Abbildung dargestellt.

Sie können auch programmgesteuert eine Aktualisierung der automatischen Metadatenüberprüfung mithilfe der REST-API des Refresh SQL-Endpunkts erzwingen.

Leitfaden

• Die automatische Metadatenerkennung verfolgt Änderungen, die an Lakehouses vorgenommen wurden, und ist eine einzelne Instanz pro Fabric-Arbeitsbereich. Wenn Sie eine erhöhte Latenz bei der Synchronisierung zwischen Lakehouses und dem SQL-Analyseendpunkt beobachten, könnte dies auf eine große Anzahl von Lakehouses in einem einzigen Arbeitsbereich zurückzuführen sein. In einem solchen Szenario sollten Sie die Migration jedes Lakehouses in einen separaten Arbeitsbereich in Erwägung ziehen, da sich die automatische Metadatenermittlung dadurch skalieren lässt.
• Parquet-Dateien sind konstruktionsbedingt unveränderlich. Im Fall eines Aktualisierungs- oder Löschvorgangs fügt eine Delta-Tabelle neue Parquet-Dateien mit dem Changeset hinzu, wodurch die Anzahl der Dateien je nach Häufigkeit der Aktualisierungs- und Löschvorgänge im Laufe der Zeit zunimmt. Ohne regelmäßige Wartung ergibt sich dadurch schließlich einen erhöhter Leseaufwand, der sich auf die Dauer der Synchronisierung von Änderungen mit dem SQL-Analyseendpunkt auswirkt. Um dieses Problem zu beheben, sollten Sie eine regelmäßige Wartung der Lakehouse-Tabelle einplanen.
• In einigen Szenarien stellen Sie möglicherweise fest, dass Änderungen, die an einem Lakehouse übertragen wurden, im zugeordneten SQL-Analyseendpunkt nicht sichtbar sind. Beispielsweise könnten Sie eine neue Tabelle in Lakehouse erstellt haben, aber sie ist noch nicht im SQL-Analyseendpunkt aufgeführt. Oder Sie haben möglicherweise eine große Anzahl von Zeilen in eine Tabelle in einem Data Lakehouse eingefügt, aber diese Daten sind im SQL-Analyseendpunkt noch nicht sichtbar. Es wird empfohlen, eine On-Demand-Metadatensynchronisierung zu initiieren, die über die Menübandoption "Aktualisieren " des SQL-Abfrage-Editors oder die REST-API für sql-Endpunktmetadaten ausgelöst wird. Mit dieser Option kann man eine On-Demand-Metadatensynchronisierung erzwingen und muss nicht auf den Abschluss der Metadatensynchronisierung im Hintergrund warten.
• Nicht alle Deltafeatures werden vom automatischen Synchronisierungsprozess verstanden. Weitere Informationen zur Funktionalität, die von jedem Modul in Fabric unterstützt wird, finden Sie unter Interoperabilität des Delta Lake-Tabellenformats.
• Wenn während der Verarbeitung von Extract Transform and Load (ETL) eine extrem große Anzahl von Tabellenänderungen vorhanden ist, kann eine erwartete Verzögerung auftreten, bis alle Änderungen verarbeitet werden.

Optimieren von Lakehouse-Tabellen zum Abfragen des SQL-Analyseendpunkts

Wenn der SQL-Analyseendpunkt Tabellen liest, die in einem Seehaus gespeichert sind, wird die Abfrageleistung stark vom physischen Layout der zugrunde liegenden Parkettdateien beeinflusst.

Eine große Anzahl kleiner Parkettdateien erzeugt Mehraufwand und wirkt sich negativ auf die Abfrageleistung aus. Um eine vorhersehbare und effiziente Leistung zu gewährleisten, empfehlen wir, die Tabellenspeicherung so zu verwalten, dass jede Parquet-Datei zwei Millionen Zeilen enthält. Diese Zeilenanzahl stellt eine ausgewogene Parallelitätsebene bereit, ohne das Dataset in übermäßig kleine Segmente zu fragmentieren.

Zusätzlich zu den Richtlinien für die Zeilenanzahl ist die Dateigröße ebenso wichtig. Der SQL-Analyseendpunkt arbeitet optimal, wenn Parquet-Dateien groß genug sind, um den Aufwand bei der Dateiverarbeitung zu minimieren, aber nicht so groß, dass sie die Effizienz des parallelen Scans begrenzen. Bei den meisten Arbeitslasten ist es am besten, einzelne Parquet-Dateien bei etwa 400 MB zu halten. Führen Sie die folgenden Schritte aus, um dieses Gleichgewicht zu erreichen:

1. Festlegen maxRecordsPerFile auf 2.000.000, bevor Datenänderungen vorgenommen werden.
2. Führen Sie Ihre Datenänderungen aus (Datenaufnahme, Aktualisierungen, Löschvorgänge).
3. Setzen Sie maxFileSize auf 4 GB.
4. Führen Sie OPTIMIZE aus. Für detaillierte Informationen zur Verwendung von OPTIMIZE lesen Sie Tabellenwartungsvorgänge.

Das folgende Skript enthält eine Vorlage für diese Schritte und sollte auf einem Seehaus ausgeführt werden:

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", 400 * 1024 * 1024 * 1024)

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

Um fehlerfreie Dateigrößen beizubehalten, sollten Benutzer regelmäßig Delta-Optimierungsvorgänge wie OPTIMIZE ausführen, insbesondere für Tabellen, die häufige inkrementelle Schreibvorgänge, Updates und Löschvorgänge erhalten. Diese Wartungsvorgänge komprimieren kleine Dateien in entsprechend große Dateien, wodurch sichergestellt wird, dass der SQL-Analyseendpunkt Abfragen effizient verarbeiten kann.

Hinweis

Anleitung zur allgemeinen Wartung von Lakehouse-Tabellen finden Sie unter Ad-hoc-Wartung von Tabellen in einer Delta-Tabelle mit Lakehouse ausführen.

Überlegungen zur Partitionsgröße

Die Auswahl der Partitionsspalte für eine Delta-Tabelle in einem Lakehouse wirkt sich auch auf die Dauer der Synchronisierung von Änderungen mit dem SQL-Analyseendpunkt aus. Die Anzahl und Größe von Partitionen der Partitionsspalte sind für die Leistung wichtig:

• Eine Spalte mit hoher Kardinalität, die überwiegend oder vollständig aus eindeutigen Werten besteht, führt zu einer großen Anzahl von Partitionen. Eine große Anzahl von Partitionen wirkt sich negativ auf die Leistung beim Ermitteln von Metadatenänderungen aus. Wenn die Kardinalität einer Spalte hoch ist, sollten Sie eine andere Spalte für die Partitionierung auswählen.
• Die Größe jeder Partition kann sich ebenfalls auf die Leistung auswirken. Wie empfehlen, eine Spalte zu verwenden, die eine Partition von mindestens (oder nahe) 1 GB ergeben würde. Wir empfehlen die folgenden bewährten Methoden für die Wartung Delta-Tabellen; Optimierung. Ein Python-Skript zum Auswerten von Partitionen finden Sie unter Beispielskript für Partitionsdetails.

Ein großes Volumen an kleinen Parquet-Dateien verlängert die Zeit, die benötigt wird, um Änderungen zwischen einem Lakehouse und dem zugehörigen SQL-Analyseendpunkt zu synchronisieren. Eine große Anzahl von Parquet-Dateien in einer Delta-Tabelle kann aus einem oder mehreren Gründen entstehen:

• Wenn Sie eine Partition für eine Delta-Tabelle mit einer hohen Anzahl eindeutiger Werte auswählen, wird sie nach jedem eindeutigen Wert partitioniert und kann dadurch übermäßig partitioniert sein. Wählen Sie eine Partitionsspalte aus, die keine hohe Kardinalität hat, und ergibt jeweils mindestens 1 GB einzelne Partitionen.
• Batch- und Streamingdatenerfassungsraten können je nach Häufigkeit und Umfang der in ein Lakehouse geschriebenen Änderungen ebenfalls zur Entstehung kleiner Dateien führen. So kann es z. B. eine kleine Menge an Änderungen geben, die zum Lakehouse kommen, wodurch kleine Parquet-Dateien entstehen können. Um dies zu beheben, empfehlen wir eine regelmäßige Wartung der Lakehouse-Tabelle.

Beispielskript für Partitionsdetails

Drucken Sie über das folgende Notebook einen Bericht mit der Größe und den Details der einer Delta-Tabelle zugrunde liegenden Partitionen.

1. Zuerst müssen Sie den ABSFF-Pfad für die Delta-Tabelle in der Variablen delta_table_path angeben.
   • Den ABFSS-Pfad einer Delta-Tabelle können Sie im Fabric-Portal im Explorer ermitteln. Klicken Sie mit der rechten Maustaste auf den Tabellennamen, und wählen Sie dann COPY PATH aus der Liste der Optionen aus.
2. Das Skript gibt alle Partitionen für die Delta-Tabelle aus.
3. Das Skript geht alle Partitionen durch und berechnet die Gesamtgröße und die Anzahl der Dateien.
4. Das Skript gibt die Details der Partitionen, die Dateien pro Partition und die Größe pro Partition in GB aus.

Das vollständige Skript kann aus dem folgenden Codeblock kopiert werden:

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

Zugehöriger Inhalt

• Arbeitsauslastungsübergreifende Tabellenwartung und Optimierung
• Delta Lake-Tabellenoptimierung und V-Order
• Tabellenkomprimierung
• Optimieren der Dateigröße
• Besser gemeinsam: das Lakehouse und das Warehouse
• Leistungsrichtlinien des Fabric Data Warehouse
• Einschränkungen des SQL-Analyseendpunkts