Ü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 Microsoft Fabric Plattform verwaltet den Synchronisierungsprozess 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.

Eine große Anzahl kleiner Parkettdateien erzeugt Mehraufwand und wirkt sich negativ auf die Abfrageleistung aus. Um eine vorhersehbare und effiziente Performance sicherzustellen, achten Sie darauf, den Tabellenspeicher 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 erzielt die beste Leistung, wenn Parquet-Dateien groß genug sind, um den Dateiverwaltungsaufwand zu minimieren, aber nicht so groß, dass sie die Effizienz paralleler Scans einschränken. Für die meisten Workloads ist es der beste Kompromiss, 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. Weitere Details zur Verwendung von OPTIMIZE finden Sie unter Tabellenwartung über Lakehouse ausführen.

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

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

Um angemessene Dateigrößen beizubehalten, führen Sie regelmäßig Delta-Optimierungsvorgänge wie OPTIMIZE aus, insbesondere bei Tabellen, in die häufig inkrementelle Einfügungen vorgenommen werden oder an denen häufig Aktualisierungen und Löschungen erfolgen. Diese Wartungsvorgänge komprimieren kleine Dateien in entsprechend große Dateien, wodurch sichergestellt wird, dass der SQL-Analyseendpunkt Abfragen effizient verarbeiten kann.

Ü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. Verwenden Sie eine Spalte, die zu einer Partition von mindestens (oder nahe) 1 GB führt. Befolgen Sie bewährte Methoden für die Wartung und Optimierung 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. 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 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

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

1. Geben Sie zunächst den ABFSS-Pfad für Ihre Delta-Tabelle in der Variablen delta_table_path an.
   • 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-Order
• Tabellenkomprimierung
• Optimieren der Dateigröße
• Lakehouse SQL Analytics-Endpunkt-Anwendungsfälle