OPTIMIZE und VACUUM sind die beiden Wartungs-Befehle für Tabellen im Delta-Lake-Format (das offene Speicherformat, das eine Datenbank-Tabelle auf viele einzelne Dateien im Cloud-Speicher abbildet). OPTIMIZE fasst viele kleine Datei-Fragmente einer Tabelle zu wenigen größeren Dateien zusammen, damit Abfragen schneller werden. VACUUM löscht alte, nicht mehr benötigte Dateien nach Ablauf einer einstellbaren Frist endgültig aus dem Cloud-Speicher und gibt den belegten Platz frei.
Was sind OPTIMIZE und VACUUM?
OPTIMIZE ist ein SQL-Befehl (OPTIMIZE <table>), der die vielen kleinen Datendateien einer Delta-Tabelle zu wenigen großen Zieldateien zusammenfasst, ein Aufräum-Vorgang, den Delta „Bin-Packing" nennt (die Fragmente werden in größere „Kisten" gepackt). Wie groß eine Zieldatei sein soll, ist pro Tabelle einstellbar (delta.targetFileSize); der Databricks-Standard liegt bei rund 1 GB. Mit dem Zusatz ZORDER BY (spalte1, spalte2, …) sortiert OPTIMIZE die Daten zusätzlich innerhalb der Dateien nach den genannten Spalten (Z-Ordering, ein mehrdimensionales Sortier-Verfahren), sodass eine Abfrage später mehr Dateien komplett überspringen kann. Auf Tabellen mit Liquid Clustering (ein neueres, automatisch nachziehendes Sortier-Verfahren) läuft dieselbe Sortierung automatisch mit; ein separater CLUSTER BY-Zusatz im OPTIMIZE-Statement entfällt.
VACUUM (VACUUM <table>) ist das Cleanup-Kommando desselben Formats. Es löscht Parquet-Dateien aus dem Objektspeicher, die von keiner Tabellenversion innerhalb der Aufbewahrungsfrist mehr referenziert werden. Die Frist ist über die Tabellen-Eigenschaft delta.deletedFileRetentionDuration einstellbar; der Delta-Default beträgt 168 Stunden (7 Tage). Kürzere Fristen erzwingen das Spark-Flag spark.databricks.delta.retentionDurationCheck.enabled=false, weil parallele Reader in offenen Sessions Dateien referenzieren können, die VACUUM bei zu kurzer Frist löschen würde.
Beide Kommandos schreiben Einträge in das Delta Transaction Log, sind aber vom Schreibpfad einer Nutz-Query getrennt und laufen als eigene Wartungs-Jobs. OPTIMIZE beseitigt das Small-Files-Problem, das durch Streaming-Ingest, Micro-Batches oder MERGE-Läufe entsteht, und reduziert damit die Metadaten-Last für Query-Engines. VACUUM ist der einzige Weg, um belegten Objektspeicher tatsächlich freizugeben und markierte Löschungen (etwa aus Deletion Vectors oder DSGVO-Löschprozessen) physisch aus dem Storage zu entfernen. OPTIMIZE allein schreibt neue Dateien; die alten Versionen bleiben bis zum nächsten VACUUM erhalten.
Abgrenzung zu Predictive Optimization, Liquid Clustering, Deletion Vectors und Optimized Writes
OPTIMIZE und VACUUM werden häufig mit Funktionen aus derselben Wartungs-Familie vermischt, die entweder dieselben Operationen automatisieren oder an anderer Stelle der Delta-Mechanik ansetzen.
| Begriff | Konzept | Verhältnis zu OPTIMIZE/VACUUM |
|---|---|---|
| Predictive Optimization (Databricks) | Plattform-Dienst, der Wartung asynchron auf Serverless-Compute plant | Ersetzt den Betriebsplan durch einen eigenen Scheduler; die ausgeführten Delta-Kommandos bleiben OPTIMIZE, VACUUM und Re-Clustering. |
| Liquid Clustering | Data-Layout-Feature per CLUSTER BY | Kein Wartungs-Kommando, sondern eine Schema-Entscheidung. Das Cluster-Layout entsteht erst durch OPTIMIZE (oder Predictive Optimization). |
| Deletion Vectors | Merge-on-Read-Bitmap, die gelöschte Zeilen markiert | Endgültige Löschung erfordert einen Rewrite (OPTIMIZE mit optimizeWrite=true oder REORG TABLE … APPLY (PURGE)) plus anschließendes VACUUM nach Ablauf der Aufbewahrungsfrist. |
| Optimized Writes / Auto Compaction | Schreib-seitige Bündelung kleiner Dateien im Ingest-Pfad | Reduziert den Umfang späterer OPTIMIZE-Läufe; kein Äquivalent zu VACUUM und keine Z-Order- oder Liquid-Layout-Wirkung. |
Der zentrale Unterschied zu Predictive Optimization liegt im Steuerungs-Modell. OPTIMIZE und VACUUM sind die Delta-Kommandos selbst und laufen in dem Rhythmus, den ein Workflow (Databricks Jobs, Airflow, Azure Data Factory) vorgibt. Predictive Optimization übernimmt die Zeitplanung auf Unity-Catalog-verwalteten Tabellen und entscheidet pro Tabelle, wann eine Operation den erwarteten Nutzen rechtfertigt; die Delta-Mechanik dahinter ist identisch.
Die Abgrenzung zu Deletion Vectors ist wichtig, weil sie den Zeitpunkt der physischen Löschung verschiebt. Ein DELETE mit Deletion Vectors ergänzt eine Bitmap und ist logisch abgeschlossen, sobald der Commit geschrieben ist; die betroffenen Zeilen liegen aber weiterhin in der ursprünglichen Parquet-Datei. Erst ein materialisierender Rewrite (OPTIMIZE oder REORG TABLE … APPLY (PURGE)) plus anschließendes VACUUM entfernt die Zeilen endgültig aus dem Storage.
Beispiel: Nächtliche Wartung einer Silver-Tabelle mit MERGE-Ingest
Eine Silver-Tabelle im Delta-Lake-Format nimmt stündlich MERGE-Ladungen aus einer CDC-Strecke auf. Im Tagesverlauf entstehen mehrere hundert kleine Parquet-Dateien, weil jeder MERGE eigene Datendateien schreibt. Ein nächtlicher Wartungs-Job führt zunächst OPTIMIZE aus, um die Dateien auf die Zieldateigröße zu verdichten:
OPTIMIZE silver.orders ZORDER BY (customer_id);
Auf einer Liquid-Clustering-Tabelle entfällt das ZORDER BY, das Cluster-Layout wird automatisch nachgeführt. Nach OPTIMIZE laufen die Query-Engines auf einer geringeren Anzahl größerer Dateien, die belegte Datenmenge im Objektspeicher hat sich aber vorerst erhöht: Die alten kleinen Dateien liegen weiter im Storage und werden für Time Travel und für parallele Reader vorgehalten.
Im zweiten Schritt räumt VACUUM auf und gibt den durch die Kompaktierung freigewordenen Speicher frei:
VACUUM silver.orders RETAIN 168 HOURS;
Die Time-Travel-Reichweite beträgt danach sieben Tage. Kürzere Fristen wären möglich, erhöhen aber das Risiko, dass laufende Reader Dateien referenzieren, die VACUUM entfernt hat. Auf einer Unity-Catalog-verwalteten Tabelle ersetzt Predictive Optimization den festen Schedule; die Plattform triggert OPTIMIZE und VACUUM asynchron, sobald die Datei-Fragmentierung oder der Anteil obsoleter Dateien den erwarteten Compute-Verbrauch rechtfertigt.
OPTIMIZE und VACUUM im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Wartungsmodell, Aufbewahrungsfrist, Storage-Kosten im Entscheider-Frame
Delta LakeFormat-Grundlagen: Transaction Log, Versionierung, Table Features
Predictive OptimizationAutomatisierung von OPTIMIZE und VACUUM auf Unity-Catalog-Tabellen
Liquid ClusteringData-Layout-Feature, das OPTIMIZE inkrementell nachführt
Deletion VectorsMerge-on-Read-Mechanik, die Rewrite und VACUUM für die endgültige Löschung braucht