Freigeben über

Grundlegendes zu Speicher für Direct Lake-Semantikmodelle

  • Artikel

In diesem Artikel werden Direct Lake-Speicherkonzepte vorgestellt. Es beschreibt Delta-Tabellen und Parkettdateien. 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-Computemodule wie Notizbücher, Kusto und das Lakehouse und Warehouse verfü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.

Hinweis

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 Parkettdateien, die in der Regel in einem Seehaus gespeichert sind, das ein Direct Lake-Semantikmodell zum Laden von Daten verwendet. Aber auch Parkettdateien können extern gelagert werden. Externe Parkettdateien können mithilfe einer OneLake-Verknüpfung referenziert werden, die auf einen bestimmten Speicherort verweist, z . B. Azure Data Lake Storage (ADLS) Gen2, Amazon S3-Speicherkonten oder Dataverse. In fast allen Fällen greifen Rechenmodule auf die Parkettdateien zu, indem Sie Delta-Tabellen abfragen. In der Regel laden jedoch Direct Lake-Semantikmodelle Spaltendaten direkt aus optimierten Parkettdateien in OneLake mithilfe eines Prozesses, der als Transcodierung bezeichnet wird.

Datenversionsverwaltung

Delta-Tabellen umfassen eine oder mehrere Parkettdateien. 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 Parkettdateien inkrementell sind. Daher lautet der Name Delta als Verweis auf die inkrementelle Datenänderung. 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 Version darstellen. Parkettdateien sind daher unveränderlich, was bedeutet, dass sie nie geä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.

ProductID StockOnHand
H 1
b 2
K 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).

  • Parkettdatei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Linkdatei 1:
    • Enthält den Zeitstempel, an dem Parquet file 1 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.

Einfügevorgänge

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

  • Parkettdatei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parkettdatei 2:
    • ProductID: D
    • StockOnHand: 4
  • Linkdatei 1:
    • Enthält den Zeitstempel, an dem Parquet file 1 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, an dem Parquet file 2 erstellt wurde, und zeichnet auf, dass die 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 Parkettdateien stammt.

ProductID StockOnHand
H 1
b 2
K 3
D 4

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

Vorgänge aktualisieren

Berücksichtigen Sie nun, was passiert, wenn ein Aktualisierungsvorgang auftritt: Die Zeile für das Produkt D hat ihre Lagerbestände auf den Handwert geändert 10. Diese Vorgänge führen zur Erstellung einer neuen Parkettdatei und Linkdatei, so dass es jetzt drei Parkettdateien und drei Linkdateien gibt.

  • Parkettdatei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parkettdatei 2:
    • ProductID: D
    • StockOnHand: 4
  • Parkettdatei 3:
    • ProductID: C
    • StockOnHand: 10
  • Linkdatei 1:
    • Enthält den Zeitstempel, an dem Parquet file 1 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, an dem Parquet file 2 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.
  • Linkdatei 3:
    • Enthält den Zeitstempel, an dem Parquet file 3 erstellt wurde, und zeichnet auf, dass die 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 Produkte C sind jetzt in mehreren Parkettdateien vorhanden. Abfragen der Delta-Tabelle kombinieren jedoch die Verknüpfungsdateien, um zu bestimmen, welche Daten verwendet werden sollen, um das richtige Ergebnis bereitzustellen.

Vorgänge löschen

Berücksichtigen Sie nun, was passiert, wenn ein Löschvorgang auftritt: Die Zeile für das 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.

  • Parkettdatei 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parkettdatei 2:
    • ProductID: D
    • StockOnHand: 4
  • Parkettdatei 3:
    • ProductID: C
    • StockOnHand: 10
  • Parkettdatei 4:
    • ProductID: A, C, D
    • StockOnHand: 1, 10, 4
  • Linkdatei 1:
    • Enthält den Zeitstempel, an dem Parquet file 1 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.
  • Linkdatei 2:
    • Enthält den Zeitstempel, an dem Parquet file 2 erstellt wurde, und zeichnet auf, dass die Daten angefügt wurden.
  • Linkdatei 3:
    • Enthält den Zeitstempel, an dem Parquet file 3 erstellt wurde, und zeichnet auf, dass die Daten aktualisiert wurden.
  • Linkdatei 4:
    • Enthält den Zeitstempel, an dem Parquet file 4 erstellt wurde, und zeichnet auf, dass die Daten gelöscht wurden.

