Grundlegendes zur Leistung von Direct Lake-Abfragen

Abgesehen von der Komplexität des semantischen Modells und der Abfrage hängt die Direct Lake-Leistung speziell von gut abgestimmten Delta-Tabellen für effizientes und schnelles Laden von Spalten (Transcodierung) und einer optimalen Abfrageausführung ab. Stellen Sie sicher, dass Sie die V-Order-Optimierung anwenden. Behalten Sie auch die Anzahl der Parquet-Dateien klein, verwenden Sie große Zeilengruppen, und bemühen Sie sich, die Auswirkungen von Datenaktualisierungen auf das Delta-Log zu minimieren. Diese gängigen Best Practices helfen dabei, eine schnelle Abfrageausführung im kalten, halbwarmen, warmen und heißen Direct-Lake-Modus sicherzustellen.

In diesem Artikel wird erläutert, wie die Direktsee-Leistung von der Gesundheit der Delta-Tabellen und effizienten Datenaktualisierungen abhängt. Die von Ihnen getroffenen Speicherentscheidungen – Dateilayout, Aktualisierungsmuster und Wartungsroutinen – bestimmen direkt, wie schnell Direct Lake Ihre Daten laden und abfragen kann. Das Datenlayout in Ihren Parquet-Dateien ist für die Abfrageleistung genauso wichtig wie ein gutes semantisches Modelldesign und gut abgestimmte Datenanalyse-Ausdrucksmessungen (DAX).

Was Sie wissen müssen

In diesem Artikel wird davon ausgegangen, dass Sie bereits mit den folgenden Konzepten vertraut sind:

• Delta-Tabellen in OneLake: Detaillierte Informationen zu Delta-Tabellen in OneLake finden Sie in der Grundlagendokumentation von Microsoft Fabric.
• Geparkte Dateien, Zeilengruppen und Delta-Protokoll: Das Parkettdateiformat, einschließlich der Organisation von Daten in Zeilengruppen und Spaltenblöcken und wie Metadaten verarbeitet werden, wird in der Dokumentation zum Format "Parkett" erläutert. Siehe auch die Dokumentation zum Delta-Transaktionsprotokoll.
• Delta-Tabellenoptimierung und V-Order: Lesen Sie die Fabric Lakehouse-Dokumentation zur Delta-Tabellenwartung, z. B. Delta Lake-Tabellenoptimierung und V-Order.
• Rahmen und Transcodierung: Das Aktualisieren eines Direct Lake-Semantikmodells (Framing) und das Laden von Daten nach Bedarf (Transcodierung) sind wichtige Konzepte, die auf einführungsbezogener Ebene im Übersichtsartikel "Direct Lake" behandelt werden.
• Formel- und Speicher-Engine: Wenn eine DAX-Abfrage ausgeführt wird, erstellt die Formel-Engine den Abfrageplan und ruft die notwendigen Daten und anfänglichen Aggregationen von der Speicher-Engine ab. Die in diesem Artikel beschriebenen Optimierungen konzentrieren sich auf das Speichermodul. Weitere Informationen zum Formelmodul und zum Speichermodul finden Sie in der Analysis Services-Entwicklerdokumentation.
• VertiPaq und VertiScan: Im Importmodus und im Direct Lake-Modus verwendet der Speichermotor seinen VertiPaq-Motor, um einen spaltenbasierten Speicher zu verwalten. VertiScan ermöglicht es der Formel-Engine, mit VertiPaq zu interagieren. Weitere Informationen finden Sie in der Analysis Services-Entwicklerdokumentation.
• Wörterbuchcodierung: Sowohl Parquet-Dateien als auch VertiPaq verwenden die Wörterbuchcodierung, eine Datenkomprimierungstechnik, die auf einzelne Spalten verschiedener Datentypen wie int, long, date und char angewendet wird. Es funktioniert, indem jeder eindeutige Spaltenwert im Arbeitsspeicher als ganze Zahl mithilfe der RLE-Codierung (Run Length Encoding) /Bit-Packing Hybridcodierung gespeichert wird. VertiPaq verwendet immer die Wörterbuchcodierung, aber Parquet kann unter bestimmten Umständen auf einfache Codierung oder Delta-Codierung umgestellt werden, wie in den Codierungen in der Parquet-Dokumentation File-Format erläutert, was erfordern würde, dass Direct Lake die Daten neu codiert, mit entsprechenden Auswirkungen auf die Kodierungsleistung.
• Spaltenblöcke und Spaltensegmente: Verweisen Sie auf die Art und Weise, wie Parkett- und VertiPaq-Spaltendaten zum effizienten Datenabruf gespeichert werden. Jede Spalte in einer Tabelle wird in kleinere Abschnitte unterteilt, die unabhängig voneinander verarbeitet und komprimiert werden können. VertiPaq bezeichnet diese Chunks als Segmente. Sie können das DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS Schema-Rowset verwenden, um Informationen zu den Spaltensegmenten in einem Direct Lake-Semantikmodell abzurufen.
• Python- und Jupyter-Notizbücher: Jupyter-Notizbücher bieten eine interaktive Umgebung zum Schreiben und Ausführen von Python-Code. Grundlegende Kenntnisse von Python sind hilfreich, wenn Sie den Codeausschnitten weiter unten in diesem Kapitel folgen möchten. Weitere Informationen finden Sie in der Python-Sprachreferenz. Informationen zur Verwendung von Notizbüchern in Microsoft Fabric finden Sie unter Verwendung von Notizbüchern – Microsoft Fabric.

