Time Travel

Time Travel bezeichnet die Möglichkeit, eine Tabelle so abzufragen, wie sie zu einem früheren Zeitpunkt aussah: über eine Versionsnummer oder einen Zeitstempel. Möglich wird das in modernen Tabellenformaten (Delta Lake, Apache Iceberg, Snowflake), die jede Änderung in einem Transaktions-Log (Protokoll aller Schreibvorgänge) festhalten und die alten Datendateien so lange aufbewahren, bis eine Aufräum-Operation sie löscht.

Was ist Time Travel?

Time Travel ist eine Funktion moderner Tabellenformate, mit der sich frühere Stände einer Tabelle lesen lassen, ohne dass die aktuelle Version verändert wird. Jeder abgeschlossene Schreibvorgang (also jedes Einfügen, Ändern, Löschen oder Zusammenführen von Zeilen) erzeugt eine neue Tabellenversion im Transaktions-Log, dem Protokoll, das jede Änderung mitschreibt. Die zugehörigen Datendateien bleiben verlinkt und lesbar, bis eine Aufräum-Operation sie aus dem Speicher entfernt.

Bei Delta Lake wird der frühere Stand über SELECT ... FROM tabelle VERSION AS OF <n> oder TIMESTAMP AS OF <zeitstempel> gelesen; DESCRIBE HISTORY listet die verfügbaren Versionen samt Operation, Ausführungszeit und Nutzer; RESTORE TABLE ... TO VERSION AS OF <n> setzt die Tabelle als neue Commit-Operation auf einen früheren Stand zurück. Bei Apache Iceberg erfolgt der Zugriff über eine snapshot-id oder ein as-of-timestamp-Prädikat gegen dieselbe Metadaten-Hierarchie. Snowflake bietet unter demselben Namen eine funktionsgleiche Mechanik über AT und BEFORE-Klauseln.

Der Begriff existiert, weil ein klassischer Data Lake auf Objekt-Speicher keine Versionshistorie kennt: Ein überschriebener Parquet-Ordner ist verloren, ein fehlerhafter Ladejob erfordert einen vollständigen Neuaufbau aus der Quelle. Mit einem Transaktions-Log über den Datendateien lässt sich eine begrenzte Versionshistorie ohne Datenkopie verwalten. Typische Einsätze sind das Debugging fehlerhafter ETL-Ladungen, die Reproduktion von ML-Trainingsständen, die Beantwortung von Stichtags-Abfragen und der schnelle Rollback nach einem fehlerhaften MERGE.

Die Aufbewahrungsdauer ist konfigurierbar und liegt bei Delta Lake standardmäßig bei sieben Tagen für Datendateien und 30 Tagen für Log-Einträge. Nach Ablauf der Fristen entfernt VACUUM (Delta) beziehungsweise expire_snapshots (Iceberg) die zugehörigen Dateien; ab diesem Zeitpunkt ist die frühere Version nicht mehr lesbar.

Abgrenzung zu Backup, Slowly Changing Dimensions, Change Data Feed und Snapshot

Time Travel wird häufig mit Konzepten verwechselt, die entweder außerhalb der Tabelle liegen, auf einer anderen Modellierungs-Ebene arbeiten oder eine andere Sicht auf dasselbe Transaktions-Log geben.

Die wichtigste Abgrenzung verläuft zwischen Time Travel und Backup, weil in Delta-Lake-Projekten regelmäßig die Annahme entsteht, mit Time Travel sei eine separate Sicherung entbehrlich. Time Travel schützt weder vor Storage-Verlust noch vor einer versehentlichen DROP TABLE-Operation und deckt keine mehrmonatige Aufbewahrung ab, ohne dass Speicher- und Log-Fristen entsprechend hochgesetzt werden. Backup, Langzeit-Archivierung und Disaster-Recovery gehören daher weiterhin separat geplant.

Beispiel: Rollback nach fehlerhaftem MERGE und reproduzierbares ML-Training

Ein nächtlicher MERGE INTO hat fehlerhafte Quelldaten in die Umsatz-Tabelle sales.orders übernommen. Das Reporting zeigt am Morgen deutlich zu hohe Werte. Statt die Pipeline über mehrere Stunden neu zu fahren, prüft das Team zunächst die Versionshistorie:

DESCRIBE HISTORY sales.orders;

Die Historie zeigt Version 42 als fehlerhaften MERGE-Commit und Version 41 als letzten korrekten Stand. Ein Read auf die Vor-Version bestätigt die erwarteten Werte:

SELECT sum(revenue)
FROM sales.orders VERSION AS OF 41
WHERE order_date = '2026-07-11';

Nach Freigabe setzt der Rollback die Tabelle als neuen Commit zurück:

RESTORE TABLE sales.orders TO VERSION AS OF 41;

Die Version 43 enthält damit denselben Inhalt wie Version 41; die Tabellenhistorie bleibt vollständig, der fehlerhafte Commit 42 ist weiterhin dokumentiert. Für ein zweites Szenario speichert ein Feature-Store die Delta-Version, gegen die ein Modell trainiert wurde. Ein Re-Training gegen VERSION AS OF 118 liest denselben Feature-Stand wie beim Originaltraining und erhält reproduzierbare Trainingsdaten, sofern die Version noch innerhalb der Aufbewahrungsfrist liegt.