Arbeitsauslastungsübergreifende Tabellenwartung und -optimierung in Microsoft Fabric

Delta-Tabellen in Microsoft Fabric dienen mehreren Verbrauchsmodulen mit jeweils unterschiedlichen Leistungseigenschaften und Optimierungsanforderungen. Dieser Leitfaden bietet ein umfassendes Framework, um zu verstehen, wie Tabellen, die von einem Modul geschrieben wurden, von anderen genutzt werden und wie Tabellenwartungsstrategien entsprechend optimiert werden.

Das Verständnis der Beziehung zwischen Schreibmustern und Leseleistung über verschiedene Engines hinweg ist für die Erstellung effizienter Datenplattformen unerlässlich. Ziel ist es, sicherzustellen, dass Datenhersteller Tabellenlayouts erstellen, die die Leseleistung für nachgeschaltete Verbraucher optimieren, unabhängig davon, ob diese Verbraucher Spark, SQL-Analyseendpunkt, Power BI Direct Lake oder Warehouse verwenden.

Szenariomatrix schreiben und lesen

In der folgenden Tabelle sind die erwarteten Leistungsmerkmale für allgemeine Schreib- und Lesekombinationen zusammen mit empfohlenen Optimierungsstrategien zusammengefasst. Verwenden Sie diese Matrix, um Ihr Szenario zu identifizieren und die relevanten Anleitungen zu verstehen.

Write-Methode	Lesemodul	Erwartete Lücken	Empfohlene Strategie
Spark-Batch	Spark	Keine Lücken	Standardmäßige Spark-Schreibkonfigurationen sind ausreichend.
Spark Batch	SQL-Analyseendpunkt	Keine Lücken	Aktivieren der automatischen Komprimierung und des optimierten Schreibens
Spark-Streaming	Spark	Kleine Dateien möglich	Automatische Komprimierung und Schreiboptimierung mit geplanter OPTIMIERUNG
Spark-Streaming	SQL-Analyseendpunkt	Kleine Dateien und Prüfpunkte	Automatische Komprimierung, Optimierungsschreiben, Aufteilung von Medaillon-Ebenen
Lagerhalle	Spark	Keine Lücken	Vom System verwaltete Optimierung behandelt das Layout
Lagerhalle	SQL-Analyseendpunkt	Keine Lücken	Vom System verwaltete Optimierung behandelt das Layout

Optimale Dateilayouts nach Engine

Unterschiedliche Verarbeitungs-Engines haben unterschiedliche optimale Dateilayouts. Wenn Sie diese Ziele verstehen, können Sie Schreibvorgänge und Wartungsaufträge entsprechend konfigurieren.

Leitfaden für SQL-Analyseendpunkt und Fabric Data Warehouse

Verwenden Sie die folgenden Einstellungen, um eine optimale Leistung mit dem SQL-Analyseendpunkt und Warehouse zu erzielen:

Zieldateigröße: Ca. 400 MB pro Datei
Zeilengruppengröße: Etwa 2 Millionen Zeilen pro Zeilengruppe
V-Reihenfolge: Verbessert die Leseleistung um 10%

Ein Lager verwendet diese Kriterien, um Komprimierungskandidaten zu ermitteln:

Der Tabellendateiaufwand beträgt mehr als 10%
In der Tabelle sind logisch gelöschte Zeilen mehr als 10%
Die Tabellengröße ist größer als 1.024 Zeilen.

Während der Komprimierungsausführung wählt der Prozess Kandidaten basierend auf diesen Kriterien aus:

Jede Datei ist kleiner als 25% der idealen Größe (basierend auf der Zeilenanzahl)
Jede Datei enthält mehr als 20% gelöschte Zeilen.

Spark

Spark ist robust beim Lesen verschiedener Dateigrößen. ** Für optimale Leistung:

Zieldateigröße: 128 MB bis 1 GB je nach Tabellengröße
Zeilengruppengröße: 1 Million bis 2 Millionen Zeilen pro Zeilengruppe
V-Reihenfolge: Für Spark-Leseleistung nicht erforderlich (kann 15-33% Schreibaufwand hinzufügen)

Spark-Lesevorgänge profitieren von der adaptiven Zieldateigröße, die basierend auf der Tabellengröße automatisch angepasst wird:

Tabellen unter 10 GB: 128 MB Ziel
Tabellen mit mehr als 10 TB: Bis zu 1 GB Ziel

Power BI Direct Lake

Optimale Direct Lake-Leistung:

Zielzeilengruppengröße: 8 Millionen oder mehr Zeilen pro Zeilengruppe für optimale Leistung
V-Reihenfolge: Kritisch für 40-60% Verbesserung von Cold-Cache-Abfragen
Dateianzahl: Minimieren der Dateianzahl, um den Transcodierungsaufwand zu verringern
Konsistente Dateigrößen: Wichtig für vorhersehbare Abfrageleistung

Direct Lake-Semantikmodelle sind am besten geeignet, wenn:

Spaltendaten sind V-Ordered für VertiPaq-kompatible Komprimierung.
Zeilengruppen sind groß genug, um eine effiziente Wörterbuchzusammenführung zu ermöglichen.
Löschvektoren werden durch regelmäßige Komprimierung minimiert.

Weitere Informationen finden Sie unter Grundlegendes zur Leistung von Direct Lake-Abfragen.

Spiegelung

Dateien werden durch das automatische Spiegeln basierend auf dem Tabellenspeicherplatz automatisch dimensioniert.

Tabellengröße	Zeilen pro Zeilengruppe	Zeilen pro Datei
Klein (bis zu 10 GB)	2 Mio.	10 Millionen
Mittel (10 GB bis 2,56 TB)	4 Millionen	60 Millionen
Groß (über 2,56 TB)	8 Millionen	80 Millionen

Erstellen von Mustern und Konfigurationen

Spark-Datenschreibmuster

Spark-Schreibvorgänge verwenden die folgenden Standardkonfigurationen:

Konfiguration	Standardwert	Description
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Zieldateigröße für optimierte Schreibvorgänge
`spark.databricks.delta.optimizeWrite.enabled`	Variiert je nach Profil	Aktiviert die automatische Zusammenbauung von Dateien
`spark.databricks.delta.autoCompact.enabled`	Disabled	Aktiviert die Komprimierung nach dem Schreiben
`spark.sql.files.maxRecordsPerFile`	Unbegrenzt	Maximale Anzahl von Datensätzen pro Datei

So konfigurieren Sie Spark-Schreibvorgänge für die nachgelagerte SQL-Verarbeitung:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Weitere Informationen zu Ressourcenprofilen und deren Standardwerten finden Sie unter Konfigurieren von Ressourcenprofilkonfigurationen.

Schreibverfahren im Lager

Warehouse optimiert das Datenlayout während der Schreibvorgänge automatisch:

V-Order ist standardmäßig für die Leseoptimierung aktiviert.
Die automatische Komprimierung wird als Hintergrundprozess ausgeführt.
Die Checkpoint-Verwaltung erfolgt automatisch.

Das Warehouse produziert Dateien, die für den SQL-Verbrauch optimiert sind, ohne manuelle Eingriffe auszuführen. Tabellen, die vom Warehouse geschrieben werden, sind inhärent für SQL-Analyseendpunkt und Warehouse-Lesevorgänge optimiert.

Tabellenwartungsvorgänge

OPTIMIERUNGS-BEFEHL

Der OPTIMIZE Befehl konsolidiert kleine Dateien in größeren Dateien:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Von Bedeutung

Der OPTIMIZE Befehl ist ein Spark SQL-Befehl. Sie müssen sie in Spark-Umgebungen wie Notizbüchern, Spark-Auftragsdefinitionen oder der Lakehouse Maintenance-Schnittstelle ausführen. Der SQL-Analyseendpunkt und der SQL-Abfrage-Editor für Warehouse unterstützen diesen Befehl nicht.

Weitere Informationen finden Sie unter Tabellenkompaktierung.

Automatische Komprimierung

Die automatische Komprimierung wertet den Partitionszustand nach jedem Schreibvorgang aus und löst eine synchrone Optimierung aus, wenn eine Dateifragmentierung erkannt wird.

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Verwenden Sie die automatische Komprimierung für Aufnahmepipelines mit häufigen kleinen Schreibvorgängen (Streaming oder Microbatch), um manuelle Planungen zu vermeiden und Dateien automatisch zu komprimieren.

Automatische Komprimierung und Optimierung von Schreibvorgängen erzeugen in der Regel die besten Ergebnisse, wenn sie zusammen verwendet werden. Durch Optimieren des Schreibvorgangs wird die Anzahl kleiner geschriebener Dateien reduziert, und die automatische Komprimierung behandelt die verbleibende Fragmentierung.

Weitere Informationen finden Sie unter "Automatische Komprimierung".