Auswirkungen auf die Leistung von Direct Lake-Abfragen

In diesem Abschnitt werden die wichtigsten Faktoren zusammengefasst, die sich auf die Leistung von Direct Lake auswirken. Nachfolgende Abschnitte bieten ausführlichere Erläuterungen:

• V-Order-Komprimierung: Die Effektivität der Komprimierung kann sich auf die Abfrageleistung auswirken, da eine bessere Komprimierung zu schnellerem Laden von Daten und effizienterer Abfrageverarbeitung führt. Das Laden von Daten ist schnell, da das Streamen komprimierter Daten die Transcodierungseffizienz erhöht. Die Abfrageleistung ist auch optimal, da die V-Order-Komprimierung VertiScan ermöglicht, Ergebnisse direkt über komprimierten Daten zu berechnen und den Dekomprimierungsschritt zu überspringen.
• Datentypen: Die Verwendung geeigneter Datentypen für Spalten kann die Komprimierung und Leistung verbessern. Verwenden Sie beispielsweise ganzzahlige Datentypen anstelle von Zeichenfolgen, soweit möglich, und vermeiden Sie das Speichern ganzzahliger Zahlen als Zeichenfolgen.
• Segmentgröße und -anzahl: VertiPaq speichert Spaltendaten in Segmenten. Eine große Anzahl kleinerer Segmente kann sich negativ auf die Abfrageleistung auswirken. Bei großen Tabellen bevorzugt Direct Lake große Segmentgrößen, z. B. zwischen 1 Millionen und 16 Millionen Zeilen.
• Spaltenkardinalität: Spalten mit hoher Kardinalität (Spalten mit vielen eindeutigen Werten) können die Leistung verlangsamen. Das Reduzieren der Kardinalität, wenn möglich, kann helfen.
• Indizes und Aggregationen: Spalten mit niedrigerer Kardinalität profitieren von der Wörterbuchcodierung, wodurch Abfragen beschleunigt werden können, indem die Menge der zu scannenden Daten reduziert wird.
• DirectQuery-Fallback: Fallbackvorgänge können zu einer langsameren Abfrageleistung führen, da die Daten jetzt vom SQL-Analyseendpunkt der Fabric-Datenquelle abgerufen werden müssen. Darüber hinaus basiert Fallback auf Hybridabfrageplänen, um Sowohl DirectQuery als auch VertiScan mit einigen Kompromissen bei der Leistung zu unterstützen, auch wenn Direct Lake nicht ausweichen muss. Deaktivieren Sie nach Möglichkeit DirectQuery-Fallback, um Hybridabfragepläne zu vermeiden.
• Grad der Speicherresidenz: Direct Lake-Semantikmodelle können sich im kalten, halbwarmen, warmen oder heißen Zustand befinden, wobei die Leistung von kalt zu heiß zunehmend besser wird. Der schnelle Übergang von Kalt zu Warm ist ein Schlüssel zu einer guten Direct Lake-Leistung.
  • Kalt: Der VertiPaq-Speicher ist leer. Alle Zum Beantworten einer DAX-Abfrage erforderlichen Daten müssen aus Delta-Tabellen geladen werden.
  • Semiwarm: Direct Lake verwirft nur die Spaltensegmente, die zu entfernten Zeilengruppen gehören, während des Framings. Dies bedeutet, dass nur aktualisierte oder neu hinzugefügte Daten geladen werden müssen. Ein Direct Lake-Semantikmodell kann auch unter Speicherdruck in semiwarm zustand wechseln, wenn Segmente entladen und Indizes aufgrund des Speicherdrucks verknüpft werden müssen.
  • Warm: Die spaltendaten, die zum Beantworten einer DAX-Abfrage erforderlich sind, sind bereits vollständig in den Arbeitsspeicher geladen.
  • Hot: Die Spaltendaten werden bereits vollständig in den Arbeitsspeicher geladen, VertiScan-Caches werden aufgefüllt, und die DAX-Abfragen treffen die Caches.
• Arbeitsspeicherdruck: Direct Lake muss alle Spaltendaten laden, die erforderlich sind, um eine DAX-Abfrage in den Arbeitsspeicher zu beantworten, was verfügbare Speicherressourcen ausschöpfen kann. Mit unzureichendem Arbeitsspeicher muss Direct Lake zuvor geladene Spaltendaten entladen, die direct Lake dann für nachfolgende DAX-Abfragen erneut laden muss. Eine angemessene Größenanpassung von Direct Lake-Semantikmodellen kann dazu beitragen, häufiges Neuladen zu vermeiden.

Speicherbewahrung und Abfrageleistung

