Freigeben über

Einführung in die Speicherverwaltung für Direct Lake-Semantikmodelle

  • Artikel

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

Delta-Tabellen

Delta-Tabellen sind in OneLake vorhanden. Sie organisieren dateibasierte Daten in Zeilen und Spalten und sind für Microsoft Fabric-Verarbeitungseinheiten wie Notizbücher, Kustosowie das Lakehouse und Warehouseverfügbar. Sie können Delta-Tabellen abfragen, indem Sie Data Analysis Expressions (DAX), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL und sogar Python verwenden.

Anmerkung

Delta –oder Delta Lake– ist ein Open-Source-Speicherformat. Dies bedeutet, dass Fabric auch Delta-Tabellen abfragen kann, die von anderen Tools und 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 Rechenmodule 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 von JSON-basierten Linkdateien begleitet, die die Reihenfolge und Art jeder Parkettdatei nachverfolgen, die einer Delta-Tabelle zugeordnet ist.

Es ist wichtig zu verstehen, dass die zugrunde liegenden Parquet-Dateien in ihrer Natur inkrementell sind. Daher der Name Delta als Verweis auf die inkrementelle Datenmodifikation. Jedes Mal, wenn ein Schreibvorgang in eine Delta-Tabelle stattfindet , z. B. beim Einfügen, Aktualisieren oder Löschen von Daten, werden neue Parkettdateien erstellt, die die Datenänderungen als Versiondarstellen. Parkettdateien sind daher unveränderlich, was bedeutet, dass sie niemals verändert werden. Es ist daher möglich, dass Daten in einer Reihe von Parkettdateien für eine Delta-Tabelle mehrmals dupliziert werden. Das Delta-Framework basiert auf Verknüpfungsdateien, um zu bestimmen, welche physischen Parkettdateien erforderlich sind, um das richtige Abfrageergebnis zu erzeugen.

Betrachten Sie ein einfaches Beispiel für eine Delta-Tabelle, die in diesem Artikel verwendet wird, um verschiedene Datenänderungsvorgänge zu erläutern. Die Tabelle enthält zwei Spalten und speichert drei Zeilen.

ProduktID StockOnHand
A 1
B 2
C 3

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

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Linkdatei 1:
    • Enthält den Zeitstempel, als Parquet file 1 erstellt wurde, und zeichnet auf, dass Daten hinzugefügt wurden.

Einfügungsvorgänge

Überlegen Sie, was passiert, wenn ein Einfügevorgang auftritt: Eine neue Zeile für produkt C mit einem Lagerbestand 4 eingefügt wird. Diese Vorgänge führen zur Erstellung einer neuen Parkettdatei und Linkdatei, so dass es jetzt zwei Parkettdateien und zwei Verknüpfungsdateien gibt.

  • Parquet-Datei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-Datei 2:
    • ProductID: D
    • StockOnHand: 4
  • Linkdatei 1:
    • Enthält den Zeitstempel, als Parquet file 1 erstellt wurde, und zeichnet auf, dass Daten hinzugefügt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, als Parquet file 2 erstellt wurde, und dokumentiert, dass Daten hinzugefü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
A 1
B 2
C 3
D 4

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

Aktualisierungsvorgänge

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 Parkettdatei und Linkdatei, so dass es jetzt drei Parkettdateien und drei Linkdateien gibt.

  • 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
  • Linkdatei 1:
    • Enthält den Zeitstempel der Erstellung von Parquet file 1 und verzeichnet, dass Daten angehängt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, als Parquet file 2 erstellt wurde, und hält fest, dass Daten angehängt wurden.
  • Linkdatei 3:
    • Enthält den Zeitstempel, zu dem Parquet file 3 erstellt wurde, und zeichnet auf, dass Daten aktualisiert wurden.

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

ProductID StockOnHand
A 1
B 2
C 10
D 4

Daten für 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 bereitzustellen.

Löschvorgänge

