Freigeben über

Leistungsrichtlinien in Fabric Data Warehouse

Gilt für:✅ Warehouse in Microsoft Fabric

Dieser Artikel enthält bewährte Methoden für Datenaufnahme, Tabellenverwaltung, Datenvorbereitung, Statistiken und Abfragen in Warehouses und SQL-Analyseendpunkten. Feinabstimmung der Leistung und Optimierung können einzigartige Herausforderungen darstellen, bieten aber auch wertvolle Chancen, um das Potenzial Ihrer Datenlösungen zu maximieren.

Informationen zum Überwachen der Leistung in Ihrem Lager finden Sie unter Monitor Fabric Data Warehouse.

Optimierung des Datentyps

Die Auswahl der richtigen Datentypen ist für leistung und Lagereffizienz in Ihrem Lager unerlässlich. Die folgenden Richtlinien tragen dazu bei, dass Ihr Schemadesign schnelle Abfragen, effizienten Speicher und Wartung unterstützt.

Weitere Informationen zu Datentypen, die von Fabric Data Warehouse unterstützt werden, finden Sie unter Datentypen in Fabric Data Warehouse.

Tipp

Wenn Sie externe Tools verwenden, um Tabellen oder Abfragen zu generieren, z. B. mit einer Code-first-Bereitstellungsmethode, überprüfen Sie die Spaltendatentypen sorgfältig. Zeichendatentyplängen und Abfragen sollten diesen bewährten Methoden entsprechen.

Zuordnen von Datentypen zur Datensemantik

Um Klarheit und Leistung sicherzustellen, ist es wichtig, den Datentyp jeder Spalte mit der tatsächlichen Art und dem Verhalten der gespeicherten Daten auszurichten.

  • Verwenden Sie Datum, Uhrzeit oder Datetime2(n) für zeitliche Werte, anstatt sie als Zeichenfolgen zu speichern.
  • Verwenden Sie ganzzahlige Typen für numerische Werte, es sei denn, die Formatierung (z. B. führende Nullen) ist erforderlich.
  • Verwenden Sie Zeichenarten (char, varchar), wenn die Formatierung beibehalten werden muss (z. B. Zahlen, die mit Null beginnen können, Produktcodes, Zahlen mit Strichen).

Verwenden von ganzzahligen Typen für ganze Zahlen

Beim Speichern von Werten wie Bezeichnern, Zählern oder anderen ganzen Zahlen bevorzugen Sie ganzzahlige Typen (smallint, int, bigint) gegenüber dezimaler/Zahl. Ganzzahlige Typen erfordern weniger Speicher als Datentypen, die Ziffern rechts vom Dezimalkomma zulassen. Daher ermöglichen sie schnellere arithmetische und Vergleichsvorgänge und verbessern die Indizierungs- und Abfrageleistung.

Beachten Sie die Wertebereiche für jeden ganzzahligen Datentyp, der von Fabric Data Warehouse unterstützt wird. Weitere Informationen finden Sie unter int, bigint, smallint (Transact-SQL).

Berücksichtigen Sie die Verwendung von dezimaler und numerischer Genauigkeit und Skalierung

Wenn Sie eine dezimale/Zahl verwenden müssen, wählen Sie beim Erstellen der Spalte die kleinste Genauigkeit und Skalierung aus, die Ihre Daten aufnehmen kann. Die Genauigkeit der Überbereitstellung erhöht die Speicheranforderungen und kann die Leistung beeinträchtigen, wenn daten wachsen.

  • Antizipieren Sie das erwartete Wachstum und die Bedürfnisse Ihres Lagers. Wenn Sie beispielsweise beabsichtigen, nicht mehr als vier Ziffern rechts vom Dezimalkomma zu speichern, verwenden Sie "dezimal(9,4) " oder "dezimal(19,4)" für den effizientesten Speicher.
  • Geben Sie beim Erstellen einer dezimalen/numerischen Spalte immer Genauigkeit und Skalierung an. Wenn sie in einer tabelle erstellt wird, die als "justdecimal" definiert ist, ohne die Genauigkeit und Skalierung anzugeben(p,s), wird eine dezimale/numerische Spalte als decimal(18,0)erstellt. Eine Dezimalzahl mit einer Genauigkeit von 18 verbraucht 9 Bytes Speicherplatz pro Zeile. Eine Skala von 0 speichert keine Daten rechts vom Dezimalkomma. Für viele Unternehmen ganze Zahlen, smallint, int, bigint sind viel effizienter als decimal(18,0). Beispielsweise kann jede neunstellige ganze Zahl als ganzzahliger Datentyp für 4 Byte Speicher pro Zeile gespeichert werden.

Weitere Informationen finden Sie unter Dezimal und Numerisch (Transact-SQL).

Überlegen Sie, wann Varchar over char verwendet werden soll.