Direct Lake funktioniert am besten in warmen oder heißen Zuständen, während kalte Zustände zu langsamer Leistung führen. Direct Lake vermeidet es so weit wie möglich, auf Cold-Storage zurückzufallen, indem es inkrementelles Framing verwendet.

Eigenstart

Nach dem Laden des ersten semantischen Modells befinden sich noch keine Spaltendaten im Arbeitsspeicher. Direct Lake ist kalt. Wenn ein Client eine DAX-Abfrage an ein Direct Lake-Semantikmodell im kalten Zustand sendet, muss Direct Lake die folgenden Hauptaufgaben ausführen, damit die DAX-Abfrage verarbeitet und beantwortet werden kann:

• VertiPaq-Wörterbuchtranscodierung. Direct Lake muss die lokalen Parkettwörterbücher für jeden Spaltenabschnitt zusammenführen, um ein globales VertiPaq-Wörterbuch für die Spalte zu erstellen. Dieser Zusammenführungsvorgang wirkt sich auf die Abfrageantwortzeit aus.

• Laden von Parquet-Spaltenblöcken in Spaltensegmente. In den meisten Fällen ist dieser Schritt eine direkte Umzuordnung von Parquet-Daten-IDs zu VertiPaq-IDs, wenn beide Seiten RLE/Bit-Packing Hybrid-Kodierung verwenden können. Wenn die Parquet-Wörterbücher die Plain-Codierung verwenden, muss VertiPaq die Werte in RLE/Bit-Packing-Hybridcodierung konvertieren, was mehr Zeit in Anspruch nimmt.

  • Die Direct Lake-Leistung ist bei V-Ordered Parquet-Dateien optimal, da V-Ordering die Qualität der RLE-Komprimierung erhöht. Direct Lake kann eng verpackte V-Ordered-Daten schneller laden als weniger komprimierte Daten.

• Generieren von Verknüpfungsindizes. Wenn die DAX-Abfrage auf Spalten aus mehreren Tabellen zugreift, muss Direct Lake Verknüpfungsindizes entsprechend den Tabellenbeziehungen erstellen, damit VertiScan die Tabellen korrekt verknüpfen kann. Zur Erstellung der Verknüpfungsindizes muss Direct Lake die Wörterbücher der Schlüsselspalten laden, die an der Beziehung teilnehmen, sowie die Spaltensegmente der Primärschlüsselspalte (die Spalte auf der Eins-Seite der Tabellenbeziehung).

• Anwenden von Delta-Löschvektoren. Wenn eine Delta-Quelltabelle Löschvektoren verwendet, muss Direct Lake diese Löschvektoren laden, um sicherzustellen, dass gelöschte Daten von der Abfrageverarbeitung ausgeschlossen werden.

  Anmerkung

  Du kannst auch den kalten Zustand induzieren, indem du einen processClear gefolgt von einem processFull XMLA-Befehl an das Modell sendest. Mit ProcessClear dem Befehl werden alle Daten und die Zuordnung mit der gerahmenten Delta-Tabellenversion entfernt. Der ProcessFull XMLA-Befehl führt das Framing durch, um das Modell mit der neuesten verfügbaren Delta-Commit-Version zu verbinden.

Inkrementelle Rahmenung

Direct Lake vermeidet einen vollständigen Kaltzustand-Neuladen durch inkrementelles Framing: Wenn sich nur ein Teil einer Delta-Tabelle ändert, verwendet es die noch gültigen In-Memory-Daten, anstatt alles neu zu laden. Für eine konzeptuelle Erklärung, wie Framing das Delta-Log analysiert und das semantische Modell aktualisiert, siehe Framing. Dieser Abschnitt konzentriert sich darauf, wie man die Effektivität des inkrementellen Framings misst und wie sich Ihre Aktualisierungsmuster der Delta-Tabelle darauf auswirken.

Sie können die inkrementelle Framing-Effektivität mithilfe der INFO.STORAGETABLECOLUMNSEGMENTS() DAX-Funktion analysieren, die das DISCOVER_STORAGE_TABLE_COLUMN_SEGMENTS Schema-Rowset umschließt. Führen Sie die folgenden Schritte aus, um aussagekräftige Ergebnisse sicherzustellen:

1. Abfragen Sie Ihr Direct Lake-semantisches Modell, um sicherzustellen, dass es sich im warmen oder heißen Zustand befindet.
2. Aktualisieren Sie die Delta-Tabelle, die Sie untersuchen möchten, und das Direct Lake-Semantikmodell, um die Rahmenbildung durchzuführen.
3. Führen Sie eine DAX-Abfrage aus, um Spaltensegmentinformationen mithilfe der INFO.STORAGETABLECOLUMNSEGMENTS() Funktion abzurufen, wie im folgenden Screenshot gezeigt. Der Screenshot verwendet eine kleine Beispieltabelle zur Veranschaulichung. Jede Spalte verfügt nur über ein einzelnes Segment. Die Segmente befinden sich nicht im Arbeitsspeicher. Dieser Zustand deutet auf einen echten kalten Zustand hin. Wenn das Modell vor der Framing warm war, bedeutet diese Bedingung, dass die Delta-Tabelle mit einem destruktiven Datenlademuster aktualisiert wurde, was die Verwendung von inkrementellem Framing unmöglich macht. Delta-Tabellenaktualisierungsmuster werden weiter unten in diesem Artikel behandelt.

