Freigeben über

Grundlegendes zu Speicher für Direct Lake-Semantikmodelle

  • Artikel

In diesem Artikel werden Direct Lake-Speicherkonzepte vorgestellt. Er beschreibt Delta-Tabellen und Parquet-Dateien. Außerdem wird beschrieben, wie Sie Delta-Tabellen für Direct Lake-Semantikmodelle optimieren und warten können, um eine zuverlässige, schnelle Abfrageleistung zu erzielen.

Delta-Tabellen

Delta-Tabellen befinden sich in OneLake. Sie organisieren dateibasierte Daten in Zeilen und Spalten und sind für Microsoft Fabric-Compute-Engines wie Notebooks, Kusto sowie das Lakehouse und das Warehouse verfügbar. Sie können Delta-Tabellen mithilfe von Data Analysis Expressions (DAX), mehrdimensionalen Ausdrücken (Multidimensional Expressions, MDX), T-SQL (Transact-SQL), Spark SQL und sogar Python abfragen.

Hinweis

Delta – oder Delta Lake – ist ein Open-Source-Speicherformat. Dies bedeutet, dass Fabric auch Delta-Tabellen abfragen kann, die mit anderen Tools und von anderen Anbietern erstellt wurden.

Delta-Tabellen speichern ihre Daten in Parquet-Dateien. Diese Dateien sind in der Regel in einem Lakehouse gespeichert, das von einem Direct Lake-Semantikmodell zum Laden von Daten verwendet wird. Parquet-Dateien können jedoch auch extern gespeichert werden. Auf externe Parquet-Dateien kann mithilfe einer OneLake-Verknüpfung verwiesen werden, die auf einen bestimmten Speicherort zeigt, z. B. Azure Data Lake Storage (ADLS) Gen2, Amazon S3-Speicherkonten oder Dataverse. In fast allen Fällen greifen Compute-Engines auf die Parquet-Dateien zu, indem sie Delta-Tabellen abfragen. Direct Lake-Semantikmodelle laden Spaltendaten in der Regel jedoch mit einem als Transcodierung bezeichneten Prozess direkt aus optimierten Parquet-Dateien in OneLake.

Datenversionsverwaltung

Delta-Tabellen umfassen eine oder mehrere Parquet-Dateien. Diese Dateien werden von einer Reihe JSON-basierter Verknüpfungsdateien begleitet, die die Reihenfolge und Art jeder Parquet-Datei nachverfolgen, die einer Delta-Tabelle zugeordnet ist.

Es ist wichtig zu verstehen, dass die zugrunde liegenden Parquet-Dateien inkrementell sind. Daher der Name Delta, der sich auf die inkrementelle Datenänderung bezieht. Bei jedem Schreibvorgang in einer Delta-Tabelle (z. B. wenn Daten eingefügt, aktualisiert oder gelöscht werden) werden neue Parquet-Dateien erstellt, die die Datenänderungen als Version darstellen. Parquet-Dateien sind folglich unveränderlich, d. h. sie werden nie geändert. Aus diesem Grund ist es möglich, dass Daten in einer Reihe von Parquet-Dateien für eine Delta-Tabelle mehrmals dupliziert werden. Das Delta-Framework verwendet Verknüpfungsdateien, um zu bestimmen, welche physischen Parquet-Dateien erforderlich sind, um das richtige Abfrageergebnis zu erzeugen.

In diesem Artikel wird das folgende einfache Beispiel einer Delta-Tabelle verwendet, um verschiedene Datenänderungsvorgänge zu erläutern. Die Tabelle enthält zwei Spalten und speichert drei Zeilen.

ProductID StockOnHand
H 1
b 2
K 3

Die Daten der Delta-Tabelle werden in einer einzigen Parquet-Datei gespeichert, die alle Daten enthält, und es gibt eine einzelne Verknüpfungsdatei, die Metadaten zum Zeitpunkt des Einfügens (Anfügens) der Daten enthält.

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Verknüpfungsdatei 1:
    • Enthält den Zeitstempel der Erstellung von Parquet file 1 und zeichnet auf, dass Daten angefügt wurden.

Einfügevorgänge