Berücksichtigen Sie nun, was passiert, wenn ein Löschvorgang auftritt: Die Zeile für produkt-B wird gelöscht. Dieser Vorgang führt zu einer neuen Parkettdatei und Linkdatei, so dass es jetzt vier Parkettdateien und vier Linkdateien gibt.

  • 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
  • Linkdatei 1:
    • Enthält den Zeitstempel, als Parquet file 1 erstellt wurde, und protokolliert, dass Daten hinzugefügt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, als Parquet file 2 erstellt wurde, und verzeichnet, dass Daten angefügt wurden.
  • Linkdatei 3:
    • Enthält den Zeitstempel, zu dem Parquet file 3 erstellt wurde, und protokolliert, dass die Daten aktualisiert wurden.
  • Linkdatei 4:
    • Enthält den Zeitstempel, zu dem Parquet file 4 erstellt wurde, und dokumentiert, dass Daten gelöscht wurden.

Beachten Sie, dass Parquet file 4 keine Daten mehr für Produkt-Benthält, sie enthält jedoch 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
A 1
C 10
D 4

Anmerkung

Dieses Beispiel ist einfach, da es eine kleine Tabelle, nur wenige Vorgänge und nur geringfügige Änderungen umfasst. Große Tabellen, bei denen viele Schreibvorgänge stattfinden und die viele Zeilen mit Daten enthalten, generieren pro Version mehr als eine Parquet-Datei.

Wichtig

Je nachdem, wie Sie Ihre Delta-Tabellen und die Häufigkeit von Datenänderungsvorgängen definieren, kann dies zu vielen Parkettdateien 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 später in diesem Artikel unter Wartung von Delta-Tabellen.

Delta-Zeitreise

Verknüpfungsdateien ermöglichen das Abfragen von Daten ab einem früheren Zeitpunkt. Diese Fähigkeit wird als Delta-Zeitreisebezeichnet. Der frühere Zeitpunkt könnte ein Zeitstempel oder eine Version sein.

Betrachten Sie die folgenden Abfragebeispiele.

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 mithilfe der @ Kurzhandsyntax abfragen, um den Zeitstempel oder die Version als Teil des Tabellennamens anzugeben. Der Zeitstempel muss im yyyyMMddHHmmssSSS-Format vorliegen. Sie können eine Version nach @ angeben, indem Sie der Version eine v voranstellen.

Dies sind die vorherigen Abfragebeispiele, die mit Kurzhandsyntax umgeschrieben wurden.

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 und der angegebenen Aufbewahrung für VAKUUM-Vorgänge bestimmt (weiter unten im Abschnitt Delta-Tabellenwartung). Wenn Sie VACUUM täglich mit den Standardwerten ausführen, stehen sieben Tage Daten für Zeitreisen zur Verfügung.

Framing

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

Ein Rahmenvorgang stempelt den Zeitstempel/die Version jeder Delta-Tabelle in die Semantikmodelltabellen. Ab diesem Zeitpunkt verwendet das semantische Modell den dem letzten Framingvorgang zugeordneten Zeitstempel/die Version, wenn es Daten aus einer Delta-Tabelle laden muss, um zu bestimmen, welche Daten geladen werden sollen. Alle nachfolgenden Datenänderungen, die seit dem letzten Framingvorgang für die Delta-Tabelle auftreten, werden ignoriert (bis zum nächsten Rahmenvorgang).

Wichtig

Da ein eingefasstes Semantikmodell auf eine bestimmte Delta-Tabellenversion verweist, muss die Quelle sicherstellen, dass die Delta-Tabellenversion beibehalten wird, bis die Einfassung einer neuen Version abgeschlossen ist. 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 in einer einzigen Gruppe von Parkettdateien gespeichert wird. Partitionen können Abfragen sowie Schreibvorgänge beschleunigen.

