OPTIMIZE und VACUUM: Das Wartungsmodell, das Delta Lake mitbringt
OPTIMIZE kompaktiert Small Files zu größeren Dateien, VACUUM löscht alte Dateiversionen nach Ablauf der Aufbewahrungsfrist. Wie beide Kommandos zusammenspielen und wer Rhythmus, Frist und Verantwortung festlegt.
Die Kernaussagen auf einen Blick.
- OPTIMIZE fasst kleine Dateien zu größeren Dateien zusammen und verbessert dadurch die Abfrageleistung, VACUUM entfernt alte Dateiversionen nach einer Aufbewahrungsfrist physisch aus dem Storage.
- Die Aufbewahrungsfrist (Standard sieben Tage) beeinflusst gleichzeitig die Speicherkosten, die verfügbare Versionshistorie und den Zeitpunkt der physischen Löschung.
- Vor dem produktiven Betrieb sollten Wartungsrhythmus, Aufbewahrungsfrist und Zuständigkeit für jede Tabellenklasse definiert und mit Lösch-Zusagen und Historien-Bedarf abgeglichen werden.
- Empfehlenswert ist, die Wartung als festen Betriebsplan mit benannter Verantwortung aufzusetzen und für verwaltete Tabellen zu prüfen, ob sich Predictive Optimization zur Automatisierung der Wartung eignet.
Inhaltsverzeichnis
Wenn der Speicherverbrauch schneller wächst als der nutzbare Datenbestand
Eine zentrale Tabelle wird seit sechs Monaten produktiv genutzt und täglich über MERGE aktualisiert. Abfragen, die zu Beginn nur wenige Sekunden benötigten, dauern inzwischen mehrere Minuten. Der belegte Speicher ist inzwischen dreimal so groß wie der aktuell nutzbare Datenbestand. Und im Team ist nicht bekannt, wann zuletzt ein VACUUM-Lauf ausgeführt wurde. Gleichzeitig braucht dieselbe Tabelle ihre Historie für Fehleranalysen, und dem Datenschutz wurde eine Lösch-Frist von 30 Tagen zugesagt.
Diese Situation tritt häufig auf, wenn Delta-Tabellen produktiv genutzt werden, ohne zuvor einen Wartungsprozess festzulegen. Da Delta Lake Änderungen versioniert, entstehen fortlaufend ältere Dateien und Tabellenstände, die regelmäßig bereinigt werden müssen.
Wie oft müssen OPTIMIZE und VACUUM bei uns laufen? Welche Aufbewahrungsfrist passt zu Fehleranalyse und Lösch-Zusagen gleichzeitig? Welche Compute-Kosten verursachen die Wartungsläufe und welche Folgekosten entstehen, wenn sie nicht ausgeführt werden? Und wer verantwortet das: Plattform-Team oder Daten-Team?
OPTIMIZE und VACUUM bilden einen wesentlichen Teil des Wartungsmodells für Delta-Tabellen: Die Kompaktierung reduziert die Anzahl der zu lesenden Dateien und stabilisiert dadurch die Abfrageleistung, und die Aufbewahrungsfrist bestimmt gleichzeitig die Speicherkosten, die verfügbare Versionshistorie und den Zeitpunkt der endgültigen physischen Löschung.
Warum Delta-Tabellen Wartung brauchen
Delta Lake dokumentiert jede Änderung als neue Version der Tabelle. UPDATE- und MERGE-Operationen erzeugen neue Dateien, während ältere Dateien zunächst für die Versionshistorie erhalten bleiben; bei aktivierten Deletion Vectors werden gelöschte Zeilen zunächst lediglich logisch markiert. Dazu kommt das Small-Files-Problem: Häufige kleine Schreibvorgänge aus Streaming-Quellen oder Mikro-Batches erzeugen über Monate Tausende kleiner Dateien, und Abfragen müssen dadurch eine große Anzahl einzelner Dateien und Metadaten verarbeiten.
Beide Effekte entstehen aus der Funktionsweise des Tabellenformats und wachsen mit jedem produktiven Tag. Ohne regelmäßige Wartung verschlechtern sich Performance und Speichereffizienz schrittweise: Die Abfrage-Zeiten steigen, dabei muss kein einzelner klar erkennbarer Fehler auftreten, und die Storage-Kosten wachsen mit jeder Version weiter, obwohl sich die fachlich relevante Datenmenge kaum verändert. Mit OPTIMIZE und VACUUM lässt sich diese Wartung als wiederkehrender Betriebsprozess organisieren: OPTIMIZE verdichtet den Bestand für schnelle Abfragen, VACUUM entfernt nicht mehr benötigte Dateien nach Ablauf der Aufbewahrungsfrist.
Datenqualität, Daten-Layout-Strategie und Zugriffsrechte decken die beiden Kommandos nicht ab; diese Themen müssen unabhängig von OPTIMIZE und VACUUM geregelt werden. Wie das Transaktionslog, die Versionierung und die übrigen Komponenten des Formats zusammenspielen, zeigen wir im Überblick zu Delta Lake.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was leistet OPTIMIZE?
OPTIMIZE fasst zahlreiche kleine Dateien einer Delta-Tabelle zu einer geringeren Anzahl größerer Dateien zusammen (Bin-Packing). Databricks dokumentiert dafür eine Zieldateigröße von rund 1 GB, die sich pro Tabelle anpassen lässt. Die Wirkung zeigt sich direkt in der Abfrageverarbeitung: Abfragen müssen weniger Dateien und Metadaten verarbeiten, was die Laufzeit reduzieren kann, ohne dass am Datenmodell etwas geändert wird.
OPTIMIZE setzt außerdem die gewählte Datenlayout-Strategie um. Bei Z-Ordering ordnet OPTIMIZE die Daten anhand mehrerer ausgewählter Spalten, sodass Abfragen ganze Dateien überspringen können; Liquid Clustering nutzt dafür flexibel anpassbare Clustering-Schlüssel. Welches Layout zu welchem Abfrageprofil passt, klären wir unter Z-Ordering und Liquid Clustering; für das Wartungsmodell zählt, dass beide Verfahren über denselben OPTIMIZE-Lauf ausgeführt werden und damit in denselben Betriebsplan gehören.
OPTIMIZE kann außerdem logisch gelöschte Zeilen aus aktiven Dateien entfernen: Beim Verdichten werden auch Dateien neu geschrieben, in denen viele Zeilen als gelöscht markiert sind. Dadurch werden logische Löschungen bei betroffenen Dateien schrittweise physisch umgesetzt. Für verbindliche Löschprozesse reicht dieser Nebeneffekt jedoch nicht aus, da nicht garantiert ist, dass alle betroffenen Dateien neu geschrieben werden; dazu unten mehr.
Delta Lake bietet zusätzlich zwei Funktionen, die bereits beim Schreiben die Entstehung kleiner Dateien reduzieren: Optimized Writes bündeln Schreibvorgänge, bevor die Dateien angelegt werden, Auto Compaction fasst kleine Dateien unmittelbar nach einem Schreibvorgang zusammen; beides ist im Open-Source-Format seit Delta 3.1 verfügbar. Für Tabellen mit Streaming-Eingang oder häufigen Mikro-Batches können diese Funktionen den Umfang späterer OPTIMIZE-Läufe reduzieren. Einen regelmäßigen Wartungsprozess ersetzen sie jedoch nicht: Layout-Läufe und das Aufräumen alter Versionen bleiben Aufgaben der geplanten Wartung.
OPTIMIZE-Läufe verursachen ihrerseits Compute-Kosten. Ein Lauf liest und schreibt die betroffenen Datenmengen vollständig, und bei großen Tabellen ist das ein relevanter Bestandteil der laufenden Plattformkosten. Die Häufigkeit der Läufe sollte sich deshalb an der Änderungs- und Schreibfrequenz der Tabelle orientieren und in ein Zeitfenster mit günstiger Compute-Auslastung gelegt werden.
Bin-Packing
Viele kleine Dateien werden zu wenigen großen zusammengefasst, Zielgröße rund 1 GB pro Datei, anpassbar je Tabelle.
Daten-Layout
Über denselben Lauf wird Z-Ordering oder Liquid Clustering ausgeführt, damit Abfragen ganze Dateien überspringen können.
Lösch-Bereinigung
Dateien mit vielen als gelöscht markierten Zeilen werden beim Verdichten neu geschrieben, als Nebeneffekt, nicht garantiert für jede Datei.
Write-Time-Vermeidung
Optimized Writes und Auto Compaction verringern schon beim Schreiben die Entstehung kleiner Dateien, ersetzen aber keinen regelmäßigen OPTIMIZE-Lauf.
Was entscheidet die VACUUM-Aufbewahrungsfrist?
VACUUM löscht nicht mehr benötigte Dateien physisch aus dem Objektspeicher: Entfernt werden Dateien, die von keiner noch aufzubewahrenden Tabellenversion benötigt werden. Databricks dokumentiert eine Standard-Frist von sieben Tagen (168 Stunden), einstellbar pro Tabelle über die Eigenschaft delta.deletedFileRetentionDuration. Erst VACUUM gibt den von alten Dateien belegten Speicher tatsächlich frei; OPTIMIZE schreibt zwar neue Dateien, entfernt die älteren Versionen jedoch nicht aus dem Speicher.
Die Aufbewahrungsfrist ist eine der wichtigsten Einstellungen des Wartungsmodells; sie beeinflusst mehrere technische und fachliche Anforderungen gleichzeitig:
| Stellgröße | Kurze Frist (unter 7 Tagen) | Standard 7 Tage | Lange Frist (30+ Tage) |
|---|---|---|---|
| Speicherkosten | gering, da alte Dateien schneller entfernt werden | planbar begrenzt | wachsen mit jeder Version weiter |
| Time-Travel-Reichweite | wenige Tage oder Stunden | bis zu 7 Tage | so weit wie Frist und Log reichen |
| Physische Löschung | sehr zeitnah nach dem VACUUM-Lauf | nach Ablauf der Frist und dem nächsten VACUUM-Lauf | erst nach Wochen oder Monaten |
| Risiko für laufende Leser | hoch bei langen Jobs und Streaming-Lesern | gering bei üblichen Job-Laufzeiten | sehr gering |
Besonders sorgfältig sollte die Auswirkung auf die verfügbare Versionshistorie bewertet werden. Time Travel setzt sowohl die Logeinträge als auch die zugehörigen Datendateien voraus. Die Log-Aufbewahrung steuert delta.logRetentionDuration mit einem Standard von 30 Tagen; die Databricks Knowledge Base beschreibt diese Standard-Konfiguration mit 30 Tagen Log-Aufbewahrung im Zusammenspiel mit der Datei-Frist. Entfernt VACUUM die Datendateien nach sieben Tagen, ist ein Zugriff auf ältere Tabellenstände danach nicht mehr möglich, auch wenn das Log länger aufbewahrt wird. Welche Einsatzfälle die Versionshistorie trägt und wie du frühere Stände wiederherstellst, zeigen wir unter Time Travel.
Warum gelöschte Daten erst nach der Wartung verschwinden
Bei aktivierten Deletion Vectors erfolgt die physische Löschung erst im Rahmen späterer Wartungsschritte. DELETE- oder MERGE-Operationen kennzeichnen betroffene Zeilen zunächst über Deletion Vectors; die ursprünglichen Werte bleiben zunächst in den zugrunde liegenden Datendateien gespeichert. Wie diese Markierungen technisch funktionieren und warum Löschen damit deutlich schneller wird, erklären wir unter Deletion Vectors.
Für die vollständige Löschung sind die nachgelagerten Wartungsschritte entscheidend. OPTIMIZE kann markierte Zeilen beim Neuschreiben aus den aktiven Dateien entfernen; dies erfolgt jedoch nicht zwingend für jede betroffene Datei. Wenn eine verbindliche physische Löschung erforderlich ist, erzwingt REORG TABLE mit PURGE das Neuschreiben aller betroffenen Dateien. Endgültig aus dem Speicher entfernt werden die Daten in beiden Fällen erst, wenn ein anschließender VACUUM-Lauf die alten Dateien nach Ablauf der Aufbewahrungsfrist entfernt.
Die tatsächlich erreichbare Löschfrist ergibt sich aus dem Wartungsrhythmus und der Aufbewahrungsfrist: Sie setzt sich aus der Wartezeit bis zum Neuschreiben der Dateien, der Aufbewahrungsfrist und dem Intervall bis zum nächsten VACUUM-Lauf zusammen. Eine Zusage von 30 Tagen gegenüber dem Datenschutz kann nur eingehalten werden, wenn alle erforderlichen Schritte innerhalb der zugesagten Frist ausgeführt und dokumentiert werden. Ohne definierten Plan bleibt jede gelöschte Zeile so lange im Storage liegen, bis die erforderlichen Wartungsschritte tatsächlich ausgeführt wurden.
Markierung
DELETE- oder MERGE-Operationen kennzeichnen betroffene Zeilen über Deletion Vectors; die Werte bleiben zunächst in den Datendateien gespeichert.
Neuschreiben
OPTIMIZE kann markierte Zeilen beim Verdichten aus aktiven Dateien entfernen, nicht garantiert für jede Datei. Für verbindliche Löschung erzwingt REORG TABLE mit PURGE das Neuschreiben aller betroffenen Dateien.
Aufbewahrungsfrist
Die alten Dateiversionen bleiben erhalten, bis die konfigurierte Aufbewahrungsfrist abgelaufen ist.
Physische Löschung
Ein anschließender VACUUM-Lauf entfernt die alten Dateien endgültig aus dem Speicher. Erst dann ist die Löschung tatsächlich wirksam.
Rhythmus, Frist, Verantwortung
Ein belastbares Wartungsmodell definiert für jede Tabellenklasse drei zentrale Parameter, mit dem Workload-Profil als Maßstab.
Rhythmus
Richtet sich an Schreib- und Änderungsfrequenz: häufig aktualisierte Tabellen brauchen tägliche Läufe in lastarmen Zeitfenstern, ruhige Tabellen kommen mit selteneren Läufen aus.
Frist
Leitet sich aus Historien-Bedarf, Lösch-Zusagen und Speicherbudget ab und wird pro Tabellenklasse bewusst entschieden und als Tabellen-Eigenschaft dokumentiert.
Verantwortung
Zentraler Plattformstandard mit Default-Werten, begründete Abweichungen beim jeweiligen Tabellen-Owner, zentrales Monitoring fehlgeschlagener oder überfälliger Läufe.
Vier Symptome weisen auf einen fehlenden oder unzureichenden Wartungsprozess hin:
- Abfragen auf denselben Tabellen werden über Monate schleichend langsamer
- der Storage wächst schneller als der nutzbare Datenbestand
- die zugesagte Lösch-Frist lässt sich auf Nachfrage des Datenschutzes nicht belegen
- den Zeitpunkt des letzten VACUUM-Laufs kennt niemand im Team
Databricks bietet für einen Teil dieser Aufgaben eine automatisierte Wartung. Predictive Optimization plant und startet OPTIMIZE-, VACUUM- und ANALYZE-Läufe für verwaltete Unity-Catalog-Tabellen automatisch auf Serverless-Compute und ist für neue Konten standardmäßig aktiv. Dadurch muss der genaue Ausführungszeitpunkt nicht für jede Tabelle manuell festgelegt werden; die Wartung wird anhand der Nutzung und des Zustands der Tabelle geplant. Externe Tabellen werden von dieser Automatisierung nicht erfasst, und Aufbewahrungsfristen und zugesagte Löschzeiten müssen weiterhin vom verantwortlichen Team festgelegt werden; im Open-Source-Betrieb außerhalb von Databricks bleibt zudem die gesamte Orchestrierung der Läufe eine eigene Aufgabe.
Grenzen
OPTIMIZE und VACUUM helfen dabei, Abfrageleistung und Speicherverbrauch einer Delta-Plattform kontrollierbar zu halten. Mehrere angrenzende Aufgaben werden durch diese Kommandos jedoch nicht gelöst; diese Themen müssen zusätzlich berücksichtigt werden, damit das Wartungsmodell wirksam ist.
Keine Layout-Strategie
OPTIMIZE führt nur das Daten-Layout aus, das jemand entschieden hat. Ungeeignete Clustering- oder Partitionsschlüssel korrigiert regelmäßige Wartung nicht. Das ist eine eigene Architektur-Frage.
Keine Datenqualität
Eine optimierte Dateistruktur garantiert keine fachlich korrekten Daten. Qualitätsregeln gehören in die Lade-Strecke.
Kein Löschkonzept
Eine technische Aufbewahrungsfrist ersetzt kein organisatorisches und rechtliches Löschkonzept. Welche Daten löschpflichtig sind und wie der Nachweis dokumentiert wird, regelt eine Governance-Schicht oberhalb des Formats.
Keine Entscheidungs-Automatik
Predictive Optimization wählt Zeitpunkte und Kandidaten besser als ein starrer Zeitplan, ersetzt aber nicht die Abwägung zwischen Historien-Bedarf, Lösch-Zusagen und Storage-Budget.
Laufende Compute-Kosten
Die Wartungsläufe selbst sind ein fester Budget-Posten, der mit Datenvolumen und Takt wächst. Ohne Kostenmonitoring drohen unnötig hohe Ausgaben.
Innerhalb dieser Grenzen sind OPTIMIZE und VACUUM ein wesentlicher Faktor dafür, ob eine Delta-Plattform langfristig performant und wirtschaftlich betrieben werden kann. Es arbeitet auf demselben Transaktionslog wie alle anderen Komponenten der Delta-Lake-Gruppe und greift in deren Verhalten ein: in die Reichweite der Historie ebenso wie in den Zeitpunkt, an dem Löschungen wirksam werden.
Der Wartungsprozess sollte deshalb als fester Bestandteil der Plattformarchitektur definiert werden, auf derselben Ebene wie Datenmodell und Berechtigungen, bevor geschäftskritische Tabellen und Pipelines produktiv genutzt werden.
Fazit
Für jede produktiv genutzte Delta-Tabelle, die Berichte, Lösch-Zusagen oder ML-Workloads trägt, sollte ein Wartungsmodell festgelegt werden.
Besonders wichtig ist dies, sobald mehrere Teams Tabellen besitzen, Deletion Vectors aktiv sind oder dem Datenschutz konkrete Fristen zugesagt wurden; in diesen Fällen beeinflussen OPTIMIZE und VACUUM gleichzeitig Performance, Speicherkosten und Compliance-Anforderungen.
Typische Hinweise auf einen fehlenden Wartungsprozess sind:
- Kern-Tabellen, deren Abfragen seit Monaten schleichend langsamer werden
- ein Speicherverbrauch, der deutlich über dem aktuellen Tabellenbestand liegt
- Lösch-Zusagen, die auf Nachfrage niemand belegen kann
- Wartungsläufe, die nicht automatisiert oder verbindlich geplant sind
Auf einer Plattform, deren Tabellen vollständig als verwaltete Unity-Catalog-Tabellen mit aktiver Predictive Optimization laufen, reduziert sich der manuelle Aufwand im Wesentlichen auf die Festlegung und Dokumentation der Aufbewahrungsfristen. Für alle anderen Tabellen muss der Wartungsprozess ausdrücklich definiert und orchestriert werden: Rhythmus, Frist und Verantwortung pro Tabellen-Klasse.
Die Aufbewahrungsfrist ist dabei eine besonders wichtige Kenngröße, die Storage-Kosten, Historie und Lösch-Zusagen gleichzeitig bewegt. Sie sollte bewusst festgelegt werden, statt dauerhaft den Standardwert ungeprüft zu übernehmen.
Als ersten Schritt die zehn wichtigsten Tabellen hinsichtlich Wartungszustand und Aufbewahrung prüfen und je Tabelle drei Werte erheben: letzter OPTIMIZE-Lauf, letzter VACUUM-Lauf, konfigurierte Aufbewahrungsfrist.
FAQ
OPTIMIZE verdichtet viele kleine Dateien einer Delta-Tabelle zu wenigen großen mit einer Zielgröße von rund 1 GB (Bin-Packing). Abfragen öffnen danach weniger Dateien und laufen schneller. Über denselben Lauf wird das Daten-Layout ausgeführt, wahlweise per Z-Ordering oder Liquid Clustering, und Dateien mit vielen lösch-markierten Zeilen werden neu geschrieben.