Folgendes geschieht bei einem Einfügevorgang: Eine neue Zeile für das Produkt C mit einem Lagerbestand (StockOnHand-Wert) von 4 wird eingefügt. Diese Vorgänge führen zur Erstellung einer neuen Parquet-Datei und einer neuen Verknüpfungsdatei, sodass jetzt zwei Parquet-Dateien und zwei Verknüpfungsdateien vorhanden sind.

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-Datei 2:
    • ProductID: D
    • StockOnHand: 4
  • Verknüpfungsdatei 1:
    • Enthält den Zeitstempel der Erstellung von Parquet file 1 und zeichnet auf, dass Daten angefügt wurden.
  • Verknüpfungsdatei 2:
    • Enthält den Zeitstempel der Erstellung von Parquet file 2 und zeichnet auf, dass Daten angefügt wurden.

An diesem Punkt gibt eine Abfrage der Delta-Tabelle das folgende Ergebnis zurück. Es spielt keine Rolle, dass das Ergebnis aus mehreren Parquet-Dateien stammt.

ProductID StockOnHand
H 1
b 2
K 3
D 4

Bei jedem nachfolgenden Einfügevorgang werden neue Parquet-Dateien und Verknüpfungsdateien erstellt. Dies bedeutet, dass die Anzahl der Parquet- und Verknüpfungsdateien mit jedem Einfügevorgang zunimmt.

Vorgänge aktualisieren

Folgendes geschieht bei einem Aktualisierungsvorgang: In der Zeile für das Produkt D wird der StockOnHand-Wert in 10 geändert. Diese Vorgänge führen zur Erstellung einer neuen Parquet-Datei und einer neuen Verknüpfungsdatei, sodass jetzt drei Parquet-Dateien und drei Verknüpfungsdateien vorhanden sind.

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-Datei 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet-Datei 3:
    • ProductID: C
    • StockOnHand: 10
  • Verknüpfungsdatei 1:
    • Enthält den Zeitstempel der Erstellung von Parquet file 1 und zeichnet auf, dass Daten angefügt wurden.
  • Verknüpfungsdatei 2:
    • Enthält den Zeitstempel der Erstellung von Parquet file 2 und zeichnet auf, dass Daten angefügt wurden.
  • Verknüpfungsdatei 3:
    • Enthält den Zeitstempel der Erstellung von Parquet file 3 und zeichnet auf, dass Daten aktualisiert wurden.

An diesem Punkt gibt eine Abfrage der Delta-Tabelle das folgende Ergebnis zurück.

ProductID StockOnHand
H 1
b 2
K 10
D 4

Daten für das Produkt C sind jetzt in mehreren Parquet-Dateien vorhanden. Abfragen der Delta-Tabelle kombinieren jedoch die Verknüpfungsdateien, um zu bestimmen, welche Daten verwendet werden sollen, um das richtige Ergebnis zu liefern.

Vorgänge löschen

Folgendes geschieht bei einem Löschvorgang: Die Zeile für das Produkt B wird gelöscht. Dieser Vorgang führt zur Erstellung einer neuen Parquet-Datei und einer neuen Verknüpfungsdatei, sodass jetzt vier Parquet-Dateien und vier Verknüpfungsdateien vorhanden sind.

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-Datei 2:
    • ProductID: D
    • StockOnHand: 4
  • Parquet-Datei 3:
    • ProductID: C
    • StockOnHand: 10
  • Parquet-Datei 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Verknüpfungsdatei 1:
    • Enthält den Zeitstempel der Erstellung von Parquet file 1 und zeichnet auf, dass Daten angefügt wurden.
  • Verknüpfungsdatei 2:
    • Enthält den Zeitstempel der Erstellung von Parquet file 2 und zeichnet auf, dass Daten angefügt wurden.
  • Verknüpfungsdatei 3:
    • Enthält den Zeitstempel der Erstellung von Parquet file 3 und zeichnet auf, dass Daten aktualisiert wurden.
  • Verknüpfungsdatei 4:
    • Enthält den Zeitstempel der Erstellung von Parquet file 4 und zeichnet auf, dass Daten gelöscht wurden.

Beachten Sie, dass Parquet file 4 keine Daten mehr für das Produkt B enthält, aber Daten für alle anderen Zeilen in der Tabelle.

