Schema-evolutie

Wat is schema-evolutie?

Schema-evolutie is hoe je omgaat met een gegevensstructuur die door de tijd verandert. Een bron voegt een kolom toe, hernoemt er een, of wijzigt een datatype, en jouw pijplijn en rapporten moeten daar tegen kunnen zonder te breken.

Je herkent het probleem waarschijnlijk. De leverancier van je webshop of boekhoudpakket past stilletjes een veldnaam aan, en 's nachts faalt je verversing met de melding dat een kolom niet gevonden is. Of erger: de verversing faalt niet, maar een veld dat vroeger een getal was komt nu als tekst binnen, en je omzetcijfer klopt niet meer zonder dat iemand het meteen doorheeft.

Een schema is de afspraak over hoe de data eruitziet: welke kolommen er zijn, hoe ze heten, en welk type waarde erin zit. Verandert die vorm, dan moet alles wat erop rekent mee veranderen. Schema-evolutie is de discipline om dat ordelijk te laten gebeuren in plaats van je te laten verrassen.

Welke wijzigingen zijn veilig, welke breken?

Niet elke wijziging is even erg. Het verschil zit in wat er stroomafwaarts mee moet.

• Een kolom toevoegen is meestal veilig. Bestaande query's blijven werken, ze negeren gewoon de nieuwe kolom. Dit heet een additieve wijziging, en het is de enige soort die de meeste systemen vanzelf opvangen.

• Een kolom hernoemen of verwijderen breekt. Elke stap die de oude naam nog aanroept, valt stil. Het valt meteen op, wat een klein geluk bij een ongeluk is: je merkt het aan een foutmelding, niet aan een verkeerd cijfer.

• Een datatype wijzigen is het gevaarlijkst, precies omdat het stil kan blijven. Een postcode die van getal naar tekst verspringt, of een bedrag dat plots met een komma in plaats van een punt binnenkomt: de verversing slaagt, maar een sortering loopt fout of een totaal klopt niet. Dit is de soort wijziging die het langst onopgemerkt blijft.

Hoe systemen een veranderend schema opvangen

Grofweg bestaan er twee houdingen tegenover een veranderend schema.

Schema-on-write
Het systeem legt de vorm vast op het moment dat je schrijft. Komt er data binnen die niet past, dan weigert het de schrijfactie in plaats van stilletjes de tabel aan te passen. Een data warehouse werkt zo, en Delta Lake doet dit standaard: dat noemt men schema enforcement. Het beschermt je tegen ongemerkte wildgroei in je schema.

Schema-on-read
Het systeem bewaart de data ruw en legt de structuur pas op wanneer je leest. Een data lake werkt zo. Dat geeft ruimte bij binnenkomst, maar verplaatst de vraag naar het moment van lezen.

Delta Lake, dat bovenop het Parquet-formaat draait, heeft ingebouwde manieren om het schema tóch te laten meegroeien wanneer je dat bewust toelaat. Met de optie mergeSchema voeg je nieuwe kolommen uit de bron automatisch toe aan de doeltabel. Voor een compatibele typewijziging, zoals een geheel getal dat een groter geheel getal wordt, bestaat type widening, dat je eerst per tabel aanzet. Hernoemen en verwijderen kan via column mapping zonder de hele tabel te herschrijven. Microsoft en Databricks documenteren elk van die opties.

Bij streaming-data over Kafka bewaakt een schema registry welke wijzigingen toegelaten zijn. Je stelt een compatibiliteitsregel in, standaard backward: een nieuwe lezer moet oude berichten nog aankunnen. Een wijziging die de regel breekt, wordt geweigerd voor ze downstream schade doet.

Schema-evolutie in Power BI en Power Query

Dicht bij huis voor veel KMO's zit het bij Power Query en Power BI.

Verwijst een stap in Power Query naar een kolom die niet meer bestaat, dan krijg je een fout op stapniveau: "De kolom X van de tabel werd niet gevonden." De hele query stopt daar.

In de Power BI-service loopt het subtieler. Een geplande gegevensverversing faalt wanneer een bronkolom of -tabel hernoemd of verwijderd is, omdat de service zelf het schema niet mee ververst. Je moet dan in Power BI Desktop een schema-refresh doen en het semantisch model opnieuw publiceren. Let op: die schema-refresh haalt de weggevallen kolom eruit, en dat kan visuals, DAX-measures en relaties breken die erop steunden.

Je maakt een query beter bestand tegen zulke wijzigingen door niet alles hard vast te pinnen. Kies expliciet de kolommen die je nodig hebt met Choose columns, en vermijd stappen die op een vaste kolompositie of losse naam leunen wanneer dat niet hoeft.

Hoe bescherm je je tegen brekende wijzigingen?

Je krijgt schema-evolutie nooit helemaal onder controle, want de bron ligt vaak buiten je huis. Wat je wel kan, is de kans op verrassingen klein maken.

• Leg een data contract vast. Zet met de bronleverancier of het bronteam zwart-op-wit welk schema en welke types je verwacht, en welke procedure een wijziging volgt. Een brekende wijziging wordt dan aangekondigd in plaats van ontdekt.

• Bewaak het schema. Monitoring en data observability merken op dat een kolom verdween of van type veranderde, nog voor je rapport het toont. Zonder die bewaking is je eerste signaal een verkeerd cijfer.

• Zet je definities onder versiebeheer. Bewaar de definitie van je pijplijn en je verwachte schema in Git, zodat je ziet wat wanneer veranderde en een fout kan terugdraaien.

• Bouw additief waar je kan. Nieuwe kolommen toevoegen breekt niemand; bestaande kolommen hernoemen of hergebruiken wel. Kies bij twijfel voor toevoegen.

Schema-evolutie versus gewone datawijziging

Verwar schema-evolutie niet met gewone datawijzigingen. Bij een datawijziging veranderen de waarden: een klant verhuist, een order krijgt een andere status, een prijs gaat omhoog. De structuur blijft gelijk, en je pijplijn merkt er niks van, dat is precies de bedoeling.

Bij schema-evolutie verandert de structuur zelf: er komt een kolom bij, een veldnaam wijzigt, een type verspringt. Waarden die veranderen horen bij de normale werking; een structuur die verandert, vraagt dat je iets aanpast. Voor het netjes bijhouden van veranderende waarden over de tijd bestaat trouwens een eigen patroon, Slowly Changing Dimensions, en dat is iets anders dan schema-evolutie.

FAQ over schema-evolutie

1. Is een kolom toevoegen echt altijd veilig?
Meestal wel, want bestaande query's negeren een kolom die ze niet kennen. Het gaat pas mis als een stap alle kolommen tegelijk overneemt en iets verderop een vaste vorm verwacht. Voeg toe waar je kan, maar test het resultaat.

2. Hoe merk ik een stille typewijziging op tijd?
Niet aan een foutmelding, want die komt er niet. Bewaak de verwachte types en waardebereiken, via een data contract of een observability-tool, en controleer na een verversing of totalen en sorteringen nog plausibel zijn.

3. Wat is het verschil met schema drift?
Schema drift is het ongewenste, ongecontroleerde uiteenlopen van je schema tegenover wat je pijplijn verwacht. Schema-evolutie is het bewust en gecontroleerd laten meegroeien. Drift is wat je overkomt, evolutie is wat je organiseert.

4. Heb ik hiervoor een data lake of warehouse nodig?
Nee. Ook een gewone Power BI-refresh op één bron loopt tegen schema-evolutie aan zodra die bron een veld hernoemt. Het hoort bij elke keten die op een externe structuur steunt, groot of klein.