Betrachten Sie eine Delta-Tabelle mit einer Milliarde Umsatzdaten für einen Zeitraum von zwei Jahren. Es ist zwar möglich, alle Daten in einer einzigen Reihe von Parkettdateien zu speichern, für dieses Datenvolumen ist es jedoch nicht optimal für Lese- und Schreibvorgänge. Stattdessen kann die Leistung verbessert werden, indem die Milliarden Zeilen von Daten über mehrere Serien von Parquet-Dateien verteilt werden.

Ein Partitionsschlüssel muss beim Einrichten der Tabellenpartitionierung definiert werden. Der Partitionsschlüssel bestimmt, welche Zeilen in welcher Datenreihe gespeichert werden sollen. Bei Delta-Tabellen kann der Partitionsschlüssel basierend auf den unterschiedlichen Werten einer angegebenen Spalte (oder Spalten) definiert werden, z. B. einer Monats-/Jahresspalte einer Datumstabelle. In diesem Fall würden zwei Jahre Daten über 24 Partitionen verteilt (2 Jahre x 12 Monate).

Fabric-Computemodule kennen keine Tabellenpartitionen. Beim Einfügen neuer Partitionsschlüsselwerte werden automatisch neue Partitionen erstellt. In OneLake finden Sie einen Unterordner für jeden eindeutigen Partitionsschlüsselwert, und jeder Unterordner speichert einen eigenen Satz von Parkettdateien und Verknüpfungsdateien. Mindestens eine Parkettdatei und eine Verknüpfungsdatei müssen vorhanden sein, aber die tatsächliche Anzahl der Dateien in jedem Unterordner kann variieren. Da Datenänderungsvorgänge durchgeführt werden, verwaltet jede Partition eine eigene Reihe von Parkettdateien und verknüpft Dateien, um nachzuverfolgen, was für einen bestimmten Zeitstempel oder eine bestimmte Version zurückgegeben werden soll.

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

Abfragen, die nicht auf den Partitionsschlüssel filtern, werden jedoch möglicherweise nicht immer besser ausgeführt. Dies kann der Fall sein, wenn eine Delta-Tabelle alle Daten in einem einzigen großen Satz von Parkettdateien speichert und eine Datei- oder Zeilengruppenfragmentierung vorhanden ist. Obwohl es möglich ist, den Datenabruf aus mehreren Parkettdateien über mehrere Clusterknoten hinweg zu parallelisieren, können sich viele kleine Parkettdateien negativ auf die Datei-E/A auswirken und daher die Abfrageleistung beeinträchtigen. Aus diesem Grund empfiehlt es sich, die Partitionierung von Delta-Tabellen in den meisten Fällen zu vermeiden – es sei denn, schreibvorgänge oder extrahieren, transformieren und laden (ETL)-Prozesse würden deutlich davon profitieren.

Auch Einfüge-, Aktualisierungs- und Löschvorgänge profitieren von den Vorteilen der Partitionierung, da Dateiaktivitäten nur in Unterordnern stattfinden, die dem Partitionsschlüssel der geänderten oder gelöschten Zeilen entsprechen. Wenn beispielsweise ein Datenbatch in eine partitionierte Delta-Tabelle eingefügt wird, werden die Daten bewertet, um zu bestimmen, welche Partitionsschlüsselwerte im Batch vorhanden sind. Die Daten werden dann nur an die relevanten Ordner für die Partitionen weitergeleitet.

Wenn Sie verstehen, wie Delta-Tabellen Partitionen verwenden, können Sie optimale ETL-Szenarien entwerfen, die die Schreibvorgänge reduzieren, die beim Aktualisieren großer Delta-Tabellen ausgeführt werden müssen. Die Schreibleistung wird verbessert, indem die Anzahl und Größe der Parquet-Dateien reduziert wird, die neu erstellt werden müssen. Für eine große Delta-Tabelle, die nach Monat/Jahr partitioniert wird, wie im vorherigen Beispiel beschrieben, fügen neue Daten nur neue Parquet-Dateien zur neuesten Partition hinzu. Unterordner der vorherigen Kalendermonate bleiben unverändert. Wenn Daten früherer Kalendermonate geändert werden müssen, erhalten nur die relevanten Partitionsordner neue Partitions- und Verknüpfungsdateien.

