Überlegungen zur Leistung des SQL-Analyseendpunkts

Der SQL-Analyseendpunkt ermöglicht es Ihnen, Daten im Lakehouse mithilfe der T-SQL-Sprache und des TDS-Protokolls abzufragen.

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 zuständig, das Lakehouse auf Änderungen zu überprüfen und den SQL-Analyseendpunkt hinsichtlich aller Änderungen, die an Lakehouses in einem Arbeitsbereich übernommen werden, auf dem neuesten Stand zu halten. Die Fabric-Plattform verwaltet den Synchronisationsprozess transparent. 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 erläutert 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.

Leitlinien

• Die automatische Metadatenerkennung verfolgt Änderungen, die an Lakehouses vorgenommen wurden, und ist eine einzelne Instanz pro Fabric-Arbeitsbereich. Wenn Sie eine erhöhte Latenz für Änderungen der Synchronisierung zwischen Seehäusern und dem SQL-Analyseendpunkt beobachten, kann dies auf eine große Anzahl von Seehäusern in einem Arbeitsbereich zurückzuführen sein. In einem solchen Szenario sollten Sie jedes Lakehouse in einen eigenen Arbeitsbereich migrieren, da dieser Ansatz es ermöglicht, die automatische Metadatenermittlung zu skalieren.
• Parquet-Dateien sind konstruktionsbedingt unveränderlich. Bei einer Aktualisierung oder einem Löschvorgang fügt eine Delta-Tabelle neue Parquet-Dateien mit dem Änderungssatz hinzu, wodurch sich die Anzahl der Dateien im Laufe der Zeit erhöht – abhängig von der Häufigkeit der Aktualisierungen und Löschvorgänge. Wenn Sie keine Wartung planen, erstellt dieses Muster schließlich einen Leseaufwand, und diese Bedingung wirkt sich auf die Zeit aus, die zum Synchronisieren von Änderungen am SQL-Analyseendpunkt benötigt wird. Um dieses Problem zu beheben, planen Sie regelmäßige Wartungsvorgänge für Lakehouse-Tabellen.
• In einigen Szenarien stellen Sie möglicherweise fest, dass Änderungen, die an einem Lakehouse übertragen wurden, im zugeordneten SQL-Analyseendpunkt nicht sichtbar sind. Sie können z. B. eine neue Tabelle im Seehaus erstellen, aber sie ist noch nicht im SQL-Analyseendpunkt aufgeführt. Oder Sie können eine große Anzahl von Zeilen auf eine Tabelle in einem Seehaus commiten, aber diese Daten sind noch nicht im SQL-Analyseendpunkt sichtbar. Sie haben die Möglichkeit, die Synchronisierung von On-Demand-Metadaten zu starten.
• Der automatische Synchronisierungsprozess unterstützt nicht alle Delta-Features. 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, tritt eine erwartete Verzögerung auf, bis alle Änderungen verarbeitet werden.

Optimieren von Lakehouse-Tabellen zum Abfragen des SQL-Analyseendpunkts

Wenn der SQL-Analyseendpunkt Tabellen liest, die in einem Lakehouse gespeichert sind, hängt die Abfrageleistung stark vom physischen Layout der zugrunde liegenden Parquet-Dateien ab. Die Engine parallelisiert die Scanvorgänge auf der Ebene von Parquet-Dateien. Zu viele kleine Dateien erhöhen den Datei- und Metadaten-Overhead, während zu wenige große Dateien den Scan-Parallelismus einschränken können.

Für von Spark geschriebene Tabellen verwenden Sie die Standardeinstellungen in Fabric Spark Runtime 2.0 oder neuer. Diese Runtimes ermöglichen standardmäßig eine adaptive Zieldateigröße, um pro Tabelle automatisch die optimale Zieldateigröße auszuwählen – von 128 MB für kleinere Tabellen bis zu 1 GB für die größten Tabellen. Vermeiden Sie es, statische Ziele oder beliebige Zeilenbegrenzungen zusätzlich zu den Standardkonfigurationen zu setzen. Ein Zeilenlimit berücksichtigt die Zeilenbreite nicht und kann kleine Dateien für schmale Tabellen erstellen.

Wenn Sie Fabric Spark Runtime 1.3 verwenden, aktivieren Sie adaptive Ziel-Dateigröße und Datei-Level-Kompaktierungsziele, die als Opt-in-Funktionen verfügbar sind.