Beachten Sie, dass Parquet file 4 keine Daten mehr für das Produkt Benthalten sind, 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
H 1
K 10
D 4

Hinweis

Dieses Beispiel ist einfach, da es eine kleine Tabelle, nur wenige Vorgänge und nur geringfügige Änderungen umfasst. Große Tabellen, die viele Schreibvorgänge aufweisen und viele Datenzeilen enthalten, generieren pro Version mehr als eine Parkettdatei.

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 Schutzschienen aufweist. Wenn die Anzahl der Parkettdateien für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, fallen Abfragen auf DirectQuery zurück, was zu einer langsameren Abfrageleistung führen kann.

Informationen zur Verwaltung der Anzahl von Parkettdateien finden Sie in der Delta-Tabellenwartung weiter unten in diesem Artikel.

Delta Zeitreise

Verknüpfungsdateien ermöglichen das Abfragen von Daten ab einem früheren Zeitpunkt. Diese Funktion wird als Delta-Zeitreise bezeichnet. 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 Format yyyyMMddHHmmssSSS vorliegen. Sie können eine Version nach @ angeben, indem Sie der Version 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 zur Wartung der Delta-Tabelle beschrieben). Wenn Sie VACUUM täglich mit den Standardwerten ausführen, stehen sieben Tage Daten für Zeitreisen zur Verfügung.

Rahmung

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 die Version auch, was beim Laden von Daten ausgeschlossen werden soll.

Ein Rahmenvorgang stempelt den Zeitstempel/die Version jeder Delta-Tabelle in die Semantikmodelltabellen. Ab diesem Zeitpunkt wird verwendet, wenn das semantische Modell Daten aus einer Delta-Tabelle laden muss, der zeitstempel/version, die dem letzten Framingvorgang zugeordnet ist, 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 rahmenfähiges Semantikmodell auf eine bestimmte Delta-Tabellenversion verweist, muss die Quelle sicherstellen, dass die Delta-Tabellenversion bis zum Abschluss einer neuen Version beibehalten wird. Andernfalls treten Fehler auf, wenn auf die Delta-Tabellendateien vom Modell zugegriffen werden muss und von der Produktionsauslastung abgesaugt oder anderweitig gelöscht wurden.

Weitere Informationen zum Framing finden Sie in der Ü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 Milliardenzeilen von Daten über mehrere Reihen von Parkettdateien 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 nur auf die letzten drei Monate der Verkaufsdaten gefiltert wird, können die Teilmenge der Parkettdateien und Verknüpfungsdateien, auf die zugegriffen werden muss, schnell identifiziert werden. Das ermöglicht es dann, viele Parkettdateien insgesamt 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.

Partitionierungsvorteile sind auch Einfüge-, Aktualisierungs- und Löschvorgänge, da Dateiaktivitäten nur in Unterordnern ausgeführt werden, 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 verbessert sich, indem die Anzahl und Größe aller neuen Parkettdateien reduziert werden, die erstellt werden müssen. Für eine große Delta-Tabelle, die nach Monat/Jahr partitioniert wird, wie im vorherigen Beispiel beschrieben, werden neue Daten nur neue Parkettdateien zur neuesten Partition hinzugefügt. 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 andere Abfrageworkloads) zu dienen, empfiehlt es sich in der Regel, partitionierungspräferenzen zur Optimierung der Auslastung von Spalten in den Arbeitsspeicher zu vermeiden.