Verwenden Sie varchar(n) anstelle von char(n) für Zeichenfolgenspalten. Es sei denn, der Abstand mit fester Länge ist explizit erforderlich. Eine Varchar-Spalte speichert nur die tatsächliche Länge der Zeichenfolge pro Zeile sowie einen kleinen Mehraufwand und reduziert verschwendeten Platz, wodurch die E/A-Effizienz verbessert wird.

  • Verwenden Sie varchar(n) für Werte wie Namen, Adressen und Beschreibungen, da sie weit variable Werte aufweisen. Statistiken und Abfragekostenschätzungen sind genauer, wenn die Länge des Datentyps für die tatsächlichen Daten genauer ist.
  • Verwenden Sie Char(n), wenn Sie wissen, dass die Zeichenfolge jedes Mal eine feste Länge ist. Das Speichern der Zeichenfolge 000000000 als Zeichen(9) ist beispielsweise sinnvoll, wenn die Zeichenfolge immer genau 9 numerische Zeichen ist, die mit einer Null beginnen können.
  • Die Länge n in der Deklaration des Spaltendatentyps ist die Speichergröße in Bytes. Bei Multibyte-Codierungszeichensätzen wie UTF-8 benötigen die Codierung für Fabric Data Warehouse, lateinische Zeichen und Zahlen 1 Byte Speicher. Es gibt jedoch Unicode-Zeichen, die mehr als 1 Byte erfordern, z. B. japanische Zeichen, die 3 Byte speichern müssen, sodass die Anzahl der tatsächlich gespeicherten Unicode-Zeichen kleiner als die Länge des Datentyps nsein kann. Weitere Informationen finden Sie unter Char- und Varchar-Argumente.

Vermeiden von nullablen Spalten nach Möglichkeit

Definieren Sie Spalten so, als NOT NULL wenn das Datenmodell dies zulässt. Standardmäßig erlaubt eine Spalte in einer Tabelle NULL Werte. Nullfähige Spalten weisen die folgenden Merkmale auf:

  • Sie fügen Metadatenaufwand hinzu.
  • Die Effektivität von Abfrageoptimierungen und Statistiken kann reduziert werden.
  • Kann sich auf die Leistung in umfangreichen Analytischen Abfragen auswirken.

Datenaufnahme und -vorbereitung in ein Datenlager

KOPIEREN IN

Der Befehl T-SQL COPY INTO ist die empfohlene Methode zum Aufnehmen von Daten aus Azure Data Lake Storage in Fabric Data Warehouse. Weitere Informationen und Beispiele finden Sie unter Daten in Ihr Warehouse laden mithilfe der COPY-Anweisung.

Berücksichtigen Sie die folgenden Empfehlungen für eine optimale Leistung:

  • Dateigröße: Stellen Sie sicher, dass jede datei, die Sie aufnehmen, idealerweise zwischen 100 MB und 1 GB für den maximierten Durchsatz liegt. Dies hilft, den Aufnahmeprozess zu optimieren und die Leistung zu verbessern.
  • Anzahl der Dateien: Um die Parallelität und Abfrageleistung zu maximieren, möchten Sie eine hohe Anzahl von Dateien generieren. Priorisieren Sie das Erstellen von so vielen Dateien wie möglich, während sie eine Mindestdateigröße von 100 MB beibehalten.
  • Paralleles Laden: Verwenden Sie mehrere COPY INTO Anweisungen, die parallel ausgeführt werden, um Daten in verschiedene Tabellen zu laden. Dieser Ansatz kann das ETL/ELT-Fenster aufgrund von Parallelität erheblich reduzieren.
  • Kapazitätsgröße: Für größere Datenvolumes sollten Sie eine Skalierung auf größere Fabric-Kapazität erwägen, um die zusätzlichen Rechenressourcen abzurufen, die erforderlich sind, um zusätzliche Anzahl paralleler Verarbeitung und größerer Datenvolumes zu berücksichtigen.

Fabric Data Warehouse unterstützt auch die BULK INSERT Anweisung, die ein Synonym für COPY INTO ist. Die gleiche Empfehlung gilt für BULK INSERT Erklärung.

CTAS oder INSERT

Verwenden Sie CREATE TABLE AS SELECT (CTAS) oder INSERT kombiniert mit SELECT FROM Lakehouse-Tabellen-/Abkürzungsbefehlen. Diese Methoden könnten leistungsfähiger und effizienter sein als die Verwendung von Pipelines, was eine schnellere und zuverlässigere Datenübertragung ermöglicht. Weitere Informationen und Beispiele finden Sie unter "Erfassen von Daten in Ihr Warehouse mithilfe von Transact-SQL".

Das Konzept, die Parallelität und die Skalierung auf größere Fabric-Kapazität zu erhöhen, gilt auch für CTAS/INSERT-Vorgänge, um den Durchsatz zu steigern.