Komplette Speicherresidenz

Wenn Direct Lake Wörterbücher, Spaltensegmente und Join-Indizes lädt, erreicht es den warmen Zustand mit einer Abfrageleistung, die dem Importmodus entspricht. In beiden Modi spielen die Anzahl und Größe von Spaltensegmenten eine entscheidende Rolle bei der Optimierung der Abfrageleistung.

Delta-Tabellenunterschiede

Wie Sie Ihre Delta-Tabellen direkt strukturieren, beeinflusst, wie effizient Direct Lake Spalten laden und Abfragen ausführen kann. Parquet-Dateien organisieren Daten nach Spalten anstatt nach Zeilen. Direct Lake organisiert auch Daten nach Spalten. Diese Ausrichtung ermöglicht eine nahtlose Integration, doch es gibt wichtige Unterschiede, insbesondere in Bezug auf Zeilengruppen und Wörterbücher.

Zeilengruppen im Vergleich zu Spaltensegmenten

Eine Zeilengruppe in einer Parkettdatei besteht aus Spaltenblöcken, und jeder Abschnitt enthält Daten für eine bestimmte Spalte. Ein Spaltensegment in einem semantischen Modell enthält ebenfalls einen Abschnitt der Spaltendaten.

Es gibt eine direkte Beziehung zwischen der Gesamtzahl der Zeilengruppenanzahl einer Delta-Tabelle und der Segmentanzahl für jede Spalte der entsprechenden Semantikmodelltabelle. Wenn beispielsweise eine Delta-Tabelle in allen aktuellen Parquet-Dateien insgesamt drei Zeilengruppen hat, hat die entsprechende semantische Modelltabelle drei Segmente pro Spalte, wie im folgenden Diagramm dargestellt. Mit anderen Worten: Wenn eine Delta-Tabelle eine große Anzahl winziger Zeilengruppen hat, besitzt auch eine entsprechende semantische Modelltabelle eine große Anzahl winziger Spaltensegmente. Diese Struktur wirkt sich negativ auf die Abfrageleistung aus.

Lokale Wörterbücher im Vergleich zum globalen Wörterbuch

Die Gesamtzahl der Zeilengruppen einer Delta-Tabelle beeinflusst auch direkt die Dictionary-Transcoding-Leistung, da Parquet-Dateien lokale Wörterbücher verwenden, während Direct-Lake-semantische Modelle für jede Spalte ein globales Wörterbuch verwenden, wie im folgenden Diagramm dargestellt. Je höher die Anzahl von Zeilengruppen ist, desto höher ist die Anzahl der lokalen Wörterbücher, die Direct Lake zusammenführen muss, um ein globales Wörterbuch zu erstellen, und je länger es dauert, bis die Transcodierung abgeschlossen ist.

Delta-Tabellenaktualisierungsmuster

Die Methode, mit der du Daten in eine Delta-Tabelle einführst, beeinflusst maßgeblich die Effizienz des inkrementellen Framings. Diese Effizienz bestimmt, ob Abfragen mit Warmzustandsgeschwindigkeit laufen oder eine vollständige Kaltzustands-Neuladung erfahren. Wenn du zum Beispiel die Option Überschreiben beim Laden von Daten in eine bestehende Tabelle nutzt, löschst du das Delta-Log. Diese Aktion bedeutet, dass Direct Lake kein inkrementelles Framing verwenden kann und alle Daten, Wörterbücher und Join-Indizes neu laden muss. Das erneute Laden im Kaltzustand erhöht die Abfragelatenz, da jedes Spaltensegment rekodiert werden muss, bevor die Abfrage abgeschlossen werden kann.

Dieser Abschnitt behandelt Aktualisierungsmuster für Delta-Tabellen, die es Direct Lake ermöglichen, inkrementelles Framing zu verwenden. Diese Muster bewahren VertiPaq-Spaltenspeicherelemente wie Wörterbücher, Spaltensegmente und Join-Indizes, um die Transkodierungseffizienz zu maximieren und die Leistung bei kalten Abfragen zu steigern.

Batchverarbeitung ohne Partitionierung

Dieses Aktualisierungsmuster sammelt und verarbeitet Daten in großen Batches in geplanten Intervallen, z. B. wöchentlich oder monatlich. Wenn neue Daten eintreffen, entfernt der Prozess alte Daten oft in rollierendem oder gleitendem Fenster, um die Tabellengröße unter Kontrolle zu halten. Das Entfernen alter Daten kann jedoch eine Herausforderung darstellen, wenn die Daten über die meisten Parquet-Dateien verteilt sind. Beispielsweise könnte das Entfernen eines Tages aus einem Zeitraum von 30 Tagen 95% der Parquet-Daten betreffen, anstelle von 5%. In diesem Fall muss Direct Lake 95% der Daten selbst für eine relativ kleine Löschoperation neu laden. Dasselbe Problem gilt auch für Updates vorhandener Zeilen, da diese das Löschen und Anhängen kombinieren. Sie können die Auswirkungen von Lösch - und Aktualisierungsvorgängen mithilfe von Delta Analyzer analysieren, wie weiter unten in diesem Artikel erläutert.

