Delta Lake Time Travel: Was die Versionshistorie leistet und wo sie endet
Delta Lake Time Travel erklärt: wie du frühere Tabellenstände abfragst, wann Rollback und Audit-Anfragen funktionieren und wo Aufbewahrungsfristen die Historie begrenzen.
Die Kernaussagen auf einen Blick.
- Mit Delta Lake Time Travel lassen sich frühere Versionen einer Delta-Tabelle abfragen, per Versionsnummer oder Zeitstempel aus dem Transaktionslog.
- Wie weit die Versionshistorie zurückreicht, hängt von zwei Aufbewahrungsfristen ab: sieben Tage für Datendateien, 30 Tage für Log-Einträge, jeweils im Standard.
- Vorab sollte festgelegt werden, für welche Anwendungsfälle die Versionshistorie benötigt wird: Fehlerkorrektur, Audit-Stichtage, reproduzierbare Trainingsstände, unter Berücksichtigung der zusätzlichen Speicherkosten längerer Aufbewahrungsfristen.
- Empfehlenswert ist, die Fristen je Tabellen-Klasse bewusst einzustellen und Backups, Langzeitarchivierung und Notfall-Wiederherstellung separat umzusetzen.
Inhaltsverzeichnis
Wenn der Tabellenstand vom Vortag wiederhergestellt werden muss
Ein nächtlicher MERGE hat fehlerhafte Quelldaten in die Umsatztabelle übernommen. Am nächsten Morgen zeigt das Reporting deutlich zu hohe Werte, der Fachbereich fragt nach, und eine vollständige erneute Verarbeitung der Pipeline würde mehrere Stunden dauern. Benötigt wird deshalb der Tabellenstand vor dem fehlerhaften Lauf.
Solche Situationen treten im Betrieb von Delta-Plattformen regelmäßig auf, und Delta Lake stellt dafür eine integrierte Versionshistorie bereit: Jede Delta-Tabelle führt ihre Versionshistorie im Transaktionslog mit. Häufig entsteht daraus jedoch die Annahme, dass zusätzliche Backups nicht mehr erforderlich seien. Deshalb sollte klar abgegrenzt werden, welche Anforderungen Time Travel erfüllt und welche nicht.
Lässt sich der Tabellenstand vom Vortag direkt wiederherstellen? Wie sah die Kennzahl zum Quartalsstichtag aus? Warum ist eine drei Wochen alte Version möglicherweise nicht mehr verfügbar? Kann die Versionshistorie ein separates Backup ersetzen?
Die kurze Fassung: Delta Lake Time Travel ermöglicht es, fehlerhafte Ladevorgänge häufig innerhalb kurzer Zeit zurückzusetzen, und erlaubt die Abfrage historischer Tabellenstände zu bestimmten Stichtagen; wie weit die Historie zurückreicht, entscheiden zwei Aufbewahrungsfristen, die konfiguriert werden müssen und zusätzliche Speicherkosten verursachen können.
Was ist Delta Lake Time Travel?
Delta Lake Time Travel bezeichnet die Möglichkeit, frühere Versionen einer Delta-Tabelle abzufragen. Jeder abgeschlossene Schreibvorgang erzeugt einen neuen Commit im Transaktionslog (_delta_log) und damit eine neue Tabellenversion; frühere Versionen lassen sich per VERSION AS OF <nummer> oder TIMESTAMP AS OF <zeitstempel> lesen, ohne dass dafür der aktuelle Tabellenstand verändert werden muss. Mit DESCRIBE HISTORY lässt sich nachvollziehen, welche Operation eine Version erzeugt hat sowie wann und durch wen sie ausgeführt wurde.
Time Travel stellt den vollständigen Tabellenstand früherer Versionen innerhalb des Aufbewahrungsfensters bereit: zum Beispiel für die Analyse fehlerhafter Ladeprozesse, für Audit-Anfragen zu einem bestimmten Stichtag und für reproduzierbare Datengrundlagen im Modelltraining. Die Abfrage einer früheren Version hat keine Auswirkungen auf den aktuellen Tabellenstand.
Zwei Einschränkungen müssen dabei berücksichtigt werden: Wie lange Versionen lesbar bleiben, hängt an zwei konfigurierbaren Fristen, und bei einem Verlust des Speichers oder einer gelöschten Tabelle bietet die Versionshistorie keinen Schutz. Beide Punkte ordnen wir weiter unten ein. Wie das Transaktionslog alle übrigen Format-Komponenten trägt, 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.
Wie Tabellenversionen entstehen
Delta Lake überschreibt vorhandene Parquet-Dateien bei Änderungen in der Regel nicht direkt. Ein UPDATE oder DELETE schreibt neue Dateien, die bisherigen Dateien werden im Transaktionslog als nicht mehr aktiv gekennzeichnet; physisch bleiben sie im Storage liegen. Diese Versionierung der Dateien bildet die technische Grundlage für Time Travel: Das Transaktionslog dokumentiert für jede Version die zugehörigen aktiven Dateien. Das Delta-Projekt dokumentiert diese Datei-Buchführung je Version anschaulich am Beispiel: Eine Abfrage auf Version 2 liest genau die Dateien, die das Log für Version 2 als aktiv führt, und überspringt alle anderen.
Diese Funktionsweise verursacht zusätzlichen Speicherbedarf. Ein Update auf eine einzelne Zeile schreibt im klassischen Copy-on-Write-Modell die komplette betroffene Datei neu, und die alte Datei bleibt für die Historie liegen. Bei Tabellen mit häufigen umfangreichen Updates kann der belegte Speicher deutlich größer als der aktuelle Datenbestand werden. Deletion Vectors können diesen Effekt bei Updates und Löschungen reduzieren, weil sie Zeilen zunächst markieren und das Neuschreiben verschieben; wie das logische Löschen und das physische Aufräumen zusammenspielen, erklären wir unter Deletion Vectors.
Bei einer Zeitstempelabfrage ermittelt Delta Lake die zuletzt vor diesem Zeitpunkt abgeschlossene Version; ein Zeitstempel nach dem jüngsten Commit kann zu einem Fehler führen. Die Zeitstempel stammen aus den Commit-Einträgen des Logs. Auch das Transaktionslog unterliegt einer regelmäßigen Bereinigung: In regelmäßigen Abständen schreibt Delta einen Checkpoint und entfernt bei dieser Gelegenheit Log-Einträge, die älter sind als die Log-Aufbewahrungsfrist. Eine Zeitstempelabfrage ist nur möglich, solange die dafür erforderlichen Logeinträge noch vorhanden sind.
Wofür sich Time Travel eignet
Für den beschriebenen fehlerhaften Ladevorgang ergibt sich folgender Ablauf in drei Schritten.
Fehlerhaften Commit identifizieren
Mit `DESCRIBE HISTORY` den fehlerhaften Commit des nächtlichen `MERGE` samt Versionsnummer und Zeitstempel eingrenzen.
Vorherigen Stand prüfen
Mit `VERSION AS OF` den Stand direkt davor abfragen. Sind die Kennzahlen dort korrekt, ist der fehlerhafte Lauf eindeutig eingegrenzt.
Tabelle zurücksetzen
Mit `RESTORE TABLE ... TO VERSION AS OF <n>` die Tabelle auf den letzten guten Stand zurücksetzen.
Eine solche Wiederherstellung (das Zurückdrehen der Tabelle auf den letzten guten Stand) kann deutlich schneller sein als eine vollständige Neuberechnung, und die gesamte Pipeline muss dafür nicht erneut ausgeführt werden.
Auch RESTORE erzeugt eine neue Tabellenversion: Sie zeigt auf die Datendateien des Zielstands, und der fehlerhafte Lauf und die anschließende Wiederherstellung bleiben dadurch in der Historie dokumentiert. Zwei Auswirkungen sollten im Betriebsprozess berücksichtigt werden. Nachgelagerte Streaming-Prozesse können die wiederhergestellten Daten erneut als Änderungen verarbeiten. Und sind die benötigten Datendateien bereits durch VACUUM entfernt worden, ist eine Wiederherstellung nicht mehr möglich.
Ein weiterer Anwendungsfall sind historische Auswertungen zu festen Stichtagen. Fragt das Audit drei Wochen nach Quartalsende, wie die Umsatz-Tabelle zum Stichtag aussah, stellt TIMESTAMP AS OF '2026-03-31 23:59:59' den Tabellenstand zu diesem Zeitpunkt bereit; eine separate Snapshot-Kopie oder nachträgliche Rekonstruktion ist dafür nicht erforderlich. Für Modell-Training gilt dasselbe Prinzip: Ein Training, das auf eine feste Versionsnummer zeigt, lässt sich exakt wiederholen, auch wenn die Tabelle längst weitergeschrieben wurde. Der verwendete Datenstand kann über eine konkrete Versionsnummer eindeutig referenziert werden, und manuell angelegte Snapshot-Kopien werden dadurch häufig überflüssig.
Dieselbe Übersicht als Karte:
| Anforderung | Trägt die Versionshistorie? |
|---|---|
| Fehl-Lauf zurückdrehen | ja, innerhalb des Aufbewahrungsfensters |
| Stichtags-Nachfrage beantworten | ja, solange Log-Einträge und Datendateien stehen |
| ML-Trainingsstand reproduzieren | ja, gegen eine feste Versionsnummer |
| Storage-Ausfall überstehen | nein, braucht eine separate Sicherung |
| Versehentliches abfedern | nein, die Historie verschwindet mit der Tabelle |
| Langzeit-Archiv über Jahre | nein, dafür sind Fristen und Storage-Kosten ungeeignet |
Wie weit reicht die Historie zurück?
Ohne abweichende Konfiguration sollte für Time Travel mit einem nutzbaren Fenster von sieben Tagen gerechnet werden. Databricks empfiehlt, Time-Travel-Operationen auf die letzten sieben Tage zu begrenzen, solange Daten- und Log-Aufbewahrung nicht bewusst höher eingestellt sind. Das Muster ist aus Snowflake Time Travel vertraut; bei Delta Lake steuern zwei Tabellen-Properties die Reichweite; die Konfiguration dieser Fristen ist deshalb eine zentrale Betriebsentscheidung.
Die erste Aufbewahrungsfrist gilt für nicht mehr aktive Datendateien. delta.deletedFileRetentionDuration legt fest, ab welchem Alter ein VACUUM-Lauf Dateien löschen darf, die keine aktuelle Version mehr referenziert; das Delta-Projekt dokumentiert dafür einen Standard von sieben Tagen. Wichtig für das Verständnis: Die konfigurierte Frist führt nicht automatisch zur Löschung der Dateien. Erst ein VACUUM-Lauf räumt physisch auf; ohne regelmäßige VACUUM-Läufe bleiben ältere Dateien länger erhalten und verursachen entsprechend zusätzliche Speicherkosten.
Die zweite Aufbewahrungsfrist gilt für die Einträge des Transaktionslogs. delta.logRetentionDuration steht im Standard auf 30 Tagen; ältere Log-Einträge entfernt Delta automatisch nach Checkpoint-Läufen. Fehlt der zugehörige Logeintrag, kann eine frühere Version auch bei noch vorhandenen Datendateien nicht mehr zuverlässig rekonstruiert werden.
Die tatsächlich verfügbare Historie wird durch beide Fristen gemeinsam begrenzt: Entscheidend ist die kürzere der beiden wirksamen Aufbewahrungsfristen, im Standard also sieben Tage. Wenn eine ältere Version nicht mehr verfügbar ist, liegt die Ursache häufig in bereits entfernten Datendateien oder Logeinträgen: Das Log kennt die Version oft noch, die Datendateien sind aber seit Tag sieben aufgeräumt.
Längere Aufbewahrungszeiträume können bei Audit- oder Reproduzierbarkeitsanforderungen sinnvoll sein, etwa 35 oder 90 Tage. Beide Fristen müssen dafür gemeinsam angehoben werden; sie erhöhen jedoch den Speicherbedarf, und bei häufig aktualisierten Tabellen können dadurch erhebliche zusätzliche Speicherkosten entstehen. Wie ein Wartungsplan Fristen, OPTIMIZE-Rhythmus und Storage-Kosten je Tabellen-Klasse festlegt, führen wir unter Optimize & Vacuum aus.
Time Travel und Change Data Feed
Die Versionshistorie kann entweder als vollständiger Tabellenstand oder als Folge einzelner Änderungen genutzt werden. Time Travel liefert den Zustand der Tabelle zu einer bestimmten Version oder einem Zeitpunkt. Der Change Data Feed zeigt dagegen die Änderungen zwischen zwei Versionen, inklusive der Vorher-Nachher-Werte bei Updates.
Time Travel nutzen, wenn
- Du brauchst den vollständigen Zustand der Tabelle zu einer bestimmten Version oder einem Zeitpunkt
- Es geht um Fehleranalyse, Rollback oder eine Stichtags-Auswertung
- Aufbewahrungsfristen und VACUUM bestimmen, wie weit du zurückkommst
Change Data Feed nutzen, wenn
- Du brauchst die zeilengenauen Änderungen zwischen zwei Versionen, inklusive der Vorher-Nachher-Werte bei Updates
- Nachgelagerte Prozesse sollen inkrementell nur mit den Deltas weiterarbeiten
- Dieselben Aufbewahrungsfristen und VACUUM-Läufe begrenzen, wie weit du zurückkommst
Für Fehleranalysen, Wiederherstellungen und Stichtagsauswertungen eignet sich Time Travel. Für die inkrementelle Verarbeitung durch nachgelagerte Prozesse, etwa für inkrementell gepflegte Ziel-Tabellen, eignet sich der Change Data Feed. Wie du sie aktivierst und welche Betriebs-Fragen daran hängen, erklären wir im Überblick zum Change Data Feed. Beide Funktionen sind durch dieselben Aufbewahrungsfristen begrenzt: Bereits entfernte Dateien und Logeinträge stehen weder für Time Travel noch für den Change Data Feed weiterhin zur Verfügung.
Grenzen
Time Travel unterstützt die Wiederherstellung nach fehlerhaften Läufen, historische Stichtagsabfragen und reproduzierbare Trainingsdaten, alles innerhalb eines Fensters, das du selbst konfigurierst. Fünf wesentliche Einschränkungen müssen dabei berücksichtigt werden; jede davon kann zu konkreten Betriebsrisiken führen. Die Versionshistorie ist für kurzfristige Wiederherstellung und Analyse gedacht und ersetzt kein Backup.
Historie liegt im selben Speicher
Aktuelle und historische Versionen liegen im selben Speichersystem. Ein gelöschter Storage-Container, ein kompromittiertes Konto oder ein DROP TABLE führen zugleich zum Verlust der historischen Versionen. Für eine echte Sicherung braucht es eine unabhängige Kopie per DEEP CLONE.
VACUUM kann Historie kappen
Ein manueller Lauf mit verkürzter Frist, etwa RETAIN 0 HOURS, entfernt alle nicht mehr referenzierten Dateiversionen unmittelbar. RESTORE und Abfragen älterer Versionen schlagen danach fehl.
Kein Ersatz für Langzeit-Archivierung
Jede aufbewahrte Dateiversion erhöht den Speicherbedarf, die Kosten wachsen mit Schreibfrequenz und Tabellengröße. Aufbewahrungspflichten über Monate oder Jahre gehören in eine dafür vorgesehene Archivlösung.
Kein Ersatz für Disaster Recovery
Fällt eine Cloud-Region aus oder wird das Storage-Konto unbrauchbar, liegt die Versionshistorie im selben Ausfall- und Sicherheitsbereich wie die aktuelle Tabelle. Regionale Replikation und getestete Wiederanlaufverfahren müssen separat umgesetzt werden.
Gelöschte Daten bleiben zunächst lesbar
Ein SQL-DELETE entfernt Zeilen aus der aktuellen Version; über Time Travel bleiben sie lesbar, bis VACUUM die alten Dateien räumt. Verbindliche Löschfristen erfordern einen abgestimmten PURGE- und VACUUM-Prozess.
Zur Einordnung: Für eine echte Sicherung beschreibt Microsoft Learn mit DEEP CLONE eine vollständige, unabhängige Kopie von Daten und Metadaten an einem separaten Ort, die von Operationen auf der Quelltabelle unberührt bleibt. Aufbewahrungsfristen sollten versioniert, geprüft und kontrolliert geändert werden, und manuelle VACUUM-Läufe auf produktiven Tabellen sollten nur nach einem festgelegten Freigabeprozess erfolgen. Databricks beschreibt in seinem Leitfaden zur DSGVO-konformen Löschung, dass erst die Kette aus Löschung, bei Deletion Vectors einem REORG TABLE ... APPLY (PURGE) und einem anschließenden VACUUM-Lauf die Daten physisch entfernt.
Innerhalb dieser Grenzen ist Time Travel ein zuverlässiges Werkzeug für kurzfristige Wiederherstellung und historische Abfragen, ohne dass dafür separate Snapshot-Pipelines aufgebaut werden müssen.
Für den Betrieb ergibt sich daraus eine klare Trennung der Aufgaben: Aufbewahrungsfristen je Tabellen-Klasse bewusst festlegen, VACUUM als geplante Wartung mit Review betreiben und Sicherung, Archiv und Notfall-Plan als eigene Mechanismen daneben stellen. Damit wird Time Travel gezielt für kurzfristige operative Wiederherstellung und historische Analysen eingesetzt: als zeitlich begrenzter Zugriff auf frühere Tabellenstände.
Fazit
Delta Lake Time Travel ist ab der ersten produktiven Tabelle sinnvoll: eingebaute Versionshistorie für Rollback und Stichtags-Abfragen, aber kein Ersatz für Backup oder Archivierung.
Die Versionshistorie ist im Format eingebaut, verursacht innerhalb kurzer Standardaufbewahrungsfristen meist nur begrenzte zusätzliche Speicherkosten und ermöglicht Abfragen und Wiederherstellungen, die andernfalls aufwendig rekonstruiert werden müssten.
Besonders nützlich ist die Funktion, wenn eines dieser Bilder vertraut klingt:
- ein Ladeprozess hat fehlerhafte Daten geschrieben, und der vorherige Tabellenstand muss kurzfristig wieder verfügbar sein
- Audit oder Fachbereich fragen regelmäßig, wie eine Kennzahl zu einem Stichtag aussah
- ML-Trainings sollen auf exakt reproduzierbaren Datenständen laufen
- Teams erstellen manuelle Tabellenkopien, um frühere Datenstände aufzubewahren, als Ersatz für eine geregelte Versionierung
Zwei Erwartungen sollten ausdrücklich ausgeschlossen werden: Time Travel ersetzt weder Backups noch eine langfristige Archivierung, und längere Aufbewahrungsfristen sollten aufgrund der zusätzlichen Speicherkosten regelmäßig überprüft werden.
Mein Vorschlag: Für jede Tabellenklasse festlegen, wie lange frühere Versionen verfügbar sein müssen (für kurzfristige Fehlerkorrekturen kann ein Zeitraum von sieben Tagen häufig ausreichen, Tabellen mit Audit-Anforderungen benötigen möglicherweise längere Aufbewahrungsfristen), Daten- und Log-Frist entsprechend einstellen und daneben dokumentieren, welche Tabellen eine echte Sicherung per Klon oder Replikation brauchen. An realen Wiederherstellungs- und Auditfällen lässt sich anschließend prüfen, ob das gewählte Aufbewahrungsfenster ausreichend ist.
Legt für jede Tabellenklasse fest, wie lange frühere Versionen verfügbar sein müssen, und stellt Daten- und Log-Aufbewahrungsfrist entsprechend ein.
FAQ
Jeder Schreibvorgang auf eine Delta-Tabelle erzeugt einen Commit im Transaktionslog und damit eine neue Tabellenversion. Alte Datendateien bleiben zunächst im Storage liegen und sind über das Log adressierbar. Frühere Stände liest du per oder ; zeigt, welche Operation welche Version erzeugt hat. Das funktioniert in Databricks und im Open-Source-Format auf dieselbe Weise.
