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.

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 Lakehouse-SQL-Analyseendpunkte verwenden und verwalten automatisch Histogrammstatistiken, durchschnittliche Spaltenlängenstatistiken 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.

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ührungen. 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 einer Zeit der Inaktivität automatisch an, um die Kosten zu reduzieren, und fügt Knoten als Teil der Autoskalierung 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.

Im Fabric Data Warehouse sind das Caching im Speicher und auf der Festplatte vollständig transparent und automatisch aktiviert. Das Zwischenspeichern minimiert intelligent die Notwendigkeit von Lesevorgängen auf Remote-Speicher durch die Nutzung lokaler Caches. Das Fabric Data Warehouse verwendet verfeinerte Zugriffsmuster, um Datenlesevorgänge aus dem Speicher zu verbessern und die Abfrageausführungsgeschwindigkeit zu erhöhen. Weitere Informationen finden Sie unter Caching in der Fabric-Datenverwaltung.

Sie können Kaltstarteffekte erkennen, die durch das Abrufen von Daten aus Remote-storage in den Arbeitsspeicher verursacht werden, indem Sie die Ansicht queryinsights.exec_requests_history 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.

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 neine geeignete Längevarchar(n), 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 den Anleitungen zu T-SQL von Fabric Data Warehouse.
• 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, Momentaufnahmeisolation und verteiltes Computing kombiniert, um hohe Parallelität und Konsistenz in großem Umfang bereitzustellen. Weitere Informationen finden Sie unter "Transaktionen in Lagertabellen".

Fabric Data Warehouse unterstützt ACID-kompatible 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 das Fabric Data Warehouse Daten in unveränderlichen Parquet-Dateien speichert, erfolgen Rollbacks schnell. Rollbacks kehren einfach zu früheren Dateiversionen zurück.
• Automatische Datenkomprimierung und Prüfpunkterstellung:Datenkomprimierung optimiert Speicher und Leseleistung, indem kleine Parquet-Dateien 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 Erstellung von Prüfpunkten werden nur die neuesten Prüfpunkten-Dateien sowie die nachfolgenden Protokolle 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 behandeln.
  • Verwenden Sie exponentielles Backoff, um Wiederholungsstürme zu vermeiden, die vorübergehende Netzwerkunterbrechungen verschlechtern.
  • Weitere Informationen finden Sie unter Retry-Muster.
• Überwachen Sie Sperren und Konflikte im Lager.
  • Verwenden Sie sys.dm_tran_locks , um aktuelle Sperren zu prüfen.

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:

• Partition oder Cluster (Liquid Clustering) große Tische in 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.

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, führt zu einem Leistungsaufwand aufgrund der Netzwerklatenz. 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.

Datenclustering

Sie können auch Datenclustering für bestimmte Spalten in den CREATE TABLE- und CREATE TABLE AS SELECT-T-SQL-Anweisungen (CTAS) durchführen. Das Datenclustering funktioniert, indem Zeilen mit ähnlichen Werten während der Speicherung an benachbarten Orten im Speicher gespeichert werden.

• Datenclustering verwendet eine Raumfüllkurve, um Daten so zu organisieren, dass die Lokalität über mehrere Dimensionen hinweg erhalten bleibt, was bedeutet, dass Zeilen mit ähnlichen Werten über Clusterspalten physisch nahe beieinander gespeichert werden. Dieser Ansatz verbessert die Abfrageleistung erheblich, indem Dateien übersprungen und die Anzahl der gescannten Dateien reduziert wird.
• Metadaten des Datenclusterings werden bei der Aufnahme in das Manifest integriert, sodass das Warehousing-Modul intelligente Entscheidungen darüber treffen kann, auf welche Dateien während Benutzerabfragen zugegriffen werden soll. Diese Metadaten, kombiniert mit der Gemeinsamen Speicherung von Zeilen mit ähnlichen Werten, stellt sicher, dass Abfragen mit Filter-Prädikaten ganze Dateien und Zeilengruppen überspringen können, die außerhalb des Prädikatbereichs liegen.

Beispiel: Wenn eine Abfrage nur auf 10% der Daten einer Tabelle ausgerichtet ist, wird durch Clustering sichergestellt, dass nur Dateien, die die Daten im Bereich des Filters enthalten, gescannt werden, wodurch die E/A-Auslastung reduziert wird. Größere Tabellen profitieren mehr vom Datenclustering, da die Vorteile des Dateiskippings mit dem Datenvolumen skalieren.

• Vollständige Informationen zum Datenclustering finden Sie unter Data clustering in Fabric Data Warehouse.
• Ein Lernprogramm zur Datenclustering und zum Messen ihrer positiven Auswirkungen auf die Leistung finden Sie unter Use data clustering in Fabric Data Warehouse.

Optimierung des Datentyps

Die Auswahl der richtigen Datentypen ist für die Leistung und storage Effizienz in Ihrem Lager unerlässlich. Die folgenden Richtlinien tragen dazu bei, dass Ihr Schemadesign schnelle Abfragen, effiziente storage und Wartung unterstützt.

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

Zuordnen von Datentypen zur Datensemantik

Um sowohl die Klarheit als auch die Leistung sicherzustellen, ist es wichtig, dass der Datentyp jeder Spalte auf die tatsächliche Art und das Verhalten der gespeicherten Daten abgestimmt wird.

• 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. Ganzzahltypen erfordern weniger Speicher als Datentypen, die Stellen nach dem Dezimalkomma erlauben. 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 Präzision der Überbereitstellung erhöht die Speicheranforderungen und kann die Leistung beeinträchtigen, wenn die Daten zunehmen.