Batchverarbeitung mit Partitionierung

Delta-Tabellen-Partitionierung kann helfen, die Wirkung von Löschvorgängen zu verringern, da die Tabelle in kleinere Parquet-Dateien unterteilt wird, die in Ordnern basierend auf den unterschiedlichen Werten in der Partitionsspalte gespeichert sind. Häufig verwendete Partitionsspalten umfassen Datum, Region oder andere dimensionale Kategorien. Im vorherigen Beispiel zum Entfernen eines Tages aus 30 Tagen würde eine Delta-Tabelle, die nach Datum partitioniert wird, die Löschungen nur auf die Parkettdateien der Partition für diesen Tag beschränken. Eine umfangreiche Partitionierung kann jedoch zu einer deutlich erhöhten Anzahl von Parquet-Dateien und Zeilengruppen führen, was zu einem übermäßigen Anstieg der Spaltensegmente im Direct Lake-semantischen Modell führt und die Abfrageleistung negativ beeinflusst. Die Auswahl einer Partitionsspalte mit niedriger Kardinalität ist für die Abfrageleistung von entscheidender Bedeutung. Als bewährte Methode sollte die Spalte weniger als 100-200 eindeutige Werte aufweisen.

Inkrementelles Laden

Beim inkrementellen Laden fügt der Aktualisierungsvorgang nur neue Daten in eine Delta-Tabelle ein, ohne dass vorhandene Parkettdateien und Zeilengruppen betroffen sind. Es sind keine Löschungen vorhanden. Direct Lake kann die neuen Daten inkrementell laden, ohne vorhandene VertiPaq-Spaltenspeicherelemente verwerfen und neu laden zu müssen. Diese Methode eignet sich gut für das inkrementelle Framing von Direct Lake. Delta-Tabellenpartitionierung ist nicht erforderlich.

Streamverarbeitung

Die Verarbeitung von Daten nahezu in Echtzeit, während sie eintreffen, kann zu einer Proliferation kleiner Parquet-Dateien und Zeilengruppen führen, was sich negativ auf die Direct Lake-Performance auswirken kann. Wie beim inkrementellen Lademuster ist es nicht erforderlich, die Delta-Tabelle zu partitionieren. Eine häufige Tabellenwartung ist jedoch unerlässlich, um sicherzustellen, dass die Anzahl der Parquet-Dateien und Zeilengruppen innerhalb der im Direct Lake-Übersichtsartikel angegebenen Schutzschienengrenzen liegt. Mit anderen Worten, vergessen Sie nicht, Spark Optimize regelmäßig auszuführen, z. B. täglich oder sogar häufiger. Spark Optimize wird im nächsten Abschnitt erneut behandelt.

Wartung von Delta-Tabellen

Wichtige Wartungsaufgaben umfassen das Aufräumen und die Optimierung von Delta-Tabellen. Um Wartungsoperationen zu automatisieren, verwenden Sie die Lakehouse-APIs, wie in der Dokumentation Lakehouse verwalten mit Microsoft Fabric REST API erklärt.

Staubsaugen

Das Staubsaugen entfernt Parquet-Dateien, die nicht mehr in der aktuellen Delta-Commit-Version enthalten sind und älter als eine festgelegte Aufbewahrungsschwelle sind. Das Entfernen dieser Parkettdateien wirkt sich nicht auf die Direct Lake-Leistung aus, da Direct Lake nur die Parkettdateien lädt, die sich in der aktuellen Commit-Version befinden. Wenn Sie VACUUM täglich mit den Standardwerten ausführen, werden die Delta-Commit-Versionen der letzten sieben Tage für Zeitreisen beibehalten.

Spark-Optimierung

Die Delta-Tabellenoptimierung führt mehrere kleine Parkettdateien in weniger große Dateien zusammen. Die laufende Optimierung ersetzt bestehende Parquet-Dateien, was die entsprechenden Spaltensegmente im Speicher ungültig macht und Direct Lake dazu zwingt, die betroffenen Daten bei der nächsten Abfrage neu zu transkodieren – eine kurzfristige Kaltzustandsstrafe. Die resultierenden weniger, größeren und einheitlicheren Segmente verbessern jedoch die langfristige Abfrageleistung. Gleichen Sie diese Kompromisse aus, indem Sie selten optimieren, wie z. B. über die Wochenenden oder am Ende des Monats. Optimieren Sie häufiger, wenn sich kleine Parquet-Dateien schnell ansammeln (hochfrequente kleine Updates), um zu gewährleisten, dass die Delta-Tabelle innerhalb der Grenzwerte bleibt.

Die Partitionierung kann dazu beitragen, den Optimierungseffekt auf die inkrementelle Rahmenbildung zu minimieren, da die Partitionierung die Daten effektiv anordnet. Zum Beispiel beschränkt die Partitionierung einer großen Delta-Tabelle auf Basis einer Spalte mit niedriger Kardinalität date_key die wöchentliche Wartung auf maximal sieben Partitionen. Die Delta-Tabelle behält den Großteil der bestehenden Parquet-Dateien bei. Direct Lake muss nur sieben Tage an Daten neu laden.

