Wat terugdraaien in een datawarehouse echt betekent

Wat betekent terugdraaien in een datawarehouse?

Neem een groothandel die elke nacht de klantgegevens uit het boekhoudpakket laadt. Maandagnacht levert dat pakket door een exportfout de kredietlimieten in de verkeerde kolom aan. De lading slaagt, want technisch is er niets mis. Dinsdag om elf uur belt de kredietafdeling: driehonderd klanten hebben opeens een limiet van veertigduizend euro in plaats van vijfentwintigduizend.

Een gewone database kan een wijziging terugdraaien zolang die nog niet is afgerond. Hier is dat moment negen uur geleden. De lading is klaar, de rapporten zijn ververst, de dashboards tonen de nieuwe limieten. Terugdraaien betekent daarom iets anders dan in een database: je kiest een moment, bijvoorbeeld maandag 23:59, en zet de tabel terug naar hoe hij toen was.

Dat gaat per tabel. De foute export raakte alleen de klanttabel; de orders, de artikelen en de voorraad van diezelfde nacht zijn goed en moeten blijven staan. Je geeft dus de naam van de tabel op en het moment waarnaar je terug wilt. Twee tabellen terugzetten zijn twee handelingen, elk met een eigen moment.

Waarom historie bewaren nog geen terugdraaien is

Yres bewaart van elke rij elke versie. Toen de kredietlimiet van De Jong Transport maandagnacht van vijfentwintig- naar veertigduizend ging, is de oude waarde niet overschreven. Er kwam een nieuwe versie bij, en de oude kreeg een einddatum. Je kunt dus altijd terugkijken: wat was de limiet op 25 september? Vijfentwintigduizend.

Terugkijken is iets anders dan terugzetten. Rapporten en dashboards tonen de actuele versie, en na maandagnacht is dat de foute. De goede waarde staat er nog, afgesloten, maar niemand ziet hem zonder er gericht naar te zoeken. De kredietafdeling werkt intussen met veertigduizend.

Er speelt nog iets, dat je op het scherm niet ziet. Een tabel die alleen de wijzigingen ophaalt, onthoudt tot waar hij is gekomen: de laatste wijzigingsdatum die hij van de bron heeft gezien. Dat is het watermerk. De foute lading van maandagnacht heeft dat watermerk naar maandagnacht geschoven. Gooi je de foute rijen met de hand weg, dan blijft het watermerk daar staan, en de volgende lading vraagt de bron alleen om wijzigingen van ná maandagnacht. Alles van vóór dat moment haalt hij nooit meer op. Je hebt dan een tabel die er goed uitziet en een gat dat zichzelf nooit meer vult.

Wat er gebeurt als je terugdraait, stap voor stap

Terug naar de groothandel. De beheerder opent in Yres de klanttabel, kiest terugdraaien en vult maandag 23:59 in. Het moment telt op de seconde. Yres bouwt dan één script van drie tot vijf stappen en voert dat in één keer uit.

Eerst een controle: bestaat de opgegeven tabel in de administratie van Yres? Zo niet, dan stopt het hier, met een foutmelding in het logboek. Daarna de vier stappen die iets veranderen. Alle rijen die na maandag 23:59 zijn geladen gaan eruit, dus ook de foute versie van De Jong Transport. De versies die op dat moment golden en daarna zijn afgesloten gaan weer open: vijfentwintigduizend is weer de actuele limiet. Maakt deze tabel zelf volgnummers aan voor nieuwe klanten, dan verdwijnen de nummers die sinds maandag 23:59 zijn uitgedeeld, zodat een nieuwe klant later geen nummer krijgt dat al in een rapport staat. En als de tabel alleen wijzigingen ophaalt, wordt het watermerk opnieuw bepaald uit wat er nu nog in de tabel staat. Het komt daarmee vanzelf uit op de laatste wijziging van vóór de foute lading.

Van elke terugdraaiactie blijft een regel in het logboek staan: welke tabel, welk venster, wie het deed, hoeveel rijen eruit gingen, hoe lang het duurde en of het gelukt is. Mislukt er iets halverwege, dan staat dat er ook, met een verwijzing naar de uitgebreide log.

Het monitoringscherm van Yres gebruikt diezelfde logregel. Elke lading die binnen het teruggedraaide venster viel, wordt daar gemarkeerd als verwijderd, met de naam van de beheerder en het tijdstip erbij. Liepen er dinsdagochtend nog twee goede ladingen op de klanttabel, dan staan die ook als verwijderd. Dat klopt, want ze zijn mee teruggedraaid en moeten opnieuw.