Bei Direct Lake-Semantikmodellen oder dem SQL-Analyseendpunkt besteht die beste Möglichkeit zum Optimieren von Delta-Tabellenpartitionen darin, Fabric die Parkettdateien für jede Version einer Delta-Tabelle automatisch zu verwalten. 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 wird empfohlen, die Lese- und Schreibleistung sorgfältig zu testen, indem Sie vielleicht mehrere Kopien derselben Delta-Tabelle mit unterschiedlichen Konfigurationen erstellen, um Die Anzeigedauern zu vergleichen.

Warnung

Wenn Sie eine Spalte mit hoher Kardinalität partitionieren, kann dies zu einer übermäßigen Anzahl von Parkettdateien führen. Beachten Sie, dass jede Fabric-Kapazitätslizenz Schutzschienen aufweist. Wenn die Anzahl der Parkettdateien für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, fallen Abfragen auf DirectQuery zurück, was zu einer langsameren Abfrageleistung führen kann.

Parquet-Dateien

Der zugrunde liegende Speicher für eine Delta-Tabelle ist eine oder mehrere Parkettdateien. Das Parkettdateiformat wird in der Regel für schreibgeschützte, lese-n-Anwendungen 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.

Hinweis

Sie können mit einem Tool wie dem OneLake-Datei-Explorer auf Parkettdateien 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 Parkettdateien und den JSON-basierten Verknüpfungsdateien, die es Computemodulen ermöglichen, Abfragen für die Dateien als Delta-Tabelle auszugeben.

Parquet-Dateiformat

Das interne Format einer Parkettdatei unterscheidet sich von anderen gängigen Datenspeicherformaten wie CSV, TSV, XMLA und JSON. Diese Formate ordnen Daten nach Zeilen an, während Die Daten nach Spalten organisiert werden. Außerdem unterscheidet sich das Format von Parkettdatei von diesen Formaten, da sie Datenzeilen in einer oder mehreren Zeilengruppen organisiert.

Die interne Datenstruktur eines Power BI-Semantikmodells ist spaltenbasiert, was bedeutet, dass Parkettdateien viel gemeinsam mit Power BI nutzen. 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, die Daten vorzubereiten, die für das direkte Laden in ein semantisches Modell geeignet sind, wenn die Parkettdatei generiert wird.

Wie Parkettdateien Daten speichern

Betrachten Sie den folgenden Beispielsatz von Daten.

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

Wenn diese Datenmenge konzeptionell im Format "Parkett" gespeichert wird, sieht diese Datenmenge 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 durch Ersetzen von Wörterbuchschlüsseln für allgemeine Werte und durch Anwenden der Codierung der Länge der Länge (Run-Length Encoding, RLE) komprimiert. 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 StockOnHand Spalte zu berechnen, nach ProductIDder gruppiert wird, 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 Parkettdatei übersprungen werden, um den Lesevorgang zu beschleunigen.

Hinweis

Der Inhalt einer Parkettdatei ist nicht lesbar 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-Order

Fabric unterstützt eine zusätzliche Optimierung namens V-Order. V-Order ist eine Schreibzeitoptimierung in das Parkettdateiformat. 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 Datenpipelinen, Datenflüssen und Notizbüchern erstellt und geladen wurden, wenden automatisch V-Order an. In einem Fabric Lakehouse hochgeladene Parkettdateien oder auf die durch eine Verknüpfung verwiesen wird, kann diese Optimierung jedoch nicht angewendet werden. 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.

Hinweis

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.

Datenmenge

Während Delta-Tabellen so wachsen können, dass extrem große Datenmengen gespeichert werden, erzwingen Fabric-Kapazitätsschutzschienen Grenzwerte für semantische Modelle, die sie abfragen. Wenn diese Grenzwerte überschritten werden, fallen Abfragen auf DirectQuery zurück, was zu einer langsameren Abfrageleistung führen kann.

