Ü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. Es nutzt den Fabric Data Warehouse Motor.

Tip

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 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 läuft, während der SQL-Analytics-Endpunkt aktiv ist, und stoppt nach 15 Minuten ohne Abfrageaktivität.

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 können die On-Demand-Metadaten-Synchronisierung im Fabric-Portal starten oder die Refresh SQL Analytics Endpoint Metadata REST API verwenden.
  • 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.

V-Order kommt hauptsächlich Power BI Direct Lake zugute, und obwohl es die Kompression für einige Workloads verbessern kann, ist es im Allgemeinen nicht standardmäßig erforderlich oder empfohlen für optimale Leistung von SQL-Analytics-Endpunkten.

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.

Note

Informationen zur allgemeinen Wartung von Lakehouse-Tabellen finden Sie unter Tabellenwartung im Lakehouse ausführen.

Überlegungen zur Partitionsgröße

Das Partitionslayout beeinflusst, wie lange der SQL-Analytics-Endpunkt benötigt, um Änderungen zu entdecken und zu synchronisieren. Eine große Anzahl von Partitionen oder kleinen Parquet-Dateien erhöht den Overhead für Metadaten-Scans. Befolgen Sie die folgenden Methoden:

  • Vermeiden Sie Partitionsspalten mit hoher Kardinalität, da dies dazu führen kann, dass für jeden eindeutigen Wert eine Partition angelegt wird. Wähle eine Spalte, die Partitionen von etwa 1 GB oder größer als 1 GB erzeugt. Für weitere Informationen siehe Delta Lake Tabellenaufteilung.
  • Batch- und Streaming-Datenaufnahme können kleine Dateien erzeugen, wenn Änderungen häufig auftreten oder nur geringfügig sind. Verwenden Sie regelmäßige Wartung von Lakehouse-Tabellen, um diese Dateien zu kompaktieren.

Um die Größe und Dateianzahl jeder Partition zu bewerten, verwenden Sie das Beispielskript für Partitionsdetails.

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

Verwandte Inhalte

  • Last updated on