Lesen von Daten aus Azure Data Lake Storage oder Blob Storage mit OPENROWSET

Mit der OPENROWSET-Funktion können Sie CSV- oder Parquet-Dateien aus dem Azure Data Lake oder Azure Blob Storage lesen, ohne sie in das Warehouse aufzunehmen. Weitere Informationen und Beispiele finden Sie unter Durchsuchen von Dateiinhalten mithilfe der OPENROWSET-Funktion.

Berücksichtigen Sie beim Lesen von Daten mithilfe der OPENROWSET-Funktion die folgenden Empfehlungen für eine optimale Leistung:

  • Parkett: Versuchen Sie, Parkett anstelle von CSV zu verwenden, oder konvertieren Sie CSV in Parkett, wenn Sie die Dateien häufig abfragen. Bei Parquet handelt es sich um ein Spaltenformat. Da Daten komprimiert werden, sind die Dateigrößen kleiner als CSV-Dateien, die dieselben Daten enthalten. Fabric Data Warehouse überspringt die Spalten und Zeilen, die in einer Abfrage nicht benötigt werden, wenn Sie Parkettdateien lesen.
  • Dateigröße: Stellen Sie sicher, dass jede datei, die Sie aufnehmen, idealerweise zwischen 100 MB und 1 GB für den maximierten Durchsatz liegt. Dies hilft, den Aufnahmeprozess zu optimieren und die Leistung zu verbessern. Es ist besser, Dateien gleicher Größe zu haben.
  • Anzahl der Dateien: Um die Parallelität und Abfrageleistung zu maximieren, möchten Sie eine hohe Anzahl von Dateien generieren. Priorisieren Sie das Erstellen von so vielen Dateien wie möglich, während sie eine Mindestdateigröße von 100 MB beibehalten.
  • Partition: Partitionieren Sie Ihre Daten, indem Sie Partitionen in verschiedenen Ordnern oder unter verschiedenen Dateinamen speichern, wenn Ihr Workload nach Partitionsspalten gefiltert wird.
  • Schätzung: Versuchen Sie, ROWS_PER_BATCH so einzustellen, dass es mit der Anzahl der Zeilen in den zugrunde liegenden Dateien übereinstimmt, wenn Sie den Eindruck haben, dass Sie die erwartete Leistung nicht erhalten.
  • Kapazitätsgröße: Für größere Datenvolumes sollten Sie eine Skalierung auf größere SKU erwägen, um mehr Rechenressourcen zu erhalten, die erforderlich sind, um zusätzliche Anzahl paralleler Verarbeitung und größerer Datenvolumes zu berücksichtigen.

Vermeiden von stetigen Einfügungen, Aktualisierungen und Löschungen

Um ein effizientes Dateilayout und eine optimale Abfrageleistung in Fabric Data Warehouse sicherzustellen, vermeiden Sie die Verwendung vieler kleiner INSERT, und UPDATEDELETE Transaktionen. Diese Zeilenebenenänderungen generieren eine neue Parkettdatei für jeden Vorgang, was zu einer großen Anzahl kleiner Dateien und fragmentierter Zeilengruppen führt. Diese Fragmentierung führt zu:

  • Erhöhte Abfragelatenz aufgrund ineffizienter Dateiscanning.
  • Höhere Speicher- und Berechnungskosten.
  • Größere Abhängigkeit von Hintergrundkomprimierungsprozessen.

Empfohlene Ansätze:

  • Transaktionen im Batchverfahren, die in das "Fabric Data Warehouse" geschrieben werden.
    • Statt z. B. viele kleine INSERT Anweisungen zu verwenden, fassen Sie die Daten vorab zusammen und fügen Sie sie in eine INSERT Anweisung ein.
  • Verwenden Sie COPY INTO für Masseneinfügungen, und führen Sie nach Möglichkeit Aktualisierungen und Löschungen in Batches durch.
  • Bewahren Sie eine minimale importierte Dateigröße von 100 MB auf, um eine effiziente Zeilengruppenbildung sicherzustellen.
  • Weitere Anleitungen und bewährte Methoden für die Datenaufnahme finden Sie unter Bewährte Methoden zum Aufnehmen von Daten in einem Lager.

Datenkomprimierung

Im Fabric Data Warehouse ist die Datenkompaktierung ein Hintergrundoptimierungsprozess, der kleine, ineffiziente Parquet-Dateien in weniger, größere Dateien zusammenführt. Häufig werden diese Dateien durch häufige TrickleINSERT-, UPDATE- oder DELETE-Operationen erstellt. Durch die Datenkomprimierung wird die Dateifragmentierung reduziert, die Effizienz der Zeilengruppen verbessert und die Gesamtleistung der Abfrage verbessert.

Obwohl die Fabric Data Warehouse-Engine die Fragmentierung im Laufe der Zeit durch Datenkomprimierung automatisch behebt, kann es zu Leistungseinbußen kommen, bis der Prozess abgeschlossen ist. Die Datenkomprimierung wird automatisch ohne Benutzereingriff für Fabric Data Warehouse ausgeführt.