Wichtig

Wenn der Hauptzweck einer Delta-Tabelle darin besteht, als Datenquelle für semantische Modelle (und zweitens für andere Abfrage-Workloads) zu dienen, sollte man in der Regel Partitionierungen vermeiden, um stattdessen die Optimierung des Ladens der -Spalten in den Speicherzu priorisieren.

Für Direct Lake-Semantikmodelle oder den SQL Analytics-Endpunktbesteht die beste Methode zur Optimierung von Delta-Tabellenpartitionen darin, Fabric die Parquet-Dateien für jede Version einer Delta-Tabelle automatisch verwalten zu lassen. Das Verlassen der Verwaltung auf Fabric sollte zu einer hohen Abfrageleistung durch Parallelisierung führen, bietet jedoch möglicherweise nicht unbedingt die beste Schreibleistung.

Wenn Sie schreibvorgänge optimieren müssen, sollten Sie Partitionen verwenden, um Schreibvorgänge basierend auf dem Partitionsschlüssel in Delta-Tabellen zu optimieren. Beachten Sie jedoch, dass sich die Überpartitionierung einer Delta-Tabelle negativ auf die Leseleistung auswirken kann. Aus diesem Grund empfehlen wir, die Lese- und Schreibleistung sorgfältig zu testen, indem Sie vielleicht 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 langsameren Abfrageleistung führen kann.

Parquet-Dateien

Der zugrunde liegende Speicher für eine Delta-Tabelle besteht aus einem oder mehreren Parquet-Dateien. Das Parquet-Dateiformat wird in der Regel für WORM-Anwendungen (Write Once Read Many) verwendet. Neue Parkettdateien werden jedes Mal erstellt, wenn Daten in einer Delta-Tabelle geändert werden, ob durch einen Einfüge-, Aktualisierungs- oder Löschvorgang.

Anmerkung

Sie können mit einem Tool wie dem OneLake-Datei-Explorer auf Parquet-Dateien zugreifen, die Delta-Tabellen zugeordnet sind. Dateien können heruntergeladen, kopiert oder an andere Ziele verschoben werden, so einfach wie das Verschieben anderer Dateien. Es ist jedoch die Kombination aus Parquet-Dateien und den JSON-basierten Verknüpfungsdateien, die es Rechenmodulen ermöglichen, Abfragen gegen die Dateien als Delta-Tabelle auszuführen.

Parquet-Dateiformat

Das interne Format einer Parkettdatei unterscheidet sich von anderen gängigen Datenspeicherformaten wie CSV, TSV, XMLA und JSON. Diese Formate organisieren Daten nach Zeilen, während Parquet die Daten nach Spaltenorganisiert. Außerdem unterscheidet sich das Format der Parquet-Datei von diesen Formaten, da es Datenzeilen in ein oder mehrere Zeilengruppenorganisiert.

Die interne Datenstruktur eines Power BI-Semantikmodells ist spaltenbasiert, was bedeutet, dass Parquet-Dateien viel mit Power BI gemeinsam haben. Diese Ähnlichkeit bedeutet, dass ein Direct Lake-Semantikmodell Daten aus den Parkettdateien effizient in den Speicher laden kann. Tatsächlich können sehr große Datenmengen in Sekunden geladen werden. Kontrastieren Sie diese Funktion mit der Aktualisierung eines Importsemantikmodells, das Blöcke oder Quelldaten abrufen muss, und verarbeiten, codieren, speichern und dann in den Arbeitsspeicher laden. Ein Aktualisierungsvorgang für das Importsemantikmodell kann auch erhebliche Rechenmengen (Arbeitsspeicher und CPU) verbrauchen und viel Zeit in Anspruch nehmen. Bei Delta-Tabellen erfolgt jedoch der größte Teil des Aufwands zur Vorbereitung der Daten, die für das direkte Laden in ein semantisches Modell geeignet sind, bereits bei der Generierung der Parquet-Datei.

