Vraag tien organisaties naar hun dashboardprobleem en negen keer is het geen dashboardprobleem. De cijfers kloppen niet met elkaar, niemand weet welke definitie waar vandaan komt, en elke wijziging in de bron breekt stilletjes drie rapportages. Het echte werk zit onder de visualisatie: een datamodel dat klopt, gedocumenteerd is en getest wordt.
Dat werk is lastig te laten zien in een portfolio — het speelt zich normaal
gesproken af achter de firewall van een opdrachtgever. Daarom bouw ik het in de
openbaarheid na, op data die van ons allemaal is: nl-open-data-warehouse,
een end-to-end analyseplatform op Nederlandse open data.
De opzet
De bron is het open-datakentekenregister van de RDW — miljoenen voertuigen, vrij beschikbaar, met echte volumes en echte datakwaliteitsproblemen — verrijkt met CBS-gegevens per gemeente. De keten:
- Ingestie. Een Python-loader haalt de data incrementeel op en schrijft ruwe bestanden weg. Geen handwerk: opnieuw draaien geeft hetzelfde resultaat.
- Warehouse. DuckDB als motor — gratis, snel en draaibaar in CI. Het dbt-project is zo opgezet dat dezelfde modellen ook op Snowflake of Databricks landen; alleen de connectie verschilt.
- Transformatie. dbt in drie lagen: staging (schoonmaken en hernoemen), warehouse (het sterschema) en marts (klaar voor gebruik).
Kimball, expliciet
Het hart van het project is een dimensioneel model volgens Kimball — en dan niet impliciet, maar opgeschreven. Elke feittabel heeft een grain statement: één zin die vastlegt wat één rij betekent ("één rij per voertuigregistratie"). Elke dimensie heeft een gedocumenteerde keuze over historie (SCD type 1 of 2) en waarom.
Dat klinkt als formaliteit. Het is het verschil tussen een model waar je zes maanden later nog op durft te bouwen en een verzameling tabellen waar niemand meer aan wil zitten. De cijferdiscussies die ik bij opdrachtgevers tegenkom, beginnen vrijwel altijd bij een grain die nooit is vastgelegd.
Testen als gewoonte, niet als project
Elke wijziging gaat via een pull request, en elke pull request draait de
volledige keten: linting op SQL en Python, daarna dbt build met alle tests —
uniciteit, verplichte velden, referentiële integriteit tussen feiten en
dimensies. Rood is rood; er gaat niets mee naar main.
Een datamodel zonder tests is een belofte. Een datamodel met tests in CI is een afspraak.
De dbt-documentatie met de volledige lineage — van ruwe bron tot mart — wordt bij elke wijziging opnieuw gegenereerd, zodat de documentatie per definitie niet kan verouderen.
Waarom dit relevant is voor jouw organisatie
Alles in dit project is één-op-één toepasbaar op de omgevingen waarin ik werk: een stuurinformatievoorziening die betrouwbaar moet zijn, definities die vastliggen, wijzigingen die niet stilletjes iets mogen breken. De technologie verschilt per organisatie — SAS, Power BI, Databricks, Snowflake — maar de discipline is overal dezelfde.
De volledige code en documentatie staan op GitHub.
Benieuwd hoe zo'n fundament er onder jouw rapportages uit zou zien? Plan een kennismaking — dan kijk ik graag een keer mee.