An diesem Punkt gibt eine Abfrage der Delta-Tabelle das folgende Ergebnis zurück.

ProductID StockOnHand
H 1
K 10
D 4

Hinweis

Dieses Beispiel ist einfach, da es sich um eine kleine Tabelle, wenige Vorgänge und geringfügige Änderungen handelt. Große Tabellen mit vielen Schreibvorgängen und vielen Datenzeilen generieren mehr als eine Parquet-Datei pro Version.

Wichtig

Je nachdem, wie Sie Ihre Delta-Tabellen definieren und wie häufig Datenänderungsvorgänge stattfinden, kann dies zu einer großen Anzahl von Parquet-Dateien führen. Beachten Sie, dass jede Fabric-Kapazitätslizenz über Schutzmaßnahmen verfügt. Wenn die Anzahl von Parquet-Dateien für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer geringeren Abfrageleistung bzw. langsameren Abfragen führen kann.

Informationen zum Verwalten der Anzahl von Parquet-Dateien finden Sie weiter unten in diesem Artikel unter Wartung von Delta-Tabellen.

Delta Zeitreise

Verknüpfungsdateien ermöglichen Abfragen für einen früheren Stand (Zeitpunkt) der Daten. Diese Funktion wird als Delta-Zeitreise bezeichnet. Bei dem früheren Zeitpunkt kann es sich um einen Zeitstempel oder eine Version handeln.

Sehen Sie sich die folgenden Abfragebeispiele an.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Tipp

Sie können eine Tabelle auch mit der @-Kurzsyntax abfragen, um den Zeitstempel oder die Version als Teil des Tabellennamens anzugeben. Der Zeitstempel muss im Format yyyyMMddHHmmssSSS vorliegen. Sie können eine Version nach @ angeben, indem Sie der Version v voranstellen.

Hier sehen Sie die vorherigen Abfragebeispiele umgeschrieben mit der Kurzsyntax.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Wichtig

Tabellenversionen, auf die mit Zeitreisen zugegriffen werden kann, werden durch eine Kombination aus dem Aufbewahrungsschwellenwert für Transaktionsprotokolldateien und der Häufigkeit sowie der angegebenen Aufbewahrungsdauer für VACUUM-Vorgänge bestimmt (Informationen dazu finden Sie weiter unten im Abschnitt Wartung von Delta-Tabellen). Wenn Sie VACUUM täglich mit den Standardwerten ausführen, stehen Daten von sieben Tage für Zeitreisen zur Verfügung.

Framing

Framing ist ein Direct Lake-Vorgang, der die Version einer Delta-Tabelle festlegt, die zum Laden von Daten in eine Semantikmodellspalte verwendet werden soll. Ebenso wichtig ist, dass die Version auch bestimmt, was beim Laden von Daten ausgeschlossen werden soll.

Ein Framingvorgang fügt den Semantikmodelltabellen den Zeitstempel/die Version jeder Delta-Tabelle hinzu. Ab diesem Zeitpunkt wird der Zeitstempel/die Version des letzten Framingvorgangs verwendet, um zu bestimmen, welche Daten geladen werden sollen, wenn das Semantikmodell Daten aus einer Delta-Tabelle laden muss. Alle nachfolgenden Datenänderungen, die nach dem letzten Framingvorgang für die Delta-Tabelle vorgenommen werden, werden ignoriert (bis zum nächsten Framingvorgang).

Wichtig

Da ein Semantikmodell, für das das Framing verwendet wird, auf eine bestimmte Delta-Tabellenversion verweist, muss die Quelle die Delta-Tabellenversion bis zum Abschluss des Framings einer neuen Version beibehalten. Andernfalls treten Fehler auf, wenn das Modell auf die Delta-Tabellendateien zugreifen muss und diese bereinigt oder anderweitig von der Producerworkload gelöscht wurden.

Weitere Informationen zum Framing finden Sie unter Übersicht über Direct Lake.

Tabellenpartitionierung

Delta-Tabellen können partitioniert werden, sodass eine Teilmenge von Zeilen zusammen in einer einzigen Gruppe von Parquet-Dateien gespeichert wird. Partitionen können sowohl Abfragen als auch Schreibvorgänge beschleunigen.