Optimieren des Schreibvorgangs

Optimieren Sie den Schreibaufwand für kleine Dateien, indem Sie eine Vorabschreibkomprimierung durchführen, wodurch weniger, größere Dateien generiert werden:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optimieren von Schreibvorgängen ist von Vorteil für:

Partitionierte Tabellen
Tabellen mit häufigen kleinen Einfügungen
Vorgänge, die viele Dateien berühren (MERGE, UPDATE, DELETE)

Die Pre-Write-Komprimierung (Optimieren des Schreibvorgangs) ist im Allgemeinen weniger kostspielig als die Nachschreibkomprimierung (Optimieren). Weitere Informationen finden Sie unter Optimieren des Schreibvorgangs.

VAKUUM-Befehl

Mit dem VACUUM Befehl werden alte Dateien entfernt, auf die ein Delta-Tabellenprotokoll nicht mehr verweist:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Der Standardaufbewahrungszeitraum ist 7 Tage. Das Festlegen kürzerer Aufbewahrungszeiträume wirkt sich auf die Zeitreisefunktionen von Delta aus und kann Probleme mit gleichzeitigen Lesern oder Autoren verursachen.

Weitere Informationen finden Sie unter Lakehouse-Tabellenwartung.

V-Order-Optimierung

V-Order ist eine Schreibzeitoptimierung, die VertiPaq-kompatible Sortier-, Codierungs- und Komprimierung auf Parkettdateien anwendet:

Power BI Direct Lake: 40-60% Verbesserung von Cold-Cache-Abfragen
SQL Analytics-Endpunkt und Warehouse: Ca. 10% Verbesserung der Lesegeschwindigkeit
Spark: Kein inhärenter Lesevorteil; 15-33% langsamere Schreibvorgänge

Wann soll V-Order aktiviert werden?

V-Order bietet den größten Vorteil für:

Goldschichttabellen, die Power BI Direct Lake bedienen
Tabellen, die häufig über den SQL-Analyseendpunkt abgefragt werden
Leseintensive Arbeitslasten, bei denen die Schreibleistung weniger kritisch ist

Wann man V-Order vermeiden sollte

Deaktivieren Sie die V-Order-Funktion für:

Bronzeschichttabellen, die sich auf die Aufnahmegeschwindigkeit konzentrieren
Spark-to-Spark-Pipelines, bei denen SQL und Power BI die Daten nicht nutzen
Schreibintensive Workloads, bei denen die Datenlatenz kritisch ist

V-Reihenfolge konfigurieren

V-Order ist in neuen Fabric-Arbeitsbereichen standardmäßig deaktiviert. Zum Aktivieren:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Um V-Order basierend auf dem Verbrauch von Direct Lake selektiv anzuwenden, sollten Sie die Automatisierung der V-Order-Aktivierung für Tabellen in semantischen Direct Lake-Modellen in Betracht ziehen. Tabellen, die von Direct Lake nicht genutzt werden, können ohne V-Order beibehalten werden, um eine bessere Schreibleistung zu erzielen.

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

Flüssigkeitsclustering und Z-Reihenfolge

Flüssigkeits-Clusterbildung

Liquid Clustering ist der empfohlene Ansatz für die Datenorganisation. Im Gegensatz zur herkömmlichen Partitionierung: Liquid Clustering:

Passt sich an das Ändern von Abfragemustern an.
Erfordert OPTIMIZE, um Clustering anzuwenden
Bietet ein besseres Überspringen von Dateien für gefilterte Abfragen.

Liquid Clustering beim Erstellen der Tabelle aktivieren:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-Reihenfolge

Z-Order platziert verwandte Daten in denselben Dateien, sodass Sie eine bessere Abfrageleistung bei Filterprädikaten erhalten.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Verwenden Sie Z-Reihenfolge, wenn:

Ihre Tabelle ist partitioniert, da Liquid Clustering nicht mit partitionierten Tabellen funktioniert.
Ihre Abfragen filtern häufig nach zwei oder mehr Spalten.
Ihre Prädikate sind selektiv genug, um von dem Überspringen von Dateien zu profitieren.

Empfehlungen für die Medallion-Architektur

Die Medallion-Architektur (Bronze, Silber, Gold-Schichten) bietet einen Rahmen für die Optimierung von Tabellenwartungsstrategien basierend auf dem Zweck jeder Schicht.

Bronzeschicht (Landezone)

Bronzetabellen fokussieren sich auf Schreibgeschwindigkeit und niedrige Latenz bei der Datenaufnahme.

