Time travel (dataversiebeheer)

Wat is time travel?

Time travel is de mogelijkheid om een tabel te bevragen zoals ze er op een eerder moment uitzag, op een oudere versie of op een bepaald tijdstip. Je query loopt niet tegen de data van vandaag, maar tegen de toestand van vorige week, of tegen exact de versie van voor die ene foute laadbeurt. De huidige tabel blijft ondertussen ongemoeid.

De functie hoort bij de open tabelformaten van een lakehouse, in de eerste plaats Delta Lake en Apache Iceberg. Zij houden niet alleen de laatste stand van de data bij, maar een hele reeks versies, elk met een verwijzing naar de bestanden die op dat moment geldig waren.

Je kan het vergelijken met de versiegeschiedenis van een tekstdocument. De laatste versie is wat je ziet als je het bestand opent, maar je kan terug naar de tekst van drie dagen geleden zonder dat iemand die apart heeft opgeslagen. Het formaat onthoudt elke wijziging.

Hoe werkt time travel?

Elke keer dat je naar een Delta- of Iceberg-tabel schrijft, ontstaat er een nieuwe versie. De data zelf zit in Parquet-bestanden die niet overschreven worden. Een schrijfactie voegt nieuwe bestanden toe en markeert oude als niet langer geldig, en een aparte log houdt bij welke bestanden bij welke versie horen.

Delta Lake schrijft die log in een mapje _delta_log naast de Parquet-bestanden. Elke commit is een genummerde versie: 0, 1, 2 en zo verder. Wil je versie 42 terug, dan leest de engine de bestanden die volgens de log bij die commit hoorden.

Apache Iceberg doet hetzelfde met snapshots. Elke schrijfactie eindigt in een nieuwe snapshot met een eigen id, en elke snapshot is een geldige, leesbare versie van de tabel.

Er is geen volledige kopie per versie nodig. Twee opeenvolgende versies delen bijna al hun bestanden, enkel wat effectief veranderde komt erbij. Zo blijft de historiek betaalbaar in opslag.

Waarvoor gebruik je time travel?

De functie is vooral handig op momenten waarop je de tabel van vroeger nodig hebt, niet die van nu.

1. Een rapport van vorige week reproduceren. Een cijfer klopte maandag, vandaag niet meer. Met time travel draai je exact dezelfde query tegen de versie van maandag en zie je wat er veranderd is.

2. Auditeren wat er wijzigde. Je vergelijkt twee versies van dezelfde tabel om te zien welke rijen zijn toegevoegd, aangepast of verdwenen.

3. Een foute laadbeurt terugdraaien. Een pipeline laadde een corrupt bestand in. Je leest eerst de vorige versie na om te controleren dat die klopt, en zet de tabel dan terug.

4. Een pipeline debuggen. Je bekijkt de tabel net voor en net na een schrijfactie om te achterhalen welke stap de fout introduceerde.

5. Reproduceerbare analyses. Een berekening draait tegen een vaste versie, zodat het resultaat identiek blijft, ook als de brontabel intussen verder groeit.

Version of timestamp: de syntax

Je bevraagt een oudere stand op twee manieren: op versienummer of op tijdstip. In Delta Lake en in Microsoft Fabric ziet dat er zo uit:

SELECT * FROM verkoop VERSION AS OF 42
SELECT * FROM verkoop TIMESTAMP AS OF '2026-06-30'

Welke versies en tijdstippen beschikbaar zijn, vraag je op met DESCRIBE HISTORY verkoop. Dat geeft per commit het versienummer, de timestamp en wat er gebeurde. In de SQL analytics endpoint van Fabric Warehouse werkt het via een OPTION (FOR TIMESTAMP AS OF ...)-clausule op je SELECT.

Verwar time travel niet met RESTORE. Time travel is alleen-lezen: je query kijkt naar het verleden, maar verandert niets aan de huidige tabel. RESTORE zet een oudere versie effectief terug als nieuwe stand. Een gangbaar patroon is eerst met time travel nakijken of de oude versie klopt, en pas dan beslissen of je RESTORE draait.

Apache Iceberg kent dezelfde VERSION AS OF- en TIMESTAMP AS OF-syntax, waarbij VERSION AS OF een snapshot-id aanspreekt in plaats van een oplopend versienummer.

Bewaren kost opslag: retention en vacuum

Elke oude versie die je kan bevragen, betekent dat de onderliggende Parquet-bestanden nog op de opslag staan. Hoe verder je wil kunnen tijdreizen, hoe meer bestanden je bewaart, en dat kost opslagruimte. Daarom snoeien beide formaten de historiek periodiek weg.

In Delta Lake doet VACUUM dat werk. Het verwijdert databestanden die niet meer bij de huidige versie horen en ouder zijn dan het bewaarvenster, standaard zeven dagen (168 uur). Zodra een bestand weg is, kan je niet meer tijdreizen naar een versie die dat bestand nodig had, ook al staat die versie nog in de geschiedenis. De transactielog zelf wordt apart bewaard, standaard dertig dagen via delta.logRetentionDuration.

In Iceberg speelt expire_snapshots dezelfde rol: het gooit oude snapshots en hun bestanden weg. In Fabric Warehouse verloopt het automatischer, met een standaard bewaarperiode van dertig kalenderdagen.

De afweging is dus concreet. Een ruim bewaarvenster geeft je meer audit- en herstelmogelijkheden maar kost opslag, een krap venster bespaart opslag maar maakt oudere versies onbereikbaar. Stem het venster af op hoe ver je echt moet kunnen terugkijken.

Waar moet je op letten bij time travel

Time travel is geen back-up voor de lange termijn. Het bewaarvenster is beperkt en bedoeld voor recente historiek. Wil je een stand voor jaren vastleggen, maak dan een echte kopie met bijvoorbeeld CREATE TABLE ... AS SELECT.

VACUUM te kort zetten breekt herstel. Verklein je het bewaarvenster onder wat je audits of een RESTORE nodig hebben, dan verdwijnen bestanden die je later nog wilde bevragen. Ook een RESTORE faalt als de nodige bestanden al opgeruimd zijn.

Een tijdstip is niet altijd exact. De timestamp van een versie hangt aan het logbestand van die commit. Kopieer je een tabel naar een nieuwe locatie, dan kan tijdreizen op timestamp breken. Werk in dat geval op versienummer.

Schema-wijzigingen tellen mee. Een query naar een tijdstip voor een kolom bestond, lukt enkel als je die nieuwe kolom niet opvraagt. Vraag je ze wel op, dan faalt de query.