Nehmen Sie als Beispiel eine Delta-Tabelle, die eine Milliarde Zeilen mit Umsatzdaten für einen Zeitraum von zwei Jahren enthält. Es ist zwar möglich, alle Daten in einer einzigen Gruppe von Parquet-Dateien zu speichern, dies ist bei einer solchen Datenmenge jedoch nicht optimal für Lese- und Schreibvorgänge. Stattdessen kann die Leistung verbessert werden, indem die Milliarde Datenzeilen auf mehrere Reihen von Parquet-Dateien verteilt werden.

Beim Einrichten der Tabellenpartitionierung muss ein Partitionsschlüssel definiert werden. Der Partitionsschlüssel bestimmt, welche Zeilen in welcher Reihe gespeichert werden. Bei Delta-Tabellen kann der Partitionsschlüssel basierend auf den unterschiedlichen Werten einer oder mehrerer festgelegter Spalten definiert werden, z. B. auf Grundlage der Spalte „Monat/Jahr“ einer Datumstabelle. In diesem Fall würden die Daten von zwei Jahren auf 24 Partitionen verteilt werden (2 Jahre x 12 Monate).

Fabric-Compute-Engines beachten Tabellenpartitionen nicht. Wenn sie neue Partitionsschlüsselwerte einfügen, werden automatisch neue Partitionen erstellt. In OneLake gibt es einen Unterordner für jeden eindeutigen Partitionsschlüsselwert, und in jedem Unterordner wird eine eigene Gruppe von Parquet-Dateien und Verknüpfungsdateien gespeichert. Mindestens eine Parquet-Datei und eine Verknüpfungsdatei müssen vorhanden sein, die aktuelle Anzahl von Dateien in jedem Unterordner kann jedoch variieren. Wenn Datenänderungsvorgänge durchgeführt werden, verwaltet jede Partition eine eigene Gruppe von Parquet- und Verknüpfungsdateien, um nachzuverfolgen, welche Daten für einen bestimmten Zeitstempel oder eine bestimmte Version zurückgegeben werden müssen.

Wenn eine Abfrage einer partitionierten Delta-Tabelle nach den Umsatzdaten der letzten drei Monate gefiltert wird, kann die Teilmenge der Parquet- und Verknüpfungsdateien, auf die zugegriffen werden muss, schnell identifiziert werden. Dadurch können viele Parquet-Dateien übersprungen werden, was zu einer besseren Leseleistung führt.

Abfragen, die nicht nach dem Partitionsschlüssel filtern, bieten jedoch nicht immer eine bessere Leistung. Dies kann der Fall sein, wenn eine Delta-Tabelle alle Daten in einer einzigen großen Gruppe von Parquet-Dateien speichert und Dateien oder Zeilengruppen fragmentiert sind. Obwohl es möglich ist, den Datenabruf aus mehreren Parquet-Dateien über mehrere Clusterknoten hinweg zu parallelisieren, können sich viele kleine Parquet-Dateien negativ auf die Datei-E/A auswirken und daher die Abfrageleistung beeinträchtigen. In den meisten Fällen sollte die Partitionierung von Delta-Tabellen daher vermieden werden, es sei denn, Schreibvorgänge oder ETL-Prozesse (Extrahieren, Transformieren und Laden) würden deutlich davon profitieren.

Die Partitionierung wirkt sich auch positiv auf Einfüge-, Aktualisierungs- und Löschvorgänge aus, da Dateiaktivitäten nur in Unterordnern stattfinden, die mit dem Partitionsschlüssel der geänderten bzw. gelöschten Zeilen übereinstimmen. Wenn beispielsweise ein Datenbatch in eine partitionierte Delta-Tabelle eingefügt wird, werden die Daten bewertet, um die im Batch vorhandenen Partitionsschlüsselwerte zu ermitteln. Die Daten werden dann nur an die relevanten Ordner für die Partitionen geleitet.