Die Datenkomprimierung gilt nicht für das Lakehouse. Für Lakehouse-Tabellen, auf die über SQL-Analyseendpunkte zugegriffen wird, ist es wichtig, die bewährten Methoden von Lakehouse zu befolgen und den BEFEHL OPTIMIZE manuell auszuführen, nachdem erhebliche Datenänderungen vorgenommen wurden, um ein optimales Speicherlayout aufrechtzuerhalten.

V-Order im Fabric Data Warehouse

V-Order ist eine Schreibzeitoptimierung in das Parkettdateiformat, das schnelle Lesevorgänge in Microsoft Fabric ermöglicht. V-Order in Fabric Data Warehouse verbessert die Abfrageleistung, indem Sortier- und Komprimierung auf Tabellendateien angewendet wird.

Standardmäßig ist V-Order für alle Lagerhäuser aktiviert, um sicherzustellen, dass Lesevorgänge, insbesondere analytische Abfragen, so schnell und effizient wie möglich sind.

V-Order führt jedoch einen kleinen Eingabeaufwand ein, der in schreibintensiven Workloads spürbar ist. Aus diesem Grund sollte die Deaktivierung von V-Order nur für Lagerhäuser gelten, die streng schreibintensiv sind und nicht für häufige Abfragen verwendet werden. Es ist wichtig zu beachten, dass V-Order, wenn es in einem Lager einmal deaktiviert wurde, nicht wieder aktiviert werden kann.

Bevor Sie sich für die Deaktivierung von V-Order entscheiden, sollten Die Benutzer ihre Workloadleistung gründlich testen, um sicherzustellen, dass der Kompromiss gerechtfertigt ist. Ein gängiges Muster besteht darin, ein Staging-Warehouse mit deaktiviertem V-Order für die hochdurchsatzfähige Aufnahme und Datentransformation zu verwenden und die zugrunde liegenden Daten in ein V-Order-aktiviertes Data Warehouse aufzunehmen, um eine bessere Leseleistung zu erzielen. Weitere Informationen finden Sie unter Deaktivieren von V-Order im Warehouse in Microsoft Fabric.

Klonen von Tabellen anstelle des Kopierens von Tabellen

Tabellenklonen in Fabric Data Warehouse bieten eine schnelle und effiziente Möglichkeit zum Erstellen von Tabellen, ohne Daten zu kopieren. Bei einem Zero-Copy-Kloning-Ansatz wird nur die Metadaten der Tabelle dupliziert, während auf die zugrunde liegenden Datendateien direkt aus dem OneLake verwiesen wird. Auf diese Weise können Benutzer nahezu sofort konsistente, zuverlässige Tabellenkopien erstellen, ohne dass der Aufwand für die vollständige Datenduplizierung besteht.

Zero-Copy-Klons eignen sich ideal für Szenarien wie Entwicklung, Tests und Sicherung, die eine leistungsfähige, speichereffiziente Lösung bieten, die die Infrastrukturkosten reduziert.

  • Geklonte Tabellen kopieren auch alle wichtigen Sicherheitsfeatures aus der Quelle, einschließlich Row-Level Security (RLS), Column-Level Security (CLS) und Dynamic Data Masking (DDM), ohne dass nach dem Klonen erneut Richtlinien angewendet werden müssen.
  • Klonen können innerhalb des Datenaufbewahrungszeitraums zu einem bestimmten Zeitpunkt erstellt werden, was die Zeitreisefunktionen unterstützt.
  • Geklonte Tabellen sind unabhängig von ihrer Quelle vorhanden, Änderungen, die an der Quelle vorgenommen wurden, wirken sich nicht auf den Klon aus, und Änderungen am Klon wirken sich nicht auf die Quelle aus. Entweder die Quelle oder der Klon können unabhängig voneinander gelöscht werden.

Abfrageleistung

Statistik