Optimierungspriorität: Erfassungsgeschwindigkeit statt Leseleistung
Partitionierung: Akzeptabel, aber für neue Implementierungen abgeraten
Kleine Dateien: Akzeptabel, da der Fokus auf die Aufnahmegeschwindigkeit liegt
V-Reihenfolge: Nicht empfohlen (zusätzlichen Schreibaufwand)
Automatische Komprimierung: Dies ermöglicht die Verringerung kleiner Dateien, kann jedoch zugunsten der Eingabegeschwindigkeit geopfert werden.
Löschvektoren: Aktivierung für Tabellen mit Zusammenführungsmustern

Bronzetabellen sollten nicht direkt für SQL-Analyseendpunkt oder Power BI Direct Lake-Verbraucher bereitgestellt werden.

Silberschicht (kuratierte Zone)

Silbertabellen balancieren Schreib- und Leseleistung.

Optimierungspriorität: Balance zwischen Aufnahme und Abfrageleistung
Dateigrößen: Moderat (128-256 MB) zur Unterstützung von Schreib- und Lesevorgängen
V-Order: Optional; aktivieren, wenn der SQL-Analyseenpunkt oder die Power BI-Nutzung erheblich ist.
Liquid Clustering oder Z-Order: Empfohlen, um die Abfrageleistung zu verbessern
Automatische Komprimierung und Schreiboptimierung: Aktivieren basierend auf nachgeschalteten Anforderungen
Löschvektoren: Aktivieren von Tabellen mit häufigen Aktualisierungen
Geplante OPTIMIERUNG: Aggressiv ausführen zur Erhaltung des Dateilayouts

Goldschicht (Dienstzone)

Gold-Tabellen priorisieren die Lesegeschwindigkeit für die Nutzung durch Endbenutzer.

Optimierungspriorität: Leseleistung für Analysen
Dateigrößen: Groß (400 MB bis 1 GB) für optimale SQL- und Power BI-Leistung
V-Order: Erforderlich für Power BI Direct Lake; vorteilhaft für SQL-Analyseendpunkt
Liquid Clustering: Erforderlich für optimales Dateiüberspringen
Schreiben optimieren: Erforderlich für konsistente Dateigrößen
Geplante OPTIMIERUNG: Aggressives Ausführen, um ein optimales Layout aufrechtzuerhalten

Optimieren Sie Goldtabellen anders basierend auf der Primären Verbrauchs-Engine.

Verbrauchsmotor	V-Reihenfolge	Größe der Zieldatei	Zeilengruppengröße
SQL-Analyseendpunkt	Ja	400 MB	2 Millionen Zeilen
Power BI Direct Lake	Ja	400 MB bis 1 GB	8+ Millionen Zeilen
Spark	Wahlfrei	128 MB bis 1 GB	1-2 Millionen Zeilen

Mehrere Tabellenkopien

Es ist akzeptabel, mehrere Kopien von Tabellen beizubehalten, die für unterschiedliche Verbrauchsmuster optimiert sind:

Ein silberner Tisch, der für die Spark-Verarbeitung optimiert ist
Eine Gold-Tabelle, die für SQL-Analyseendpunkt und Power BI Direct Lake optimiert ist
Datenpipelinen, die die richtige Struktur auf jeder Ebene transformieren und platzieren

Speicher ist kostengünstig, verglichen mit den Berechnungskosten. Das Optimieren von Tabellen für ihre Verbrauchsmuster bietet eine bessere Benutzererfahrung als den Versuch, alle Verbraucher aus einem einzigen Tabellenlayout zu bedienen.

Ermittlung der Tabellengesundheit

Bevor Sie Tabellen optimieren, bewerten Sie den aktuellen Tabellenzustand, um den Optimierungsbedarf zu verstehen.

Parquet-Dateien direkt prüfen

Sie können den Tabellenordner in OneLake durchsuchen, um die Größen einzelner Parkettdateien zu prüfen. Gesunde Tabellen weisen gleichmäßig verteilte Dateigrößen auf. Suchen nach:

Konsistente Dateigrößen: Dateien sollten ungefähr die gleiche Größe haben (innerhalb von 2x voneinander).
Keine extrem kleinen Dateien: Dateien unter 25 MB deuten auf Fragmentierung hin.
Keine extrem großen Dateien: Dateien über 2 GB können die Parallelität reduzieren.