Wenn Sie verstehen, wie Delta-Tabellen Partitionen verwenden, können Sie optimale ETL-Szenarien entwerfen, die die Anzahl erforderlicher Schreibvorgänge beim Aktualisieren großer Delta-Tabellen reduzieren. Die Schreibleistung wird verbessert, indem die Anzahl und Größe der Parquet-Dateien, die neu erstellt werden müssen, reduziert wird. Bei einer großen Delta-Tabelle, die wie im obigen Beispiel beschrieben nach Monat/Jahr partitioniert ist, werden durch neue Daten nur der aktuellen Partition neue Parquet-Dateien hinzugefügt. Unterordner der vorherigen Kalendermonate bleiben unverändert. Wenn Daten früherer Kalendermonate geändert werden müssen, empfangen nur die relevanten Partitionsordner neue Partitions- und Verknüpfungsdateien.

Wichtig

Wenn eine Delta-Tabelle in erster Linie als Datenquelle für Semantikmodelle dient (und nachrangig als Datenquelle für andere Abfrageworkloads), empfiehlt es sich meist, eine Partitionierung zu vermeiden und stattdessen das Laden von Spalten in den Arbeitsspeicher zu optimieren.

Bei Direct Lake-Semantikmodellen oder dem SQL-Analyseendpunkt besteht die beste Möglichkeit zum Optimieren von Delta-Tabellenpartitionen darin, die Parquet-Dateien für jede Version einer Delta-Tabelle automatisch von Fabric verwalten zu lassen. Wenn Sie die Dateien von Fabric verwalten lassen, sollten Sie durch Parallelisierung eine hohe Abfrageleistung, möglicherweise jedoch nicht die beste Schreibleistung erzielen.

Wenn Sie die Leistung für Schreibvorgänge optimieren müssen, sollten Sie die Verwendung von Partitionen in Betracht ziehen, um Schreibvorgänge in Delta-Tabellen basierend auf dem Partitionsschlüssel zu optimieren. Beachten Sie jedoch, dass sich die übermäßige Partitionierung einer Delta-Tabelle negativ auf die Leseleistung auswirken kann. Aus diesem Grund wird empfohlen, die Lese- und Schreibleistung sorgfältig zu testen. Sie können beispielsweise mehrere Kopien derselben Delta-Tabelle mit unterschiedlichen Konfigurationen erstellen, um die Zeiten zu vergleichen.

Warnung

Wenn Sie nach einer Spalte mit hoher Kardinalität partitionieren, kann dies zu einer übermäßigen Anzahl von Parquet-Dateien führen. Beachten Sie, dass alle Fabric-Kapazitätslizenzen über Schutzmaßnahmen verfügen. Wenn die Anzahl von Parquet-Dateien für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer geringeren Abfrageleistung bzw. langsameren Abfragen führen kann.

Parquet-Dateien

Beim zugrunde liegenden Speicher für eine Delta-Tabelle handelt es sich um eine oder mehrere Parquet-Dateien. Das Parquet-Dateiformat wird in der Regel für Write Once, Read Many (WORM)-Anwendungen verwendet. Neue Parquet-Dateien werden bei jeder Änderung von Daten in einer Delta-Tabelle erstellt, unabhängig davon, ob es sich um einen Einfüge-, Aktualisierungs- oder Löschvorgang handelt.

Hinweis

Sie können mit einem Tool wie dem OneLake-Datei-Explorer auf Parquet-Dateien zugreifen, die Delta-Tabellen zugeordnet sind. Das Herunterladen, Kopieren oder Verschieben der Dateien an andere Ziele ist so einfach wie das Verschieben jeder anderen Datei. Es ist jedoch die Kombination aus Parquet-Dateien und JSON-basierten Verknüpfungsdateien, die es Compute-Engines ermöglicht, die Dateien als Delta-Tabelle abzufragen.

Parquet-Dateiformat

Das interne Format einer Parquet-Datei unterscheidet sich von anderen gängigen Datenspeicherformaten wie CSV, TSV, XMLA und JSON. Diese Formate organisieren Daten nach Zeilen, während Parquet Daten nach Spalten ordnet. Außerdem unterscheidet sich das Parquet-Dateiformat insofern von diesen Formaten, dass es Datenzeilen in einer oder mehreren Zeilengruppen organisiert.