Statistiken sind beibehaltene Objekte, die Daten in den Spalten Ihrer Tabellen darstellen. Der Abfrageoptimierer verwendet Statistiken, um die Kosten eines Abfrageplans zu ermitteln und zu schätzen. Fabric Data Warehouse und der Endpunkt für SQL-Analysen in Lakehouse verwenden und verwalten automatisch Histogrammstatistiken, Statistiken zur durchschnittlichen Spaltenlänge und Tabellenkardinalitätsstatistiken. Weitere Informationen finden Sie unter Statistics in Fabric Data Warehouse.

  • Die Befehle CREATE STATISTICS und UPDATE STATISTICS T-SQL werden für Histogrammstatistiken mit einer Spalte unterstützt. Sie können diese nutzen, wenn zwischen Ihren Tabellentransformationen und Ihrer Abfrageworkload ein großes Fenster vorhanden ist, z. B. während eines Wartungsfensters oder einer anderen Ausfallzeit. Dadurch wird die Wahrscheinlichkeit reduziert, dass Ihre SELECT Abfragen zuerst Statistiken aktualisieren müssen.
  • Versuchen Sie, ein Tabellenschema zu definieren, das die Datentypparität bei gemeinsamen Spaltenvergleichen verwaltet. Wenn Sie beispielsweise wissen, dass Spalten häufig in einer WHERE Klausel miteinander verglichen werden oder als JOIN ... ON Prädikat verwendet werden, stellen Sie sicher, dass die Datentypen übereinstimmen. Wenn nicht möglich, genau dieselben Datentypen zu verwenden, verwenden Sie ähnliche Datentypen, die für die implizite Konvertierung kompatibel sind. Vermeiden Sie explizite Datenkonvertierungen. Weitere Informationen finden Sie unter Datentypkonvertierung.

Tipp

Für Lakehouse-Benutzer kann die ACE-Cardinality Statistik Informationen aus den Delta-Protokolldateien Ihrer Tabellen verwenden, um genauer zu sein. Stellen Sie sicher, dass Ihre generierten Delta-Tabellen die Tabellenzeilenanzahl enthalten mit: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Weitere Informationen finden Sie unter Configure and manage Automated Table Statistics in Fabric Spark.

Beim Filtern von Lakehouse-Tabellen nach Zeitstempelspalte vor Apache Spark Runtime 3.5.0 werden zeilengruppenbasierte Statistiken für Zeitstempelspalten nicht generiert. Dieser Mangel an Statistiken erschwert es Systemen wie Fabric Warehouse, die Rowgroup-Eliminierung anzuwenden (auch als Datenüberspringen oder Prädikat-Pushdown bezeichnet), was eine Leistungsoptimierung ist, die irrelevante Zeilengruppen während der Abfrageausführung überspringt. Ohne diese Statistiken müssen Filterabfragen, die Zeitstempelspalten umfassen, möglicherweise mehr Daten scannen, was zu erheblicher Leistungsbeeinträchtigung führt. Sie können die Apache Spark-Laufzeit in Fabric aktualisieren. Apache Spark 3.5.0 und höhere Versionen können Zeilengruppen-Statistiken für Zeitstempelspalten generieren. Anschließend müssen Sie die Tabelle neu erstellen und die Daten aufnehmen, damit Statistiken auf Zeilengruppenebene generiert werden.

Leistung des Kalten Caches

Die erste Ausführung einer Abfrage in Fabric Data Warehouse kann unerwartet langsamer sein als nachfolgende Ausführung. Dies wird als Kaltstart bezeichnet, der durch Systeminitialisierungs- oder Skalierungsaktivitäten verursacht wird, die die Umgebung für die Verarbeitung vorbereiten.

Kaltstarts treten in der Regel auf, wenn:

  • Daten werden aus OneLake in den Arbeitsspeicher geladen, da zum ersten Mal auf sie zugegriffen wird und noch nicht zwischengespeichert wird.
  • Wenn zum ersten Mal auf Daten zugegriffen wird, wird die Abfrageausführung verzögert, bis die erforderlichen Statistiken automatisch generiert werden.
  • Fabric Data Warehouse hält Knoten nach einiger Zeit der Inaktivität automatisch an, um die Kosten zu reduzieren, und fügt Knoten als Teil der automatischen Skalierung hinzu. Das Fortsetzen oder Erstellen von Knoten dauert in der Regel weniger als eine Sekunde.

Diese Vorgänge können die Abfragedauer erhöhen. Kaltstarts können teilweise sein. Einige Computeknoten, Daten oder Statistiken sind möglicherweise bereits im Arbeitsspeicher verfügbar oder zwischengespeichert, während die Abfrage wartet, bis andere verfügbar sind. Weitere Informationen finden Sie unter Caching in der Fabric-Datenverwaltung.

Sie können Kaltstarteffekte erkennen, die durch das Abrufen von Daten aus dem Remotespeicher in den Arbeitsspeicher verursacht werden, indem Sie die queryinsights.exec_requests_history Ansicht abfragen. Überprüfen Sie die data_scanned_remote_storage_mb Spalte:

  • Ein Wert ungleich Null in data_scanned_remote_storage_mb zeigt einen Kaltstart an. Daten wurden während der Abfrageausführung von OneLake abgerufen. Nachfolgende Ansichten sollten nachweislich schneller sein in queryinsights.exec_requests_history.
  • Ein Nullwert in data_scanned_remote_storage_mb ist der perfekte Zustand, in dem alle Daten zwischengespeichert sind. Es wurden keine Knotenänderungen oder Daten aus OneLake benötigt, um die Abfrageergebnisse zu erfüllen.

Von Bedeutung

