Schema drift

Wat is schema drift?

Schema drift betekent dat de structuur van een gegevensbron in de loop van de tijd verandert: er komt een kolom bij, een kolom verdwijnt, een veld wordt hernoemd of het type van een veld verandert. Het probleem is niet die wijziging op zich, maar dat alles wat er verderop op rekende nog uitgaat van de oude vorm. Een pipeline, een transformatie of een rapport dat de oude kolommen verwacht, breekt of gaat stilletjes de mist in.

Je krijgt schema drift zodra data van het ene systeem naar het andere loopt en de kant die de data stuurt haar structuur aanpast zonder dat de kant die ze verwerkt het weet. Bij een klassieke ETL- of ELT-pipeline zijn de transformaties vaak vastgeknoopt aan de exacte kolomnamen van de bron. Wijzigt die bron, dan klopt de knoop niet meer.

Je kan het vergelijken met een leverancier die de indeling van zijn pakbon verandert zonder iets te zeggen. Zolang je magazijnier op vaste plekken op het blad kijkt om artikelnummer en aantal te vinden, leest hij vanaf dat moment de verkeerde vakjes. Het papier komt nog altijd binnen, alleen belanden de gegevens op de verkeerde plaats.

Hoe ontstaat schema drift?

De oorzaak zit bijna altijd stroomopwaarts, bij het systeem dat de data levert.

Een applicatie of SaaS-dienst verandert
Je CRM of boekhoudpakket rolt een update uit en voegt een veld toe, hernoemt er een of splitst er een in twee. De API of de export verandert mee, meestal zonder aankondiging aan wie de data verder verwerkt.

Nieuwe behoeften in de business
Een team heeft een extra veld nodig en voegt het toe aan de brondatabank. In productie staat het er, in je rapportagelaag nog niet, en de twee lopen uiteen.

Geen afstemming tussen teams
Meerdere mensen werken aan dezelfde databank en passen de structuur aan zonder het door te geven. Wie downstream zit, ontdekt de wijziging pas als er iets stukloopt.

Hoe merk je schema drift?

Schema drift toont zich op twee manieren, en de tweede is de gevaarlijke.

In het beste geval loopt je pipeline meteen vast. Een transformatie verwijst naar kolom klant_id die er niet meer is, de run faalt en je krijgt een foutmelding. Vervelend, maar je weet tenminste dat er iets mis is.

In het slechtste geval blijft alles gewoon draaien en klopt de uitkomst niet. Een hernoemde kolom komt binnen als een nieuwe, lege kolom, dus je rapport toont plots nullen. Of een bedrag dat vroeger in euro binnenkwam, staat nu in cent, en je omzetcijfer is honderd keer te groot. Niemand krijgt een foutmelding. Het cijfer ziet er plausibel uit tot iemand het toevallig natelt.

Een concreet voorbeeld

Stel dat je elke nacht een CSV-export van je webshop inlaadt. De kolommen liggen vast: order_id, datum, klant, bedrag_excl_btw en btw. Je transformatie telt bedrag_excl_btw en btw op tot het totaal.

De webshop krijgt een update. In de nieuwe export heet btw voortaan vat_amount en staat er een extra kolom korting tussen. Twee dingen gebeuren tegelijk. Je optelling vindt de kolom btw niet meer en rekent met een leeg veld, dus elk totaal mist de btw. En omdat er een kolom bij is gekomen, zijn alle posities een plaats opgeschoven, dus een pipeline die op volgorde werkt leest de datum waar ze de klant verwacht. De export laadt zonder fout in, en je dagrapport toont te lage bedragen tot iemand merkt dat de btw ontbreekt.

Hoe verdedig je je tegen schema drift?

Er bestaat geen knop die schema drift tegenhoudt, want de wijziging gebeurt buiten jouw systeem. Wat je wel kan doen, is ze opvangen voor ze schade aanricht.

Detecteer de wijziging vroeg
Vergelijk bij elke run het binnenkomende schema met het verwachte schema en sla alarm bij een verschil. Een data observability-platform doet dit automatisch en waarschuwt je zodra een kolom van type verandert of verdwijnt. Tests op je datakwaliteit vangen dezelfde breuken op je eigen tabellen.

Leg de afspraak vast in een data contract
Een data contract zet zwart-op-wit welk schema de bron belooft en welke wijzigingen wel of niet mogen. Een release die het contract breekt, wordt geblokkeerd voor ze in productie gaat. Voor streaming via Change Data Capture en Kafka doet een schema registry hetzelfde op berichtniveau: een brekende versie wordt geweigerd nog voor er iets misloopt.

Ga bewust om met nieuwe kolommen
In plaats van een vaste vorm te veronderstellen, kan je je pipeline zo bouwen dat ze meebeweegt. Azure Data Factory noemt dit schema drift-ondersteuning: onbekende kolommen, de zogenaamde drifted columns, worden door de flow meegedragen en je verwijst ze via hun naam in plaats van hun positie. Fivetran laat je per bron kiezen of nieuwe kolommen en tabellen automatisch mee mogen of geblokkeerd worden tot je ze goedkeurt. Verwijs daarbij naar kolommen op hun naam en niet op hun positie, want een pipeline die op volgorde werkt loopt vast zodra er een kolom tussen wordt geschoven.

Schema drift versus data drift en model drift

Deze drie worden makkelijk verward, want alle drie gaan ze over data die verandert. Het verschil zit in wat er precies verandert.

Bij schema drift verandert de structuur: een kolom komt bij, verdwijnt, krijgt een andere naam of een ander type. De waarden kunnen perfect in orde zijn, alleen past de vorm niet meer.

Bij data drift blijft de structuur gelijk maar verschuiven de waarden zelf. Dezelfde kolommen, maar de verdeling verandert: een leeftijdskolom die vroeger vooral rond 40 zat, zit nu rond 25. De vorm klopt nog, de inhoud gedraagt zich anders.

Bij model drift ligt het probleem bij het model zelf: een machine learning-model presteert slechter omdat de wereld waarop het getraind is verschoven is. Data drift is daar vaak de onderliggende oorzaak van.

Kort gezegd: schema drift breekt je pipeline of levert stilletjes verkeerde kolommen op, data drift laat je cijfers geleidelijk afwijken, en model drift laat je voorspellingen ontsporen.