Die interne Datenstruktur eines Power BI-Semantikmodells ist spaltenbasiert. Parquet-Dateien weisen daher viele Gemeinsamkeiten mit Power BI auf. Aufgrund dieser Ähnlichkeit kann ein Direct Lake-Semantikmodell Daten aus den Parquet-Dateien effizient direkt in den Arbeitsspeicher laden. Selbst sehr große Datenmengen können in Sekundenschnelle geladen werden. Vergleichen Sie diese Funktion mit der Aktualisierung eines Importsemantikmodells, bei der Blöcke oder Quelldaten abgerufen, dann verarbeitet, codiert und gespeichert und anschließend in den Arbeitsspeicher geladen werden müssen. Die Aktualisierung eines Importsemantikmodells kann zudem erhebliche Computekapazitäten (Arbeitsspeicher und CPU) verbrauchen und viel Zeit in Anspruch nehmen. Bei Delta-Tabellen erfolgt jedoch der Großteil der Datenvorbereitung für das direkte Laden in ein Semantikmodell beim Generieren der Parquet-Datei.

Speicherung von Daten in Parquet-Dateien

Sehen Sie sich die folgenden Beispieldaten an.

Datum ProductID StockOnHand
2024-09-16 A 10
2024-09-16 b 11
2024-09-17 A 13
…

Wenn diese Daten im Parquet-Dateiformat gespeichert werden, sehen sie in etwa wie folgt aus.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Daten werden komprimiert, indem allgemeine Werte durch Wörterbuchschlüssel ersetzt werden und eine Lauflängencodierung (Run Length Encoding, RLE) angewendet wird. Bei der Lauflängencodierung wird versucht, eine Reihe gleicher Werte in eine kleinere Darstellung zu komprimieren. Im folgenden Beispiel wird eine Wörterbuchzuordnung zwischen numerischen Schlüsseln und Werten im Header erstellt, und die kleineren Schlüsselwerte werden anstelle der Datenwerte verwendet.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Wenn das Direct Lake-Semantikmodell Daten zum Berechnen der Summe der nach ProductID gruppierten Spalte StockOnHand benötigt, sind nur das Wörterbuch und die Daten erforderlich, die den beiden Spalten zugeordnet sind. In großen Dateien, die viele Spalten enthalten, können erhebliche Teile der Parquet-Datei übersprungen werden, um den Lesevorgang zu beschleunigen.

Hinweis

Der Inhalt einer Parquet-Datei ist nicht lesbar und eignet sich daher nicht zum Öffnen in einem Text-Editor. Es gibt jedoch viele Open-Source-Tools, mit denen eine Parquet-Datei geöffnet und der Inhalt angezeigt werden kann. Mit diesen Tools können Sie auch die Metadaten überprüfen, z. B. die Anzahl von Zeilen und Zeilengruppen in einer Datei.

V-Order

Fabric unterstützt eine zusätzliche Optimierung namens V-Reihenfolge bzw. „V-Order“. „V-Reihenfolge“ optimiert die erforderliche Zeit für das Schreiben in das Parquet-Dateiformat. Wenn Sie „V-Reihenfolge“ anwenden, erhalten Sie eine kleinere Datei, die schneller gelesen werden kann. Diese Optimierung ist für Direct Lake-Semantikmodelle besonders relevant, da sie die Daten für das schnelle Laden in den Arbeitsspeicher vorbereitet und dadurch weniger Kapazitätsressourcen erfordert. Sie führt außerdem zu einer besseren Abfrageleistung, da weniger Arbeitsspeicher überprüft werden muss.

Delta-Tabellen, die von Fabric-Elementen wie Datenpipelines, Dataflows und Notebooks erstellt und geladen wurden, wenden „V-Reihenfolge“ automatisch an. Auf Parquet-Dateien, die in ein Fabric-Lakehouse hochgeladen werden oder auf die mit einer Verknüpfung verwiesen wird, wird diese Optimierung jedoch möglicherweise nicht angewendet. Nicht optimierte Parquet-Dateien können weiterhin gelesen werden, die Leseleistung ist aber wahrscheinlich geringer als bei einer entsprechenden Parquet-Datei, auf die „V-Reihenfolge“ angewendet wurde.

Hinweis

Parquet-Dateien, auf die „V-Reihenfolge“ angewendet wurde, entsprechen weiterhin dem Open-Source-Parquet-Dateiformat. Daher können sie von Nicht-Fabric-Tools gelesen werden.

Weitere Informationen finden Sie unter Delta Lake-Tabellenoptimierung und V-Reihenfolge.