Beurteilen Sie die Abfrageleistung nicht basierend auf der ersten Ausführung. Überprüfen Sie data_scanned_remote_storage_mb immer, ob die Abfrage vom Kaltstart betroffen ist. Nachfolgende Ausführungen sind oft deutlich schneller und repräsentativ für die tatsächliche Leistung, wodurch die durchschnittliche Ausführungszeit verringert wird.

Abfragen für Tabellen mit Zeichenfolgenspalten

Verwenden Sie die kleinste Länge der Zeichenfolgenspalte, die Werte aufnehmen kann. Fabric Warehouse wird ständig verbessert; Es kann jedoch zu einer suboptimalen Leistung kommen, wenn große Zeichenfolgen-Datentypen verwendet werden, insbesondere große Objekte (LOBs). Berücksichtigen Sie z. B. für den Datentyp einer customer_name Spalte Ihre Geschäftsanforderungen und erwarteten Daten, und verwenden Sie beim Deklarieren varchar(n)eine geeignete Längen, z. B. varchar(100), anstelle von varchar(8000) oder varchar(max). Statistiken und Abfragekostenschätzungen sind genauer, wenn die Länge des Datentyps für die tatsächlichen Daten genauer ist.

  • Informationen zum Auswählen der geeigneten Länge für Zeichenfolgendatentypen finden Sie in Fabric Data Warehouse T-SQL.
  • Lakehouse-Tabellenspalten vom Typ String ohne definierte Länge in Spark werden von Fabric Warehouse als varchar(8000) erkannt. Verwenden Sie für eine optimale Leistung die CREATE TABLE Anweisung in SparkSQL, um die Zeichenfolgenspalte zu varchar(n)definieren, wobei n die maximale Spaltenlänge für Werte geeignet ist.

Transaktionen und Parallelität

Fabric Data Warehouse basiert auf einer modernen, cloud-nativen Architektur, die transaktionsbezogene Integrität, Snapshotisolation und verteilte Rechenleistung kombiniert, um hohe Parallelität und Konsistenz in großem Maßstab bereitzustellen. Weitere Informationen finden Sie unter "Transaktionen in Lagertabellen".

Fabric Data Warehouse unterstützt ACID-konforme Transaktionen mithilfe der Snapshotisolation. Dies bedeutet:

  • Lese- und Schreibvorgänge können mit standard T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK) in eine einzelne Transaktion gruppiert werden.
  • All-or-Nothing-Semantik: Wenn eine Transaktion mehrere Tabellen umfasst und ein Vorgang fehlschlägt, wird die gesamte Transaktion zurückgesetzt.
  • Lesekonsistenz: SELECT Abfragen innerhalb einer Transaktion sehen eine konsistente Momentaufnahme der Daten, die nicht durch gleichzeitige Schreibvorgänge beeinträchtigt sind.

Unterstützung von Fabric Warehouse-Transaktionen:

  • Data Definition Language (DDL) innerhalb von Transaktionen: Sie können CREATE TABLE in einen Transaktionsblock einschließen.
  • Datenbankübergreifende Transaktionen: Unterstützt innerhalb desselben Arbeitsbereichs, einschließlich Lesevorgängen von SQL Analytics-Endpunkten.
  • Parquet-basierter Rollback: Da Fabric Data Warehouse Daten in unveränderlichen Parquet-Dateien speichert, sind Rollbacks schnell. Rollbacks kehren einfach zu früheren Dateiversionen zurück.
  • Automatische Datenkomprimierung und Prüfpunkterstellung:Die Datenkomprimierung optimiert die Speicher- und Leseleistung, indem kleine Parkettdateien zusammengeführt und logisch gelöschte Zeilen entfernt werden.
  • Automatische Prüfpunkterstellung: Jeder Schreibvorgang (INSERT, UPDATE, DELETE) fügt eine neue JSON-Protokolldatei an das Delta Lake-Transaktionsprotokoll an. Im Laufe der Zeit kann dies zu Hunderten oder Tausenden von Protokolldateien führen, insbesondere in Streaming- oder Hochfrequenzaufnahmeszenarien. Die automatische Prüfpunkterstellung verbessert die Effizienz der Metadatenlesebarkeit, indem Transaktionsprotokolle in einer einzigen Prüfpunktdatei zusammengefasst werden. Ohne Checkpointing muss jeder Lesevorgang den gesamten Transaktionsprotokollverlauf durchsuchen. Bei der Prüfpunkterstellung werden nur die aktuellste Prüfpunktdatei und die Protokolle danach gelesen. Dadurch wird die E/A- und Metadatenanalyse erheblich reduziert, insbesondere bei großen oder häufig aktualisierten Tabellen.

Sowohl Komprimierung als auch Prüfpunkte sind entscheidend für die Tabellengesundheit, insbesondere in Langzeitbetrieb oder Umgebungen mit hoher Parallelität.

Nebenläufigkeitskontrolle und Isolation