Wie Parkettdateien Daten speichern

Betrachten Sie den folgenden Beispielsatz von Daten.

Datum ProductID StockOnHand
16.09.2024 A 10
16.09.2024 B 11
2024-09-17 A 13
…

Wenn die Datenmenge konzeptionell im Parquet-Dateiformat gespeichert wird, sieht sie möglicherweise wie der folgende Text 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. RLE ist bestrebt, eine Reihe von gleichen Werten in eine kleinere Darstellung zu komprimieren. Im folgenden Beispiel wird eine Wörterbuchzuordnung numerischer Schlüssel zu Werten in der Kopfzeile 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 benötigt, um die Summe der nach ProductIDgruppierten StockOnHand Spalte zu berechnen, ist nur das Wörterbuch und die mit den beiden Spalten verknüpften Daten erforderlich. In großen Dateien, die viele Spalten enthalten, können erhebliche Teile der Parquet-Datei übersprungen werden, um den Lesevorgang zu beschleunigen.

Anmerkung

Der Inhalt einer Parquet-Datei ist nicht menschenlesbar und eignet sich daher nicht zum Öffnen in einem Text-Editor. Es gibt jedoch viele Open-Source-Tools, die den Inhalt einer Parkettdatei öffnen und offenlegen können. Mit diesen Tools können Sie auch Metadaten überprüfen, z. B. die Anzahl der Zeilen und Zeilengruppen, die in einer Datei enthalten sind.

V-Reihenfolge

Fabric unterstützt eine zusätzliche Optimierung namens V-Order. Die V-Reihenfolge optimiert die erforderliche Zeit für das Schreiben in das Parquet-Dateiformat. Nachdem V-Order angewendet wurde, führt sie zu einer kleineren und damit schnelleren Datei zum Lesen. Diese Optimierung ist besonders für ein Direct Lake-Semantikmodell relevant, da sie die Daten für das schnelle Laden in den Arbeitsspeicher vorbereitet und somit weniger Anforderungen an Kapazitätsressourcen erfüllt. Sie führt auch zu einer schnelleren Abfrageleistung, da weniger Arbeitsspeicher gescannt werden muss.

Delta-Tabellen, die von Fabric-Elementen wie Datenpipelines, Dataflows und Notebooks erstellt und geladen wurden, wenden die 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. Während nicht optimierte Parkettdateien noch gelesen werden können, ist die Leseleistung wahrscheinlich nicht so schnell wie eine entsprechende Parkettdatei, auf die V-Order angewendet wurde.

Anmerkung

Parkettdateien, auf die V-Order angewendet wurde, entsprechen weiterhin dem Open-Source-Parkett-Dateiformat. Daher können sie von Nicht-Fabric-Tools gelesen werden.

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

Delta-Tabellenoptimierung

In diesem Abschnitt werden verschiedene Themen zum Optimieren von Delta-Tabellen für semantische Modelle beschrieben.

Datenvolume

Während Delta-Tabellen extrem große Datenmengen speichern können, setzen die Kapazitätsbegrenzungen von Fabric Grenzwerte für semantische Modelle, die auf sie zugreifen. Wenn diese Grenzwerte überschritten werden, greifen Abfragen auf den DirectQuery-Modus zurück, was zu einer langsameren Abfrageleistung führen kann.

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

Stellen Sie außerdem sicher, dass V-Order- angewendet wird, da sie zu einer kleineren und damit schnelleren Datei zum Lesen führt.

Spaltendatentyp

Versuchen Sie, die Kardinalität (die Anzahl eindeutiger Werte) in jeder Spalte jeder Delta-Tabelle zu reduzieren. Das liegt daran, dass alle Spalten mithilfe der -Hashcodierungkomprimiert und gespeichert werden. Für die Hashcodierung ist eine V-Order-Optimierung erforderlich, um jedem eindeutigen Wert, der in der Spalte enthalten ist, einen numerischen Bezeichner zuzuweisen. Es ist der numerische Bezeichner, der dann gespeichert wird und eine Hash-Suche während des Speichers und der Abfrage erfordert.

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