Optimierung von Delta-Tabellen

In diesem Abschnitt werden verschiedene Themen zur Optimierung von Delta-Tabellen für Semantikmodelle beschrieben.

Datenvolumen

Obwohl Delta-Tabellen an Umfang zunehmen und so enorme Datenmengen speichern können, geben Fabric-Kapazitätsschutzmaßnahmen Grenzwerte für Semantikmodelle vor, die diese Tabellen abfragen. Wenn diese Grenzwerte überschritten werden, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer geringeren Abfrageleistung bzw. langsameren Abfragen führen kann.

Erwägen Sie daher, die Zeilenanzahl einer großen Faktentabelle zu beschränken, indem Sie die Granularität (Speichern zusammengefasster Daten) erhöhen, die Dimensionalität verringern oder weniger Verlaufsdaten speichern.

Stellen Sie außerdem sicher, dass V-Reihenfolge angewendet wird, da dies zu einer kleineren Datei führt, die schneller gelesen werden kann.

Spaltendatentyp

Versuchen Sie, die Kardinalität (Anzahl eindeutiger Werte) in allen Spalten jeder Delta-Tabelle zu reduzieren. Dies ist empfehlenswert, weil alle Spalten mithilfe der Hashcodierung komprimiert und gespeichert werden. Die Hashcodierung erfordert die Optimierung mittels „V-Reihenfolge“, um jedem eindeutigen Wert in der Spalte einen numerischen Bezeichner zuzuweisen. Es wird also der numerische Bezeichner gespeichert, was eine Hashsuche während der Speicherung und Abfrage erfordert.

Wenn Sie ungefähre numerische Datentypen verwenden (z. B. float und real), sollten Sie die Verwendung von Rundungswerten und einer geringeren Genauigkeit in Erwägung ziehen.

Unnötige Spalten

Wie jede andere Datentabelle sollten Delta-Tabellen nur Spalten speichern, die erforderlich sind. Im Kontext dieses Artikels sind dies die Spalten, die das Semantikmodell benötigt, es kann jedoch andere Analyseworkloads geben, die die Delta-Tabellen abfragen.

Zusätzlich zu Spalten, die Modellbeziehungen unterstützen, sollten Delta-Tabellen Spalten enthalten, die das Semantikmodell zum Filtern, Gruppieren, Sortieren und Zusammenfassen benötigt. Unnötige Spalten wirken sich zwar nicht auf die Abfrageleistung von Semantikmodellen aus (da sie nicht in den Arbeitsspeicher geladen werden), führen aber zu einer größeren Speichergröße und erfordern daher mehr Computeressourcen zum Laden und Verwalten.

Da Direct Lake-Semantikmodelle keine berechneten Spalten unterstützen, sollten Sie solche Spalten in den Delta-Tabellen materialisieren. Beachten Sie, dass dieser Entwurfsansatz ein Antimuster für Import- und DirectQuery-Semantikmodelle ist. Wenn Sie beispielsweise die Spalten FirstName und LastName haben und eine Spalte FullName benötigen, materialisieren Sie die Werte für diese Spalte, wenn Sie Zeilen in die Delta-Tabelle einfügen.

Beachten Sie, dass einige Zusammenfassungen des Semantikmodells möglicherweise von mehr als einer Spalte abhängen. Um beispielsweise den Umsatz zu berechnen, summiert das Measure im Modell das Produkt von zwei Spalten: Quantity und Price. Wenn keine dieser Spalten unabhängig verwendet wird, wäre es effizienter, die Umsatzberechnung als einzelne Spalte zu materialisieren, als die Komponentenwerte in separaten Spalten zu speichern.

Zeilengruppengröße

Intern organisiert eine Parquet-Datei Datenzeilen in mehreren Zeilengruppen innerhalb jeder Datei. Beispielsweise kann eine Parquet-Datei, die 30.000 Zeilen enthält, diese Zeilen in drei Zeilengruppen mit jeweils 10.000 Zeilen aufteilen.

Die Anzahl von Zeilen in einer Zeilengruppe bestimmt, wie schnell Direct Lake die Daten lesen kann. Eine höhere Anzahl von Zeilengruppen mit weniger Zeilen wirkt sich aufgrund der übermäßigen E/A-Vorgänge wahrscheinlich negativ auf das Laden von Spaltendaten in ein Semantikmodell aus.