Analysieren von Delta-Tabellenaktualisierungen

Verwenden Sie Delta Analyzer oder ähnliche Tools, um zu untersuchen, wie Delta-Tabellenaktualisierungen sich auf Parkettdateien und Zeilengruppen auswirken. Mit Delta Analyzer können Sie die Entwicklung von Parkettdateien, Zeilengruppen, Spaltenblöcken und Spalten als Reaktion auf Anfüge-, Aktualisierungs- und Löschvorgänge nachverfolgen. Delta Analyzer ist als eigenständiges Jupyter-Notizbuch verfügbar. Sie ist auch in der Bibliothek für semantische Verknüpfungslabore verfügbar. In den folgenden Abschnitten werden semantische Verknüpfungslabore verwendet. Diese Bibliothek lässt sich einfach in einem Notizbuch installieren, indem man den Befehl %pip install semantic-link-labs verwendet.

Zeilengruppengröße

Die ideale Zeilengruppengröße für Direct-Lake-semantische Modelle liegt zwischen 1 und 16 Millionen Zeilen, aber Fabric könnte größere Zeilengruppengrößen für große Tabellen verwenden, wenn die Daten komprimierbar sind. Im Allgemeinen solltest du die Standardgröße der Zeilengruppe nicht ändern. Lass Fabric das Delta-Tabellenlayout verwalten. Es ist jedoch ratsam, das noch einmal zu überprüfen.

Der folgende Python-Code kann als Ausgangspunkt dienen, um die Zeilengruppengrößen und andere Details einer Delta-Tabelle in einem Fabric-Notizbuch verbundenen Lakehouse zu analysieren. Die folgende Tabelle zeigt die Ausgabe einer Beispieltabelle mit 1 Milliarden Zeilen.

import sempy_labs as labs
from IPython.display import HTML
from IPython.display import clear_output

table_name = "<Provide your table name>"

# Load the Delta table and run Delta Analyzer
df = spark.read.format("delta").load(f"Tables/{table_name}")
da_results = labs.delta_analyzer(table_name)

# Display the table summary in an HTML table.
clear_output()

df1 = da_results['Summary'].iloc[0]

html_table = "<table border='1'><tr><th>Column Name</th><th>{table_name}</th></tr>"
for column in da_results['Summary'].columns:
    html_table += f"<tr><td>{column}</td><td>{df1[column]}</td></tr>"
html_table += "</table>"

display(HTML(html_table))

Ausgabe:

Die Delta Analyzer-Zusammenfassung zeigt eine durchschnittliche Zeilengruppengröße von ca. 40 Millionen Zeilen an. Diese Größe ist größer als die empfohlene maximale Reihengruppengröße von 16 Millionen Reihen. Glücklicherweise verursacht die größere Reihengruppe keine größeren Probleme für Direct Lake. Größere Zeilengruppen erleichtern durchgehende Segmentierungsaufträge mit minimalem Aufwand in der Speicher-Engine. Umgekehrt können kleine Zeilengruppen, also deutlich unter 1 Million Zeilen, Performance-Probleme verursachen.

Im vorigen Beispiel ist wichtiger, dass Fabric die Zeilengruppen auf acht Parquet-Dateien verteilt hat. Diese Verteilung entspricht der Anzahl der Kerne auf der Fabric-Kapazität, um effiziente parallele Leseoperationen zu unterstützen. Wichtig ist auch, dass die Größen der einzelnen Zeilengruppen nicht zu weit vom Durchschnitt abweichen. Große Variationen können zu einer nichtuniformen VertiScan-Auslastung führen, was zu einer weniger optimalen Abfrageleistung führt.

Gleitende Fensteraktualisierungen

Zur Veranschaulichung simuliert das folgende Python-Codebeispiel ein rollierendes Fensterupdate. Der Code entfernt die Zeilen mit der ältesten DateID aus einer Delta-Beispieltabelle. Dann aktualisiert es die DateID dieser Zeilen und fügt sie als die aktuellsten Zeilen wieder in die Mustertabelle ein.

from pyspark.sql.functions import lit

table_name = "<Provide your table name>"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

# Get the rows of the oldest DateID.
rows_df = table_df[table_df["DateID"] == 20200101]
rows_df = spark.createDataFrame(rows_df.rdd, schema=rows_df.schema)

# Delete these rows from the table
table_df.createOrReplaceTempView(f"{table_name}_view")
spark.sql(f"DELETE From {table_name}_view WHERE DateID = '20200101'")

# Update the DateID and append the rows as new data
rows_df = rows_df.withColumn("DateID", lit(20250101))
rows_df.write.format("delta").mode("append").save(f"Tables/{table_name}")

Die get_delta_table_history Funktion in der Bibliothek für semantische Verknüpfungslabore kann dazu beitragen, die Auswirkungen dieses rollierenden Fensterupdates zu analysieren. Sehen Sie sich das folgende Python-Codebeispiel an. Siehe auch die Tabelle mit der Ausgabe nach dem Codeausschnitt.