Unnötige Spalten

Wie bei jeder Datentabelle sollten Delta-Tabellen nur Spalten speichern, die erforderlich sind. Im Kontext dieses Artikels bedeutet dies, dass das semantische Modell erforderlich ist, obwohl es andere Analyseworkloads geben könnte, die die Delta-Tabellen abfragen.

Delta-Tabellen sollten Spalten enthalten, die vom semantischen Modell zum Filtern, Gruppieren, Sortieren und Zusammenfassen erforderlich sind, zusätzlich zu Spalten, die Modellbeziehungen unterstützen. Unnötige Spalten wirken sich zwar nicht auf die Leistung von Semantikmodellabfragen aus (da sie nicht in den Arbeitsspeicher geladen werden), sie führen jedoch zu einer größeren Speichergröße und erfordern daher mehr Rechenressourcen zum Laden und Verwalten.

Da die Semantikmodelle von Direct Lake 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 über die Spalten FirstName und LastName verfügen und die Spalte FullName benötigen, materialisieren Sie die Werte für diese Spalte beim Einfügen von Zeilen in die Delta-Tabelle.

Beachten Sie, dass einige Zusammenfassungen des semantischen Modells 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 der Zeilen in einer Zeilengruppe beeinflusst, wie schnell Direct Lake die Daten lesen kann. Eine höhere Anzahl von Zeilengruppen mit weniger Zeilen wirkt sich wahrscheinlich negativ auf das Laden von Spaltendaten in ein semantisches Modell aus, da übermäßige E/A-Vorgänge erforderlich sind.

Im Allgemeinen wird davon abgeraten, die Standardgröße der Zeilengruppe zu ändern. Sie können jedoch die Zeilengruppengröße für große Delta-Tabellen ändern. Testen Sie sorgfältig die Lese- und Schreibleistung, indem Sie möglicherweise mehrere Kopien derselben Delta-Tabellen 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 langsameren Abfrageleistung führen kann.

Wartung von Delta-Tabellen

Wenn Schreibvorgänge stattfinden, sammeln sich im Laufe der Zeit Delta-Tabellenversionen an. Schließlich können Sie einen Punkt erreichen, an dem sich negative Auswirkungen auf die Leseleistung bemerkbar machen. 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 langsameren Abfrageleistung führen kann. Daher ist es wichtig, dass Sie Delta-Tabellen regelmäßig verwalten.

OPTIMIZE

Sie können OPTIMIZE verwenden, um eine Delta-Tabelle so zu optimieren, dass kleinere Dateien in größere Dateien zusammengeführt werden. Sie können die WHERE-Klausel auch so festlegen, dass nur eine gefilterte Teilmenge von Zeilen anvisiert wird, die einem bestimmten Partitions-Prädikat entsprechen. Nur Filter mit Partitionsschlüsseln werden unterstützt. Der Befehl OPTIMIZE kann auch V-Order anwenden, um die Parkettdateien zu komprimieren und neu zu schreiben.

Es wird empfohlen, diesen Befehl regelmäßig auf großen, häufig aktualisierten Delta-Tabellen auszuführen, z. B. jeden Tag, wenn Der ETL-Prozess abgeschlossen ist. Den Kompromiss zwischen einer besseren Anfrageleistung und den Kosten der zur Optimierung der Tabelle erforderlichen Ressourcennutzung ausgleichen.

VAKUUM

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 gerahmtes Semantikmodell auf eine bestimmte Version der Delta-Tabelle verweist, muss die Quelle sicherstellen, dass diese Delta-Tabellenversion beibehalten wird, bis die neue Version vollständig gerahmt ist. 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

Um Tabellenwartungsvorgänge zu automatisieren, können Sie die Lakehouse-API verwenden. Weitere Informationen finden Sie unter Manage the Lakehouse with 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.

Verwandte Inhalte