Im Allgemeinen wird davon abgeraten, die standardmäßige Zeilengruppengröße zu ändern. Bei großen Delta-Tabellen können Sie jedoch eine Änderung der Zeilengruppengröße in Erwägung ziehen. Testen Sie die Lese- und Schreibleistung sorgfältig. Sie können beispielsweise mehrere Kopien derselben Delta-Tabelle mit unterschiedlichen Konfigurationen erstellen, um die Zeiten zu vergleichen.

Wichtig

Beachten Sie, dass alle Fabric-Kapazitätslizenzen über Schutzmaßnahmen verfügen. Wenn die Anzahl von Zeilengruppen für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer geringeren Abfrageleistung bzw. langsameren Abfragen führen kann.

Wartung von Delta-Tabellen

Im Laufe der Zeit sammeln sich Delta-Tabellenversionen an, wenn Schreibvorgänge stattfinden. Dies kann irgendwann zu einer spürbaren Beeinträchtigung der Leseleistung führen. Schlimmer noch: Wenn die Anzahl von Parquet-Dateien pro Tabelle, die Anzahl von Zeilengruppen pro Tabelle oder die Anzahl von Zeilen pro Tabelle die Schutzmaßnahmen für Ihre Kapazität überschreitet, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer geringeren Abfrageleistung bzw. langsameren Abfragen führen kann. Daher ist es wichtig, dass Sie Delta-Tabellen regelmäßig warten.

OPTIMIZE

Sie können eine Delta-Tabelle mithilfe von OPTIMIZE optimieren, um kleinere Dateien in größeren Dateien zusammenzufügen. Sie können auch die WHERE-Klausel auf eine gefilterte Teilmenge von Zeilen festlegen, die einem bestimmten Partitionsprädikat entsprechen. Es werden nur Filter mit Partitionsschlüsseln unterstützt. Der Befehl OPTIMIZE kann auch „V-Reihenfolge“ anwenden, um die Parquet-Dateien zu komprimieren und erneut zu generieren.

Es wird empfohlen, diesen Befehl für große, häufig aktualisierte Delta-Tabellen regelmäßig auszuführen, z. B. täglich nach Abschluss des ETL-Prozesses. Finden Sie einen Kompromiss zwischen einer besseren Abfrageleistung und den zum Optimieren der Tabelle erforderlichen Kosten für die Ressourcennutzung.

VACUUM

Sie können VACUUM verwenden, um Dateien zu entfernen, auf die nicht mehr verwiesen wird und/oder die älter als ein festgelegter Aufbewahrungsschwellenwert sind. Achten Sie darauf, einen geeigneten Aufbewahrungszeitraum festzulegen. Andernfalls könnte die Zeitreise zu einer Version, die älter als der in Semantikmodelltabellen hinzugefügte Frame ist, nicht mehr möglich sein.

Wichtig

Da ein Semantikmodell, für das das Framing verwendet wird, auf eine bestimmte Delta-Tabellenversion verweist, muss die Quelle die Delta-Tabellenversion bis zum Abschluss des Framings einer neuen Version beibehalten. Andernfalls treten Fehler auf, wenn das Modell auf die Delta-Tabellendateien zugreifen muss und diese bereinigt oder anderweitig von der Producerworkload gelöscht wurden.

REORG TABLE

Sie können REORG TABLE verwenden, um eine Delta-Tabelle neu zu organisieren, indem Sie Dateien zum endgültigen Löschen vorläufig gelöschter Daten erneut generieren (z. B. wenn Sie eine Spalte mit ALTER TABLE DROP COLUMN verwerfen).

Automatisieren der Tabellenwartung

Tabellenwartungsvorgänge können mithilfe der Lakehouse-API automatisiert werden. Weitere Informationen finden Sie unter Verwalten der Lakehouse-Instanz per Microsoft Fabric-REST-API.

Tipp

Sie können auch das Lakehouse-Feature „Tabellenwartung“ im Fabric-Portal verwenden, um die Verwaltung Ihrer Delta-Tabellen zu vereinfachen.

Zugehöriger Inhalt