import sempy_labs as labs
from IPython.display import HTML
from IPython.display import clear_output

table_name = "<Provide your table name>"
da_results = labs.get_delta_table_history(table_name)

# Create a single HTML table for specified columns
html_table = "<table border='1'>"
# Add data rows for specified columns
for index, row in da_results.iterrows():
    for column in ['Version', 'Operation', 'Operation Parameters', 'Operation Metrics']:
        if column == 'Version':
            html_table += f"<tr><td><b>Version</b></td><td><b>{row[column]}</b></td></tr>"
        else:
            html_table += f"<tr><td>{column}</td><td>{row[column]}</td></tr>"
html_table += "</table>"

# Display the HTML table
display(HTML(html_table))

Ausgabe:

Der obige Delta Analyzer-Verlauf zeigt, dass diese Delta-Tabelle jetzt die folgenden drei Versionen aufweist:

• Version 0: Dies ist die Originalversion mit acht Parkettdateien und 24 Zeilengruppen, wie im vorherigen Abschnitt erläutert.
• Version 1: Diese Version gibt den Löschvorgang wieder. Obwohl nur ein einzelner Tag an Daten (DateID = '20200101') aus der Stichprobentabelle mit fünf Jahren Verkaufstransaktionen entfernt wurde, waren alle acht Parquet-Dateien betroffen. Bei den Betriebsmetriken sind numRemovedFiles acht [Parquet-Dateien] und numAddedFiles sind 18 [Parquet-Dateien]. Das bedeutet, dass der Löschvorgang die ursprünglichen acht Parquet-Dateien durch 18 neue Parquet-Dateien ersetzte.
• Version 3: Die Vorgangsmetriken zeigen, dass eine weitere Parkettdatei mit 548.665 Zeilen zur Delta-Tabelle hinzugefügt wurde.

Nach dem Update des rollierenden Fensters umfasst die aktuellste Delta-Commit-Version 19 Parquet-Dateien und 21 Zeilengruppen mit Größen von 500 Tausend bis 50 Millionen Zeilen. Die Aktualisierung des rollierenden Fensters von 548.665 Zeilen hat Auswirkungen auf die gesamte Delta-Tabelle von 1 Milliarde Zeilen. Es ersetzte alle Parquet-Dateien und Row Groups. Es ist unwahrscheinlich, dass inkrementelles Framing in diesem Fall die Leistung im Kaltstart verbessert, und die erhöhte Variation der Zeilengruppengrößen wird vermutlich keinen Nutzen für die Leistung im Warmbetrieb bringen.

Delta-Tabellenaktualisierungen

Der folgende Python-Code aktualisiert eine Delta-Tabelle im Wesentlichen auf die gleiche Weise wie im vorherigen Abschnitt beschrieben. Auf der Oberfläche ändert die Aktualisierungsfunktion nur den DateID-Wert der vorhandenen Zeilen, die einer bestimmten DateID entsprechen. Parkettdateien sind jedoch unveränderlich und können nicht geändert werden. Unter der Oberfläche entfernt der Aktualisierungsvorgang vorhandene Parkettdateien und fügt neue Parkettdateien hinzu. Das Ergebnis und die Wirkung sind dieselben wie bei der Aktualisierung mit einem gleitenden Fenster.

from pyspark.sql.functions import col, when
from delta.tables import DeltaTable

# Load the Delta table
table_name = "<Provide your table name>"
delta_table = DeltaTable.forPath(spark, f"Tables/{table_name}")

# Define the condition and the column to update
condition = col("DateID") == 20200101
column_name = "DateID"
new_value = 20250101

# Update the DateID column based on the condition
delta_table.update(
    condition,
    {column_name: when(condition, new_value).otherwise(col(column_name))}
)

Partitionierte gleitende Fenster-Updates

Partitionierung kann helfen, die Auswirkungen von Tabellenupdates zu verringern. Es mag verlockend sein, die Datumsschlüssel zu verwenden, aber eine schnelle Kardinalitätsprüfung kann zeigen, dass diese Wahl nicht die beste ist. Zum Beispiel enthält die bisher diskutierte Beispieltabelle Verkaufstransaktionen der letzten fünf Jahre, was etwa 1.800 verschiedenen Datumswerten entspricht. Diese Kardinalität ist zu hoch. Die Partitionsspalte sollte weniger als 200 unterschiedliche Werte aufweisen.

column_name = 'DateID'
table_name = "<Provide your table name>"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

distinct_count = table_df.select(column_name).distinct().count()
print(f"The '{column_name}' column has {distinct_count} distinct values.")

if distinct_count <= 200:
    print(f"The '{column_name}' column is a good partitioning candidate.")
    table_df.write.format("delta").partitionBy(column_name).save(f"Tables/{table_name}_by_date_id")
    print(f"Table '{table_name}_by_date_id' partitioned and saved successfully.")
else:   
    print(f"The cardinality of the '{column_name}' column is possibly too high.")

Ausgabe:

The 'DateID' column has 1825 distinct values.
The cardinality of the 'DateID' column is possibly too high.