Du brauchst kein V-Order für eine verbesserte Leistung von SQL-Analytics-Endpunkten, da Spark Parquet-Dateien schreibt, die Snappy komprimiert sind, um sowohl Lese- als auch Schreib-I/O zu reduzieren.

Standard-Schreibeinstellungen ersetzen nicht die Tabellenpflege. Verwenden Sie die folgenden Methoden, um ein gesundes Layout zu erhalten, wenn sich die Tabellen ändern:

• Automatische Verdichtung für Workloads aktivieren, bei denen die periodische zusätzliche synchrone Schreiblatenz akzeptabel ist. Automatische Verdichtung ist eine Spark-Funktion, die nur läuft, wenn zu viele kleine Dateien in einer Tabelle sind.
• Planen Sie periodische OPTIMIZE Jobs für Workloads, bei denen die zusätzliche periodische Latenz durch automatische Komprimierung die SLAs für Datenaktualisierungen nicht erfüllt.
• Führe VACUUM gemäß deinen Aufbewahrungs- und Zeitreiseanforderungen durch, um Dateien zu entfernen, auf die das Delta-Log nicht mehr verweist. VACUUM reduziert den gespeicherten Speicher, verbessert aber nicht das aktive Dateilayout.
• Vermeiden Sie Partitionierungen mit hoher Kardinalität und benutzerdefinierte Writer-Konfigurationen, die viele kleine Dateien erzeugen.

Wenn Sie keine automatische Verdichtung verwenden, verwenden Sie zur Identifizierung von Tabellen, die Wartung benötigen, eine Datenpipeline und das gespeicherte sys.sp_get_table_health_metrics T-SQL-Verfahren vor dem Ausführen OPTIMIZE. Ein Tutorial finden Sie unter Lakehouse-Tabellen auf Grundlage von Integritätsprüfungen optimieren.

Überlegungen zur Partitionsgröße

Die Wahl der Partitionsspalte für eine Delta-Tabelle in einem Lakehouse beeinflusst auch die Zeit, die benötigt wird, um Änderungen an den SQL-Analytics-Endpunkt zu synchronisieren. 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. Verwenden Sie eine Spalte, die zu einer Partition von mindestens (oder nahe) 1 GB führt. Befolgen Sie Best Practices für Wartung und Partitionierung von Delta-Tabellen. Ein Python Skript zum Auswerten von Partitionen finden Sie unter Sample-Skript 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. Aus einem oder mehreren Gründen könnten Sie eine große Anzahl von Parkettdateien in einer Delta-Tabelle haben:

• Wenn Sie eine Partition für eine Delta-Tabelle mit hoher Anzahl eindeutiger Werte auswählen, wird die Tabelle von jedem eindeutigen Wert partitioniert und kann überpartitioniert werden. 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 dieses Problem zu beheben, führen Sie regelmäßige Lakehouse-Tabellenwartung durch.

Beispielskript für Partitionsdetails

Verwenden Sie das folgende Notizbuch, um einen Bericht auszudrucken, der die Größe und Details der Partitionen detailliert beschreibt, die einer Delta-Tabelle zugrunde liegen.

1. Gib zuerst den ABFSS-Pfad für deine Delta-Tabelle in der Variablen delta_table_pathan.
   • 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.

Sie können das vollständige Skript aus dem folgenden Codeblock kopieren:

# 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 generiertes Schema im SQL-Analyseendpunkt des Lakehouse

Der SQL-Analyseendpunkt generiert für jede Deltatabelle in Ihrem Lakehouse automatisch eine Tabelle im passenden Schema. Das SQL Analytics-Endpunktmodul basiert auf dem Fabric Data Warehouse-Modul.

Weitere Informationen finden Sie unter SQL Analytics-Endpunktmetadatensynchronisierung. Sie können eine Aktualisierung der automatischen Metadatenüberprüfung auch programmgesteuert erzwingen, indem Sie die REST-API für sql-Endpunkte aktualisieren.

Verwandte Inhalte

• Arbeitsauslastungsübergreifende Tabellenwartung und Optimierung
• Delta-Lake-Tabellenoptimierung und V-Ordnung
• Tabellenkomprimierung
• Optimieren der Dateigröße
• Lakehouse SQL Analytics-Endpunkt-Anwendungsfälle