De valkuil: de volgende lading

De rijen weggooien is het eenvoudige deel. De schade die daarna ontstaat zit in het watermerk, en dat is de reden dat terugdraaien in Yres een eigen handeling is en geen opruimactie met de hand.

Een tabel die alleen wijzigingen ophaalt vraagt de bron elke nacht: geef me alles wat is gewijzigd sinds dit moment. Dat houdt een lading klein. Het betekent ook dat het antwoord van de bron volledig afhangt van het moment dat je meegeeft. Na het terugdraaien staat dat moment weer op de laatste wijziging van vóór de foute lading. Woensdagnacht vraagt Yres dus om alles sinds dat moment, en de bron levert de kredietlimieten opnieuw, dit keer uit de juiste kolom. De driehonderd klanten krijgen hun goede limiet terug als een gewone wijziging.

Twee details zijn goed om te kennen. Is de tabel na het terugdraaien helemaal leeg, bijvoorbeeld omdat je terugging tot vóór de allereerste lading, dan is er geen laatste wijziging meer om op te staan. Yres haalt de bron dan in zijn geheel opnieuw op. En de vraag aan de bron is 'vanaf en met' het watermerk, zodat de rijen die op dat moment zelf zijn gewijzigd nog een keer meekomen. Yres vergelijkt elke binnenkomende rij met de versie die er al staat en maakt alleen een nieuwe versie als er iets veranderd is, dus daar ontstaan geen dubbele versies van.

Wanneer je het gebruikt, en wanneer niet

Terugdraaien is bedoeld voor één tabel die een lading heeft binnengekregen die eruit moet, waarbij je weet vanaf welk moment. Drie gevallen die in de praktijk steeds terugkomen.

Een bron die een periode dubbel aanlevert. Een salarispakket exporteert na een update de mutaties van september nog een keer, met nieuwe tijdstempels. De tabel met loonkosten bevat september nu twee keer. Terugdraaien naar het moment vóór die export, en de volgende lading haalt september één keer opnieuw op.

Een koppeling die de verkeerde kolom als sleutel gebruikte. Bij het inrichten van een nieuwe bron is het klantnummer per vestiging als sleutel gekozen in plaats van het landelijke nummer. Elke klant met drie vestigingen staat na de eerste lading drie keer in de tabel. Sleutel corrigeren, terugdraaien tot vóór de eerste lading, opnieuw laden.

Een leeg bestand dat als geldige levering is verwerkt. De leverancier van een prijslijst zet per ongeluk een leeg bestand klaar. Yres leest nul regels en sluit alle prijzen af alsof ze zijn vervallen. Terugdraaien naar het moment vóór die lading, en de prijzen zijn weer actueel.

Wie rechtstreeks op de database werkt, kan de handeling eerst in de proefstand draaien. Yres toont dan het volledige script met het gekozen moment erin, en raakt niets aan. Zo zie je vooraf hoeveel rijen eraan gaan. Vanuit het beheerscherm kan dat niet: daar wordt altijd uitgevoerd. Let op dat ook een proefdraai een regel in het logboek achterlaat, en dat het monitoringscherm de ladingen in dat venster daardoor als verwijderd toont terwijl er niets is verwijderd.

• Wel: één tabel, één moment, en de periode daarna kan opnieuw geladen worden
• Wel: je wilt vooraf zien wat er zou gebeuren en je kunt bij de database; de proefstand toont het script en laat de data met rust
• Grens: een lading die twaalf tabellen raakte vraagt twaalf keer terugdraaien, elk met een eigen moment
• Grens: de verwijderde rijen zijn echt weg; het terugdraaien zelf terugdraaien bestaat niet
• Grens: alleen de inhoud van de tabel verandert. Kolommen, tabellen, views en rapporten blijven zoals ze zijn
• Grens: wat buiten het datawarehouse is weggeschreven, zoals bestanden in een data lake, blijft staan
• Weinig zin: een tabel die bij elke lading volledig wordt vervangen. Er staat geen oudere stand meer om naar terug te keren
• Weinig zin: de tussenlaag waarin de laatste lading wordt klaargezet. Die wordt bij de volgende lading toch opnieuw gevuld

Veelgestelde vragen