• Antizipieren Sie das erwartete Wachstum und die Bedürfnisse Ihres Lagers. Wenn Sie beispielsweise nicht mehr als vier Ziffern rechts neben dem Dezimalkomma speichern möchten, verwenden Sie decimal(9,4) oder decimal(19,4) für die effizienteste storage.
• 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 (p,s) anzugeben, wird eine dezimale/numerische Spalte als decimal(18,0)erstellt. Eine decimal mit einer Genauigkeit von 18 verbraucht 9 Byte storage 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 integer Datentyp für 4 Byte storage 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 Spaltendatentypdeklaration ist die Speicher-Bytes. Bei Multibyte-Codierungszeichensätzen wie UTF-8 benötigen lateinische Zeichen und Zahlen im Fabric Data Warehouse 1 Byte Speicherplatz. 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 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 in Kombination mit SELECT FROM Lakehouse-Tabellen-/Shortcut-Befehlen. 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 Funktion OPENROWSET können Sie CSV- oder Parquet-Dateien aus Azure Data Lake oder Azure Blob Storage lesen, ohne sie in Warehouse aufzunehmen. Weitere Informationen und Beispiele finden Sie unter Durchsuchen von Dateiinhalten mithilfe der OPENROWSET-Funktion.

Weitere Informationen und Beispiele zum Abfragen externer Daten finden Sie unter Externe Data-Lake-Dateien mit Fabric Data Warehouse oder SQL Analytics Endpoint abfragen.

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, UPDATE und DELETE 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 Rechenkosten.
• Größere Abhängigkeit von Hintergrundkomprimierungsprozessen.

Empfohlene Ansätze:

• Batchtransaktionen, die in 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

In Fabric Data Warehouse ist die Datenkomprimierung ein Prozess der Hintergrundoptimierung, bei dem kleine, ineffiziente Parkettdateien in weniger, größere Dateien zusammengeführt werden. 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 Datenverdichtung automatisch beseitigt, kann die Leistung nachlassen, 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 welche über SQL-Analyseendpunkte zugegriffen wird, ist es wichtig, die bewährten Methoden von Lakehouse zu befolgen und den Befehl OPTIMIZE nach signifikanten Datenänderungen auszuführen, um ein optimales Speicherlayout zu erhalten.

Datenkomprimierungsunterbrechung

Fabric Data Warehouse verhindert intelligent und aktiv Schreib-Schreib-Konflikte zwischen Hintergrundkomprimierungsaufgaben und Benutzervorgängen. Ab Oktober 2025 ist die Datenkompaktierungspräemption aktiviert.

Komprimierungsprüfungen für freigegebene Sperren, die von Benutzerabfragen gehalten werden. Wenn die Datenkomprimierung eine Sperre erkennt, bevor sie beginnt, wartet sie und versucht es später erneut. Wenn die Datenkomprimierung gestartet wird und eine Sperre erkennt, bevor ein Commit ausgeführt wird, wird die Komprimierung abgebrochen, um einen Schreibkonflikt mit der Benutzerabfrage zu vermeiden.

Schreibkonflikte mit dem Fabric-Data Warehouse Hintergrunddatenkomprimierungsdienst sind weiterhin möglich. Es ist möglich, einen Schreib-Schreib-Konflikt mit Datenkomprimierung zu erzeugen, beispielsweise wenn eine Anwendung eine explizite Transaktion verwendet und nicht-konfliktbehaftete Arbeiten (wie INSERT) vor einer konfliktbehafteten Aktion (UPDATE, DELETE, MERGE) ausführt. Die Datenkomprimierung kann erfolgreich ausgeführt werden, sodass die explizite Transaktion später aufgrund eines Konflikts fehlschlägt. Weitere Informationen zu Schreib- oder Aktualisierungskonflikten finden Sie unter Transactions in Warehouse-Tabellen in Microsoft Fabric.

V-Reihenfolge im Fabric-Datenlager

V-Order ist eine Schreibzeitoptimierung für 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 ist die Verwendung eines Staging-Depots mit deaktiviertem V-Order für die Verarbeitung bei hohem Durchsatz, die Datentransformation und das Einpflegen der zugrunde liegenden Daten in ein aktiviertes V-Order-bereitgestelltes Data Warehouse, um eine bessere Leseleistung zu erzielen. Weitere Informationen finden Sie unter V-Order in Microsoft Fabric-Warehouse deaktivieren.

Klonen von Tabellen anstelle des Kopierens von Tabellen

Table-Klonen 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-Klone eignen sich ideal für Szenarien wie Entwicklung, Tests und Datensicherung, da sie eine leistungsstarke, 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.

Abfragemetadatenansichten

• Abfrageausführungsverlauf (30 Tage)

  • queryinsights.exec_requests_history
  • queryinsights.exec_sessions_history

• Aggregierte Einblicke

  • queryinsights.long_running_queries
  • queryinsights.häufig_laufende_abfragen

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

• DMVs des Abfragelebenszyklus
  • sys.dm_exec_connections
  • sys.dm_exec_sessions
  • sys.dm_exec_requests

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

Zugehöriger Inhalt

• Arbeitsauslastungsübergreifende Tabellenwartung und Optimierung
• Delta Lake-Tabellenoptimierung und V-Order
• Tabellenkomprimierung
• Lakehouse-Tabellenwartung
• Monitor Fabric Data warehouse
• Was ist die Microsoft Fabric Capacity Metrics-App?
• Abfrageeinblicke
• Statistiken im Fabric Data Warehouse
• Einspeisen von Daten in Ihr Lager mithilfe der COPY-Anweisung