Ungleiche Dateigrößenverteilung zeigt häufig fehlende Komprimierungs- oder inkonsistente Schreibmuster für verschiedene Aufträge an.

Testlauf optimieren in Spark SQL

Verwenden Sie die DRY RUN Option, um eine Vorschau anzuzeigen, welche Dateien für die Optimierung geeignet sind, ohne die Komprimierung auszuführen:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Der Befehl gibt eine Liste von Dateien zurück, die während der Optimierung neu geschrieben werden würden. Verwenden Sie dies, um:

Bewerten Sie den Umfang der Optimierung, bevor Sie sie ausführen.
Verstehen der Dateifragmentierung, ohne die Tabelle zu ändern.
Schätzen Sie die Optimierungszeit basierend auf der Anzahl der betroffenen Dateien.

Dateigrößenverteilung

Verwenden Sie den folgenden Ansatz, um Dateigrößen und Verteilung zu analysieren:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Die Verteilung kann schief sein, da Dateien in der Nähe des Tabellenkopfs oder von einer bestimmten Partition möglicherweise nicht optimiert werden.

Sie können die Verteilung bewerten, indem Sie eine Abfrage ausführen, die durch die Partitionierungs- oder Clusterschlüssel der Tabelle gruppiert wird.

Ermitteln der Optimierungsanforderungen

Vergleichen Sie basierend auf dem Verbrauchsmodul die tatsächlichen Dateigrößen mit Zielgrößen:

Engine	Größe der Zieldatei	Wenn Dateien kleiner sind	Wenn Dateien größer sind
SQL-Analyseendpunkt	400 MB	Führen Sie `OPTIMIZE` aus.	Dateien sind zulässig
Power BI Direct Lake	400 MB bis 1 GB	Führen Sie `OPTIMIZE VORDER` aus.	Dateien sind akzeptabel
Spark	128 MB bis 1 GB	Automatische Komprimierung aktivieren	Dateien werden akzeptiert

Tabellenverlauf und Transaktionsprotokoll

Überprüfen Sie den Tabellenverlauf, um Schreibmuster und Wartungshäufigkeit zu verstehen:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Bewährte Methoden für die Konfiguration

Verwenden Sie Tabelleneigenschaften anstelle von Sitzungskonfigurationen

Tabelleneigenschaften bleiben sitzungsübergreifend erhalten und sorgen für ein konsistentes Verhalten für alle Aufträge und Autoren:

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Konfigurationen auf Sitzungsebene gelten nur für die aktuelle Spark-Sitzung und können zu inkonsistenten Schreibvorgängen führen, wenn unterschiedliche Sitzungen unterschiedliche Konfigurationen verwenden.

Adaptive Zieldateigröße aktivieren

Die Größe der adaptiven Zieldatei passt die Dateigröße automatisch basierend auf der Tabellengröße an:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Mithilfe dieser Funktion

Beginnt mit kleineren Dateien (128 MB) für kleine Tabellen
Skaliert bis zu 1 GB für Tabellen mit mehr als 10 TB
Automatisch während der OPTIMIZE-Operationen neu ausgewertet.

Aktivieren von Komprimierungszielen auf Dateiebene

Vermeiden Sie das Neuschreiben zuvor komprimierter Dateien, wenn sich die Zielgrößen ändern:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Zusammenfassung der Empfehlungen

Ebene	Automatische Komprimierung	Optimieren des Schreibvorgangs	V-Reihenfolge	Flüssigkeits-Clusterbildung	Geplante Optimierung
Bronze	Aktivieren (optional)	Aktivieren	Nein	Nein	Wahlfrei
Silber	Aktivieren	Aktivieren	Wahlfrei	Ja	Aggressive
Gold	Aktivieren	Aktivieren	Ja	Ja	Aggressive

Verwenden Sie für bestimmte Szenarien die folgenden Empfehlungen:

Spark-to-Spark: Konzentrieren Sie sich auf die Optimierung der Dateigröße; V-Order optional.
Spark-to-SQL: Aktivieren Sie die Funktionen "optimize-write" und "auto-compaction"; zielen Sie auf Dateien mit 400 MB und 2 Millionen Zeilengruppen ab.
Streaming-Ingestion: Automatische Komprimierung aktivieren; zusätzliche OPTIMIZE Aufträge für SQL-Consumer einplanen.
Power BI Direct Lake: V-Order aktivieren; Ziel von 8+ Millionen Zeilengruppen; run OPTIMIZE VORDER.

Feedback

War diese Seite hilfreich?

Last updated on 2026-02-13