Samenvatting
Het datawarehouse van een Nederlandse vakbond was sinds ongeveer 2020 gegroeid tot acht databases, één per bron of laag, met verwijzingen over en weer en een metadata-gedreven laadengine als ruggengraat. Deze migratie brengt alles samen in één database met een schema per laag en per bron, en gebruikt de consolidatie voor een verbeterslag: alleen levende objecten gaan mee, en een laag van 144 business-views, op vier na pure hernoemingen, gaat op in de transformatielaag. De laadengine is herbouwd voor één database en uitgebreid met een lineage-harvest, een gegenereerde compatibiliteitslaag voor bestaande rapporten en kwaliteitscontroles. Omdat hier de cijfers doorheen gaan waar de organisatie op stuurt, is de hele migratie ingericht op controleerbaarheid: elk verschil met het oude warehouse wordt dagelijks gemeten, en wat niet exact verklaard is, komt als melding in het dagrapport.
De vraag
Breng acht databases samen in één datawarehouse en neem een verbeterslag mee, zonder dat bestaande Power BI-rapporten breken. Alles mocht ter discussie staan. Vast stond alleen dat het laden metadata-gedreven blijft, dat bestaande rapporten blijven werken, en dat logging, lineage en herstartbaarheid eisen zijn in plaats van extra's: elke stap moet meetbaar en controleerbaar zijn.
Wat ik heb gebouwd
- Eén database met een schema per laag (landing, staging, transformatie, datamart) en per bron, voor veertien bronnen waaronder ERP, CRM, contactcenter, HR en de website; verwijzingen tussen databases verdwijnen daarmee
- Een catalogus van brontabellen waaruit de engine landings- en stagingtabellen genereert en bijwerkt bij schemawijzigingen in de bron: kolommen erbij, alleen verbreden, nooit stil verkleinen, en vóór elke wijziging aan een bestaande tabel een impactmeting via de lineage
- Een dynamische MERGE-lading met temporal history en soft delete, per tabel herstartbaar, en materialisatie naar de datamart met vaste tabeldefinities in git: een kolom die de view niet levert, faalt luid in plaats van stil te verdwijnen
- Een gegenereerde compatibiliteitslaag met de oude object- en kolomnamen, waarop bestaande Power BI-rapporten bij de overstap kunnen blijven draaien; een naamkoppeling die niet meer klopt, geeft een fout in de database in plaats van een kapot rapport
- Lineage op object- en kolomniveau, zoveel mogelijk geharvest uit de database zelf en alleen voor berekende kolommen met de hand geregistreerd, een glossary van 137 begrippen en 2.412 kolombeschrijvingen, en zeven soorten kwaliteitscontrole, van rijtellingen en versheid tot verweesde sleutels en grain
- Een permissiemodel met vijf rollen en een GRANT/DENY-matrix per schema, laadprocedures die onder een vaste eigenaar draaien terwijl de echte aanroeper in de logging blijft staan, en een classificatie van bijzondere persoonsgegevens (AVG artikel 9) op 740 kolommen
In detail
- Een reconciliatie zonder tolerantie: elke nacht worden de datamarts van oud en nieuw per tabel geteld, en een verschil is óf exact verklaard in een verwachtingentabel, óf een melding. Bij de invoering bracht dat het dagrapport terug van 30 naar 6 openstaande afwijkingen
- Fouten die een vergelijking niet ziet, apart geregistreerd: als oud en nieuw even fout zijn, meldt een rijtelling niets. Een bevindingenregister houdt per fout oorzaak, bewijs en status bij, los voor het oude en het nieuwe warehouse, zodat de migratie ook bestaande fouten boven water haalt
- Bewijzen in plaats van aannemen: herbouwde logica wordt gemeten tegen de oude datamart (ongewijzigde kolommen exact gelijk, elk verschil per mechanisme verklaard), en 28 end-to-end-testsuites draaien als één regressieketen, omdat de build de dynamische SQL van een metadata-engine niet kan valideren
- Een generale repetitie van de datamigratie, met hashverificatie, rollback, herstart en een idempotentie-tegenproef. Die repetitie vond een geporte view die op een gevulde database ruim vijf uur nodig had; na de fix 57 seconden, met bewijs dat de uitkomst niet veranderde
- Tempo uit een vaste werkwijze: per domein een ontwerp met expliciete keuzes en een implementatieplan met de volledige SQL per taak; elke taak wordt uitgevoerd door een AI-agent en nagelopen door een tweede, onafhankelijke agent die zelf hertest. Ontwerpkeuzes en merges blijven mensenwerk. De engine en de eerste veertien plannen stonden in tien dagen
Resultaat
Stand per september 2026: de logica van alle veertien bronnen is geport, met 138 datamarttabellen op een catalogus van 499 brontabellen, en sinds begin september draait het nieuwe warehouse elke nacht als schaduw naast het bestaande op de pre-productieomgeving, met kwaliteitscontroles en de dagelijkse reconciliatie. Tot nu toe ruim tien weken en ruim 700 commits. Wat nog komt: de testfase en de cutover, waarin de rapporten overstappen naar het nieuwe warehouse.