Erwägen Sie daher, die Zeilenanzahl einer großen Faktentabelle einzuschränken, indem Sie ihre Granularität erhöhen (zusammengefasste Daten speichern), die Dimensionalität verringern oder weniger Verlauf 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 Hashcodierung komprimiert 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 Abrunden von Werten und die Verwendung einer niedrigeren Genauigkeit in Betracht 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 und Spalten verfügen FirstName und LastName eine FullName Spalte benötigen, werden die Werte für diese Spalte beim Einfügen von Zeilen in die Delta-Tabelle materialisiert.

Beachten Sie, dass einige Zusammenfassungen des semantischen Modells möglicherweise von mehr als einer Spalte abhängen. Um z. B. 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 Parkettdatei Zeilen mit Daten in mehreren Zeilengruppen innerhalb jeder Datei. Beispielsweise kann eine Parkettdatei, die 30.000 Zeilen enthält, sie in drei Zeilengruppen unterteilen, wobei jeweils 10.000 Zeilen vorhanden sind.

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 die Lese- und Schreibleistung sorgfältig, indem Sie vielleicht mehrere Kopien derselben Delta-Tabellen mit unterschiedlichen Konfigurationen erstellen, um Die Anzeigedauern zu vergleichen.

Wichtig

Beachten Sie, dass jede Fabric-Kapazitätslizenz Schutzschienen aufweist. Wenn die Anzahl der Zeilengruppen für eine Delta-Tabelle den Grenzwert für Ihre SKU überschreitet, fallen Abfragen auf DirectQuery zurück, was zu einer langsameren Abfrageleistung führen kann.

Wartung von Delta-Tabellen

Im Laufe der Zeit sammeln sich die Delta-Tabellenversionen, da Schreibvorgänge durchgeführt werden. Schließlich können Sie einen Punkt erreichen, an dem sich negative Auswirkungen auf die Leseleistung bemerkbar machen. Schlimmer noch: Wenn die Anzahl der Parkettdateien pro Tabelle oder Zeilengruppen pro Tabelle oder Zeilen pro Tabelle die Schutzläufe für Ihre Kapazität überschreitet, fallen Abfragen auf DirectQuery 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 zu optimieren, um kleinere Dateien in größere Dateien zusammenzugliedern. Sie können die WHERE Klausel auch so festlegen, dass sie nur auf eine gefilterte Teilmenge von Zeilen ausgerichtet ist, die einem bestimmten Partitions-Prädikat entsprechen. Nur Filter mit Partitionsschlüsseln werden unterstützt. Der OPTIMIZE Befehl 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. Ausgleich des Ausgleichs zwischen einer besseren Abfrageleistung und den Kosten für die Ressourcennutzung, die zum Optimieren der Tabelle erforderlich sind.

VACUUM

Sie können VAKUUM 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 verlieren Sie möglicherweise die Möglichkeit, zu einer version zurückzukehren, die älter ist als der Frame, der in semantische Modelltabellen gestempelt ist.

Wichtig

Da ein rahmenfähiges Semantikmodell auf eine bestimmte Delta-Tabellenversion verweist, muss die Quelle sicherstellen, dass die Delta-Tabellenversion bis zum Abschluss einer neuen Version beibehalten wird. Andernfalls treten Fehler auf, wenn auf die Delta-Tabellendateien vom Modell zugegriffen werden muss und von der Produktionsauslastung abgesaugt oder anderweitig gelöscht wurden.

REORG TABLE

Sie können REORG TABLE verwenden, um eine Delta-Tabelle neu zu organisieren, indem Sie Dateien neu schreiben, um vorläufig gelöschte Daten zu löschen, z. B. wenn Sie eine Spalte mithilfe von ALTER TABLE DROP COLUMN ablegen.

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 Wartungsfeature "Lakehouse Table" im Fabric-Portal verwenden, um die Verwaltung Ihrer Delta-Tabellen zu vereinfachen.

Zugehöriger Inhalt