Fabric Data Warehouse verwendet ausschließlich Snapshotisolation. Versuche, die Isolationsstufe über T-SQL zu ändern, werden ignoriert.

Bewährte Methoden für Transaktionen

  • Verwenden Sie explizite Transaktionen klug. Immer COMMIT oder ROLLBACK. Lassen Sie Transaktionen nicht offen.
    • Halten Sie Transaktionen kurz. Vermeiden Sie lange ausgeführte Transaktionen, die unnötig Sperren aufrechterhalten, insbesondere bei expliziten Transaktionen, die DDLs enthalten. Dies kann zu einem Konflikt mit Anweisungen über SELECT Systemkatalogansichten (wie z. B. sys.tables) führen und Probleme mit dem Fabric-Portal verursachen, das auf Systemkatalogansichten basiert.
  • Fügen Sie Wiederholungslogik mit Verzögerung in Pipelines oder Apps hinzu, um vorübergehende Konflikte zu bewältigen.
    • Verwenden Sie exponentielles Backoff, um Wiederholungsstürme zu vermeiden, die vorübergehende Netzwerkunterbrechungen verschlechtern.
    • Weitere Informationen finden Sie unter Retry Pattern (Wiederholungsmuster).
  • Überwachen Sie Sperren und Konflikte im Lager.

Reduzieren der zurückgegebenen Datasetgrößen

Abfragen mit großen Datenmengen während der Zwischenabfrage-Ausführung oder im endgültigen Abfrageergebnis können mehrere Leistungsprobleme aufweisen. Um die größe des zurückgegebenen Datasets zu verringern, sollten Sie die folgenden Strategien in Betracht ziehen:

  • Die Partitionierung großer Tische im "Lakehouse".
  • Beschränken Sie die Anzahl der zurückgegebenen Spalten. SELECT * kann teuer sein.
  • Beschränken Sie die Anzahl der zurückgegebenen Zeilen. Führen Sie so viele Datenfilter im Lager wie möglich aus, nicht in Clientanwendungen.
    • Versuchen Sie, vor dem Verknüpfen zu filtern, um das Dataset frühzeitig bei der Abfrageausführung zu reduzieren.
    • Filtern Sie frühzeitig vor JOINs nach Spalten mit niedriger Kardinalität, um die Größe großer Datasets zu reduzieren.
    • Spalten mit hoher Kardinalität eignen sich ideal zum Filtern und Verknüpfungen. Diese werden häufig in WHERE Klauseln verwendet und profitieren von Prädikaten, die in früheren Phasen der Abfrageausführung angewendet werden, um Daten auszufiltern.
  • Da in Fabric Data Warehouse Primärschlüssel und eindeutige Schlüsseleinschränkungen nicht erzwungen werden, sind Spalten mit diesen Einschränkungen nicht unbedingt gute Kandidaten für JOINs.

Abfragepläne und Abfragehinweise

In Fabric Data Warehouse generiert der Abfrageoptimierer einen Abfrageausführungsplan, um die effizienteste Methode zum Ausführen einer SQL-Abfrage zu ermitteln. Erweiterte Benutzer könnten erwägen, Abfrageleistungsprobleme mit dem Abfrageplan zu untersuchen oder Abfragehinweise hinzuzufügen.

  • Benutzer können SHOWPLAN_XML in SQL Server Management Studio verwenden, um den Plan anzuzeigen, ohne die Abfrage auszuführen.
  • Optionale Abfragehinweise können einer SQL-Anweisung hinzugefügt werden, um weitere Anweisungen für den Abfrageoptimierer vor der Plangenerierung bereitzustellen. Das Hinzufügen von Abfragehinweisen erfordert erweiterte Kenntnisse von Abfrageworkloads. Daher werden sie in der Regel verwendet, nachdem andere bewährte Methoden implementiert wurden, aber das Problem weiterhin besteht.

Nicht skalierbare Vorgänge

Fabric Data Warehouse basiert auf einer massiv parallelen Verarbeitungsarchitektur (MPP), in der Abfragen über mehrere Computeknoten hinweg ausgeführt werden. In einigen Szenarien ist die Ausführung mit einem einzigen Knoten gerechtfertigt:

  • Die gesamte Ausführung des Abfrageplans erfordert nur einen Computeknoten.
  • Eine Planunterstruktur kann in einen Computeknoten passen.
  • Die gesamte Abfrage oder ein Teil der Abfrage muss auf einem einzelnen Knoten ausgeführt werden, um die Abfragesemantik zu erfüllen. Beispielsweise Vorgänge, TOP globale Sortierung, Abfragen, die Sortierergebnisse aus parallelen Ausführungen erfordern, um ein einzelnes Ergebnis zu erzeugen oder Ergebnisse für den letzten Schritt zu verknüpfen.

