Freigeben über

Überlegungen zur Leistung des SQL-Analyseendpunkts

  • Artikel

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. 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-Analyseendpunkt hinsichtlich aller Änderungen an Lakehouses in einem Arbeitsbereich auf dem neuesten Stand 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 der Anzahl von Faktoren variieren, die in diesem Artikel besprochen werden: von einigen Sekunden bis hin zu Minuten.

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. Sobald Sie die Delta Lake-Tabelle im Lake erstellt oder aktualisiert haben, wird die SQL-Analyseendpunkttabelle, die auf die Delta Lake-Tabelle verweist, automatisch erstellt/aktualisiert.

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. In dem Artikel werden Schllüsselszenarien dargestellt und Sie erhalten eine ausführliche Anleitung zur effizienten Verwaltung von Delta-Tabellen, 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. Wechseln Sie zum Abfragen Ihres SQL-Analyseendpunkts, und suchen Sie nach der Schaltfläche "Aktualisieren", wie in der folgenden Abbildung dargestellt.

Screenshot des Fabric-Portals mit der Schaltfläche „SQL-Analyseendpunkt aktualisieren“.

Leitfaden

  • Die automatische Metadatenermittlung verfolgt die an Lakehouses erfolgten Änderungen und ist eine einzelne Instanz pro Fabric-Arbeitsbereich. Wenn beim Synchronisieren von Änderungen zwischen Lakehouses und dem SQL-Analyseendpunkt eine längere Wartezeit festzustellen ist, kann dies auf eine große Anzahl von Lakehouses in einem 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.
  • Parket-Dateien sind grundsätzlich 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 ist gegebenenfalls festzustellen, dass die an einem Lakehouse vorgenommenen Änderungen im zugeordneten SQL-Analyseendpunkt nicht zu sehen sind. Sie haben zum Beispiel im Lakehouse eine neue Tabelle erstellt, die im SQL-Analyseendpunkt aber nicht aufgelistet wird. Oder Sie haben eine große Anzahl von Zeilen an eine Tabelle in einem Lakehouse übergeben, aber diese Daten sind im SQL-Analyseendpunkt nicht zu sehen. Es empfiehlt sich, eine On-Demand-Metadatensynchronisierung zu initiieren, die über die Option Aktualisieren im Menüband des SQL-Abfrage-Editors ausgelöst werden kann. 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 zu den Funktionen, die von den einzelnen Engines in Fabric unterstützt werden, finden Sie unter Delta Lake-Interoperabilität.
  • Wenn während der Verarbeitung von Extract Transform and Load (ETL) eine extrem große Menge von Tabellenänderungen vorhanden ist, kann eine erwartete Verzögerung auftreten, bis alle Änderungen verarbeitet werden.

Ü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 (überwiegend oder vollständig aus eindeutigen Werten) führt zu einer großen Anzahl von Partitionen. Eine große Anzahl von Partitionen wirkt sich negativ auf die Leistung des Scannens der Metadatenermittlung auf Ä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 kleiner Parquet-Dateien verlängert die Dauer der Synchronisierung von Änderungen zwischen einem Lakehouse und dem zugeordneten SQL-Analyseendpunkt. Einer große Anzahl von Parquet-Dateien in einer Delta-Tabelle kann sich aus einem oder mehreren Gründen ergeben:

  • 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 eine einzelne Partitionsgröße von mindestens 1 GB ergibt.
  • Batch- und Streamingdatenerfassungsraten können je nach Häufigkeit und Umfang der in ein Lakehouse geschriebenen Änderungen ebenfalls zur Entstehung kleiner Dateien führen. Es könnte zum Beispiel könnte ein kleiner Umfang an Änderungen zum Lakehouse gelangen, wodurch kleine Parquet-Dateien entstehen würden. 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