Wenn keine geeignete Trennspalte vorhanden ist, erstelle eine künstlich, indem du die Kardinalität einer bestehenden Spalte reduzierst. Der folgende Python-Code fügt eine Spalte "Monat" hinzu, indem die letzten beiden Ziffern der DateID entfernt werden. Dieser Prozess erzeugt 60 verschiedene Werte. Der Beispielcode speichert dann die Delta-Tabelle, die von der Spalte "Monat" partitioniert wird.

from pyspark.sql.functions import col, expr

column_name = 'DateID'
table_name = "sales_1"
table_df = spark.read.format("delta").load(f"Tables/{table_name}")

partition_column = 'Month'
partitioned_table = f"{table_name}_by_month"
table_df = table_df.withColumn(partition_column, expr(f"int({column_name} / 100)"))

distinct_count = table_df.select(partition_column).distinct().count()
print(f"The '{partition_column}' column has {distinct_count} distinct values.")

if distinct_count <= 200:
    print(f"The '{partition_column}' column is a good partitioning candidate.")
    table_df.write.format("delta").partitionBy(partition_column).save(f"Tables/{partitioned_table}")
    print(f"Table '{partitioned_table}' partitioned and saved successfully.")
else:   
    print(f"The cardinality of the '{partition_column}' column is possibly too high.")

Ausgabe:

The 'Month' column has 60 distinct values.
The 'Month' column is a good partitioning candidate.
Table 'sales_1_by_month' partitioned and saved successfully.

Die Delta Analyzer-Zusammenfassung zeigt jetzt, dass das Layout der Delta-Tabelle gut an Direct Lake ausgerichtet ist. Die durchschnittliche Zeilengruppengröße beträgt etwa 16 Millionen Zeilen, und die mittlere absolute Abweichung der Zeilengruppengrößen und damit der Segmentgrößen beträgt weniger als 1 Million Zeilen.

Nachdem ein Rolling Window-Update für eine partitionierte Beispieltabelle durchgeführt wurde, zeigt der Delta Analyzer-Verlauf, dass nur eine Parquet-Datei betroffen war. Siehe die folgende Ausgabetabelle. Version 2 enthält genau 16.445.655 Zeilen, die aus der alten Parkettdatei in eine Ersatzparkettdatei kopiert wurden, und Version 3 fügt eine neue Parkettdatei mit 548.665 Zeilen hinzu. Insgesamt muss Direct Lake nur ca. 17 Millionen Zeilen neu laden, eine beträchtliche Verbesserung gegenüber dem Laden von 1 Milliarde Zeilen ohne Partitionierung.

Nur-Anfügemuster gefolgt von Spark Optimize

Nur Anfügemuster wirken sich nicht auf vorhandene Parkettdateien aus. Sie funktionieren gut mit Direct Lake inkrementellem Framing. Vergessen Sie jedoch nicht, Ihre Delta-Tabellen zu optimieren, um Parquet-Dateien und Zeilengruppen zu konsolidieren, wie weiter oben in diesem Artikel beschrieben. Kleine und häufige Anfüge können Dateien schnell ansammeln und die Uniformität der Zeilengruppengrößen verfälschen.

Die folgende Ausgabe zeigt den Delta Analyzer-Verlauf für eine nicht partitionierte Tabelle im Vergleich zu einer partitionierten Tabelle. Der Verlauf umfasst sieben Anfüge und einen nachfolgenden Optimierungsvorgang .

Betrachtet man die Betriebsmetriken von Version 8, fusionierte die Optimierungsoperation für die nicht partitionierte Tabelle acht Parquet-Dateien, die etwa 1 GB Daten beeinflussten, während der Optimierungsbetrieb der partitionierten Tabelle sieben Parquet-Dateien nur etwa 25 MB Daten betraf. Daraus folgt, dass Direct Lake mit der partitionierten Tabelle besser abschneidet.

Überlegungen und Einschränkungen

Überlegungen und Einschränkungen zur Optimierung der Direct Lake-Leistung umfassen folgende Punkte:

• Vermeiden Sie zerstörerische Updatestrategien für große Delta-Tabellen, um inkrementelle Datenrahmen in Direct Lake beizubehalten.
• Du musst kleine Delta-Tabellen nicht für inkrementelles Framing optimieren.
• Ziel ist eine Zeilengruppengröße zwischen 1 und 16 Millionen Zeilen, um in Direct Lake Spaltensegmente mit 1 bis 16 Millionen Zeilen zu erstellen. Direct Lake bevorzugt große Säulensegmente.
• Vermeiden Sie Partitionsspalten mit hoher Kardinalität, da die Direct Lake-Transcodierung mit vielen kleinen Parkettdateien und Zeilengruppen weniger effizient ist als bei weniger großen Parkettdateien und Zeilengruppen.
• Aufgrund unvorhergesehener Nachfrage nach Rechen- und Speicherressourcen könnte ein semantisches Modell auf einen anderen Fabric-Clusterknoten im kalten Zustand neu laden.
• Direct Lake verwendet keine Delta\Parquet-Statistiken für das Überspringen von Zeilengruppen\Dateien, um das Datenladen zu optimieren.