In diesen Fällen können Benutzer eine Warnmeldung erhalten: "Ein oder mehrere nicht skalierbare Vorgänge werden erkannt", und die Abfrage kann nach einer langen Ausführung langsam oder fehlschlagen.

  • Erwägen Sie, die Größe des gefilterten Datasets der Abfrage zu verringern.
  • Wenn für die Abfragesemantik keine Ausführung mit einem einzelnen Knoten erforderlich ist, versuchen Sie, einen verteilten Abfrageplan mit FORCE DISTRIBUTED PLAN zu erzwingen, zum Beispiel OPTION (FORCE DISTRIBUTED PLAN);.

Abfragen des SQL-Analyseendpunkts

Sie können den SQL-Analyseendpunkt verwenden, um Lakehouse-Tabellen abzufragen, die mit Spark SQL aufgefüllt wurden, ohne Daten in das Warehouse zu kopieren oder aufzunehmen.

Die folgenden bewährten Methoden gelten für das Abfragen von Lagerdaten im Lakehouse über den SQL-Analyseendpunkt. Weitere Informationen zur Leistung von SQL Analytics-Endpunkten finden Sie unter Überlegungen zur Leistung des SQL Analytics-Endpunkts.

Tipp

Die folgenden bewährten Methoden gelten für die Verwendung von Spark zum Verarbeiten von Daten in einem Lakehouse, das vom SQL-Analyseendpunkt abgefragt werden kann.

Regelmäßige Tabellenwartung für Lakehouse-Tabellen durchführen

In Microsoft Fabric optimiert das Warehouse automatisch Datenlayouts und führt Garbage Collection und Komprimierung durch. Für ein Lakehouse haben Sie mehr Kontrolle über die Tischwartung. Tabellenoptimierung und Vakuumierung sind erforderlich und können die für große Datasets erforderliche Scanzeit erheblich reduzieren. Die Tabellenwartung im Lakehouse erstreckt sich auch auf Verknüpfungen und kann Ihnen dabei helfen, die Leistung dort erheblich zu verbessern.

Optimieren von Lakehouse-Tabellen oder Abkürzungen mit vielen kleinen Dateien

Das Vorhandensein vieler kleiner Dateien erzeugt einen Mehraufwand beim Lesen von Dateimetadaten. Verwenden Sie den Befehl "OPTIMIEREN " im Fabric-Portal oder ein Notizbuch, um kleine Dateien in größere Dateien zu kombinieren. Wiederholen Sie diesen Vorgang, wenn sich die Anzahl der Dateien erheblich ändert.

Um eine Tabelle in einem Fabric Lakehouse zu optimieren, öffnen Sie das Lakehouse im Fabric-Portal. Klicken Sie im Explorer mit der rechten Maustaste auf die Tabelle, und wählen Sie "Wartung" aus. Wählen Sie optionen auf der Seite " Wartungsbefehle ausführen " und dann " Jetzt ausführen" aus.

Lakehouse-Tabellen oder Verknüpfungen in derselben Region abfragen

Fabric verwendet Rechenleistung dort, wo sich die Fabric-Kapazität befindet. Das Abfragen von Daten, z. B. in Ihrem eigenen Azure Data Lake Storage oder in OneLake in einer anderen Region, führt aufgrund der Netzwerklatenz zu einem Leistungsüberhead. Stellen Sie sicher, dass sich Daten in derselben Region befinden. Je nach Ihren Leistungsanforderungen sollten Sie in Erwägung ziehen, nur kleine Tabellen wie Dimensionstabellen in einem Remotebereich beizubehalten.

Filtern Sie Lakehouse-Tabellen und Verknüpfungen in denselben Spalten

Wenn Sie Tabellenzeilen häufig nach bestimmten Spalten filtern, sollten Sie die Tabelle partitionieren.

Die Partitionierung eignet sich gut für Spalten mit geringer Kardinalität oder Spalten mit vorhersagbarer Kardinalität wie Jahren oder Datumsangaben. Weitere Informationen finden Sie im Lakehouse-Lernprogramm – Vorbereiten und Transformieren von Lakehouse-Daten und Laden von Daten mithilfe der Partition in Lakehouse.

Clustering eignet sich gut für Spalten mit hoher Selektivität. Wenn Sie andere Spalten haben, die Sie häufig zum Filtern verwenden, außer zum Partitionieren von Spalten, sollten Sie die Tabelle mithilfe der Optimierung mit der Spark SQL-Syntax ZORDER BYclustern. Weitere Informationen finden Sie unter Optimierung der Delta Lake-Tabelle.

Abfragemetadatenansichten

Weitere Informationen zu den queryinsights Ansichten finden Sie unter Query Insights in Fabric Data Warehouse.

Weitere Informationen zu DMVs des Abfragelebenszyklus finden Sie unter Überwachen von Verbindungen, Sitzungen und Anforderungen mithilfe von DMVs.

Zugehöriger Inhalt