Modern Dataplatform Architectuur

Introductie

"Modern dataplatform" is een van die termen die overal wordt gebruikt en zelden wordt gedefinieerd. In dit hoofdstuk bedoelen we er iets specifieks mee: een architectuur waarin storage en compute onafhankelijk van elkaar schalen, transformatie gebeurt via versiebeheerde, testbare code in plaats van point-and-click ETL-tools, en de platformkeuze wordt gedreven door concrete workload-eisen in plaats van door wat net op een conferentie werd gepitcht.

De vorige hoofdstukken behandelden losse bouwstenen — de stacklagen in Introduction to Data Engineering, de SQL-patronen in SQL for Data Engineers. Dit hoofdstuk zet een stap terug en behandelt de architectuurbeslissingen die bepalen hoe die bouwstenen samen een platform vormen dat na twee jaar nog steeds prettig is om op te werken — in plaats van een systeem waar niemand meer aan durft te komen.

De Drie Lagen Die Elk Platform Nodig Heeft

Ongeacht welke specifieke tools je kiest, elk volwassen dataplatform heeft drie architectonisch gescheiden lagen nodig, en de meeste problemen die ik in bestaande platformen tegenkom, zijn terug te voeren op het vermengen van deze lagen.

Ingestion, losgekoppeld van transformatie. De code die data binnenhaalt uit bronsystemen mag geen businesslogica bevatten. Zijn enige taak is data zo betrouwbaar mogelijk, in een zo ruw mogelijke vorm, naar storage krijgen. Zodra ingestion-code begint te filteren, aggregeren of "opschonen", verlies je de mogelijkheid om transformatielogica later te herzien zonder opnieuw te hoeven extraheren — en dat is precies de situatie waarin platformen vastlopen.

Storage en compute, onafhankelijk schaalbaar. Dit is de architectonische doorbraak die Snowflake, Databricks en Fabric allemaal delen (in tegenstelling tot traditionele on-premises warehouses): je betaalt voor opslag naar wat je daadwerkelijk bewaart, en voor compute naar wat je daadwerkelijk verwerkt, en die twee kosten schalen onafhankelijk van elkaar. Praktisch betekent dit dat je een goedkoop, altijd-aan opslaglaag kunt hebben met daarnaast meerdere, los van elkaar schaalbare compute-clusters voor verschillende workloads — een zwaar nachtelijk backfill-proces hoeft de compute voor interactieve BI-queries overdag niet te beïnvloeden.

Transformatie, als code. Business logica hoort in versiebeheerde, testbare, reviewbare code — SQL-bestanden in een dbt-project, of Python/Scala in Spark-notebooks die via CI/CD worden gedeployed. Niet in een GUI-gebaseerde ETL-tool waar wijzigingen niet te diffen zijn en waar "wie heeft dit veranderd en waarom" een archeologische opgave wordt. Dit is het onderwerp van dbt en CI/CD for Data Engineering.

Medallion Architecture als de Facto Standaard

Binnen de transformatielaag heeft één patroon zich de afgelopen jaren ontwikkeld tot de facto standaard: medallion architecture, met bronze-, silver- en gold-lagen. Dit is niet zomaar een naamgevingsconventie — het codificeert een specifieke verantwoordelijkheidsverdeling die rechtstreeks voortkomt uit de scheiding tussen ingestion en transformatie hierboven.

Bronze bevat ruwe, ongewijzigde data, precies zoals die uit de bron kwam — inclusief duplicaten, foute types en ontbrekende waarden. Dit is je vangnet: als transformatielogica een bug bevat die pas maanden later wordt ontdekt, kun je silver en gold herbouwen vanuit bronze zonder opnieuw te hoeven extraheren uit een bronsysteem dat inmiddels misschien niet meer dezelfde data teruggeeft.

Silver bevat schone, gededupliceerde, correct getypeerde data — één betrouwbare rij per entiteit, maar nog niet noodzakelijk geaggregeerd of verrijkt met businesslogica. Dit is de laag waar de meeste datakwaliteitsvalidatie plaatsvindt.

Gold bevat businessklare, vaak geaggregeerde tabellen, direct bruikbaar door BI-tools of downstream-applicaties — precies gemodelleerd naar de vraag die ze moeten beantwoorden, niet naar de vorm van de bron.

De kracht van dit patroon zit in de foutisolatie: elke laag is onafhankelijk herbouwbaar, en een fout in één laag corrumpeert nooit stilletjes de lagen ervoor. Zie Medallion Architecture voor een volledige uitwerking, inclusief hoe dit patroon zich verhoudt tot Data Vault als alternatieve modelleeraanpak in Data Vault 2.0.

Platform Kiezen: Snowflake versus Databricks versus Fabric

Dit is de vraag die ik het vaakst krijg, en het eerlijke antwoord is dat de drie grote platformen dichter bij elkaar zijn komen te liggen dan marketingmateriaal doet vermoeden — Snowflake heeft met Snowpark en Dynamic Tables Spark-achtige en declaratieve mogelijkheden toegevoegd, Databricks heeft met Databricks SQL en Unity Catalog een warehouse-achtige ervaring bovenop het lakehouse gebouwd, en Microsoft Fabric probeert beide werelden vanaf het begin te combineren. Toch zijn er praktische verschillen die de keuze bepalen.

Snowflake blinkt uit wanneer je primaire workload SQL-gebaseerde analytics is met veel gelijktijdige gebruikers. De scheiding tussen storage en meerdere onafhankelijk schaalbare virtual warehouses is uitzonderlijk volwassen, en het beheer is eenvoudiger dan bij Spark-gebaseerde platformen omdat je zelden onder de motorkap hoeft te kijken. De keerzijde: voor zware, custom Python/ML-workloads voelt het minder natuurlijk dan Databricks, en de kosten kunnen oplopen als warehouses niet actief worden beheerd op auto-suspend-instellingen.

Databricks is de sterkere keuze wanneer machine learning, complexe Python/Scala-transformaties, of streaming-workloads een substantieel deel van je platform vormen. Het notebook-gedreven ontwikkelmodel en de directe toegang tot Spark maken het flexibeler voor niet-SQL-workloads, en Delta Lake (behandeld in Delta Lake) geeft ACID-garanties op een lakehouse die vroeger alleen warehouses boden. De keerzijde: het beheren van clustergrootte en -configuratie vraagt meer operationele kennis dan Snowflake's warehouse-model.

Microsoft Fabric is het meest overtuigend voor organisaties die al diep in het Microsoft-ecosysteem zitten — Power BI, Azure Active Directory, Office 365 — en die profiteren van een unified platform waar ingestion (Data Factory), transformatie (notebooks, dataflows) en rapportage (Power BI) native op elkaar aansluiten zonder aparte licenties en connectoren te hoeven beheren. De keerzijde: als losstaand analytics-platform, buiten het Microsoft-ecosysteem, is het minder volwassen dan de andere twee.

De praktische vuistregel: kies niet op basis van welk platform het meest indrukwekkend klinkt op een conferentie, maar op basis van waar je team al ervaring heeft, welk ecosysteem je organisatie al gebruikt, en of je workload primair SQL-analytics, ML/Python, of een mix is. Een verkeerde platformkeuze is duur om terug te draaien; een middelmatige implementatie op het juiste platform is altijd beter dan een perfecte implementatie op het verkeerde platform.

Governance en Security als Architectuurbeslissing

Een fout die ik regelmatig zie: governance en security worden behandeld als iets dat je "later nog even toevoegt" zodra het platform draait. Dat werkt niet — wie toegang heeft tot welke laag, hoe gevoelige kolommen (BSN's, e-mailadressen, betaalgegevens) worden gemaskeerd, en hoe lineage wordt vastgelegd, zijn beslissingen die de architectuur zelf raken, niet een laagje dat je er achteraf overheen legt.

Concreet betekent dit: rolgebaseerde toegang instellen per laag (bronze doorgaans alleen toegankelijk voor het data-engineeringteam, gold breder beschikbaar voor analisten), kolomniveau-maskering voor PII direct in de silver-laag definiëren zodat gevoelige data nooit onbeschermd in gold terechtkomt, en lineage-tools (Unity Catalog bij Databricks, Purview bij Microsoft Fabric/Azure) vanaf dag één aankoppelen in plaats van pas wanneer een auditor ernaar vraagt. Dit wordt in detail behandeld in Data Governance en Data Security.

Orchestratie & de Opkomst van Declaratieve Pipelines

Een merkbare verschuiving in platformarchitectuur de afgelopen jaren is de beweging van imperatieve orchestratie ("draai stap A, dan stap B, dan stap C, in deze volgorde, op dit tijdstip") naar declaratieve pipelines ("dit is de gewenste eindtoestand van deze tabel; het platform bepaalt zelf hoe en wanneer die actueel gehouden wordt").

dbt was hier vroeg bij: je definieert modellen als SQL-SELECT-statements en dbt leidt de afhankelijkheidsgrafiek automatisch af uit ref()-aanroepen, in plaats van dat jij handmatig een DAG met volgordes onderhoudt. Snowflake's Dynamic Tables en Databricks' Delta Live Tables (DLT) trekken dit patroon nog verder door: je declareert een query en een verversingsdoel (TARGET_LAG bij Snowflake), en het platform bepaalt zelf de uitvoeringsfrequentie en -volgorde over een hele keten van afhankelijke tabellen. Het verschil tussen deze declaratieve objectbeheer-aanpak en dbt's rol als transformatietool wordt in detail behandeld in twee gerelateerde artikelen op onze blog: dbt vs Snowflake DCM en Snowflake DCM vs Databricks Asset Bundles.

Deze verschuiving vermindert niet de noodzaak van orchestratietools als Airflow of Dagster — die blijven essentieel voor het coördineren van cross-platform workflows (bijvoorbeeld: wacht tot een externe API-extractie klaar is, trigger dan een dbt-run, en start pas daarna een ML-trainingsjob) — maar het verplaatst een groot deel van de binnen-platform verversingslogica van handmatig geplande DAG's naar declaratieve, door het platform beheerde afhankelijkheidsgrafieken.

Een Referentiearchitectuur

Een representatieve architectuur voor een middelgroot dataplatform, samengevoegd uit de patronen hierboven:

┌─────────────┐     ┌──────────────┐     ┌────────────────────────────┐
│  Bronnen    │     │  Ingestion   │     │         Storage             │
│             │     │              │     │                              │
│ Postgres    │────▶│ Fivetran /   │────▶│  🥉 bronze  (ruw, append-only)│
│ Stripe API  │     │ Airbyte /    │     │  🥈 silver  (schoon, gededupl.)│
│ Event stream│────▶│ Kafka        │     │  🥇 gold    (business-klaar)  │
└─────────────┘     └──────────────┘     └──────────────┬───────────────┘
                                                          │
                     ┌──────────────┐                    │
                     │Transformatie │◀───────────────────┘
                     │  dbt / Spark │
                     └──────┬───────┘
                             │
                     ┌───────▼──────┐     ┌─────────────┐
                     │ Orchestratie │     │   Serving    │
                     │Airflow/Dagster├────▶│ Power BI    │
                     └──────────────┘     │ Reverse ETL │
                                           │ API's       │
                                           └─────────────┘

De pijl van transformatie terug naar storage (bronze → silver → gold, allemaal binnen dezelfde storage-laag) is bewust: transformatie verplaatst data niet naar een apart systeem, het herschrijft data binnen dezelfde storage-laag naar een verder verfijnde vorm — precies het punt van de storage/compute-scheiding die dit hele model economisch maakt.

Codevoorbeelden

Een dbt-model dat silver naar gold transformeert, met expliciete afhankelijkheid via ref():

-- models/gold/revenue_by_category.sql
{{ config(materialized='table') }}

WITH orders AS (
    SELECT * FROM {{ ref('silver_orders') }}
),
products AS (
    SELECT * FROM {{ ref('silver_products') }}
)

SELECT
    p.category,
    DATE_TRUNC('day', o.order_date) AS order_day,
    SUM(o.amount) AS revenue,
    COUNT(DISTINCT o.order_id) AS order_count
FROM orders o
JOIN products p ON p.product_id = o.product_id
GROUP BY p.category, DATE_TRUNC('day', o.order_date)

Een Databricks-notebookfragment dat dezelfde gold-laag bouwt met PySpark, voor een platform waar de transformatielaag Spark is in plaats van dbt-SQL:

# gold_revenue_by_category.py
from pyspark.sql import functions as F

orders = spark.read.table("silver.orders")
products = spark.read.table("silver.products")

gold_revenue = (
    orders
    .join(products, "product_id")
    .groupBy("category", F.date_trunc("day", "order_date").alias("order_day"))
    .agg(
        F.sum("amount").alias("revenue"),
        F.countDistinct("order_id").alias("order_count"),
    )
)

gold_revenue.write.format("delta").mode("overwrite").saveAsTable("gold.revenue_by_category")

Een Fabric-pipelineschets die laat zien hoe dezelfde bronze→silver→gold-keten wordt uitgedrukt als pipeline-activiteiten in Microsoft Fabric:

{
  "name": "revenue_pipeline",
  "activities": [
    { "name": "Copy_Orders_to_Bronze", "type": "Copy", "dependsOn": [] },
    { "name": "Notebook_Bronze_to_Silver", "type": "Notebook", "dependsOn": ["Copy_Orders_to_Bronze"] },
    { "name": "Notebook_Silver_to_Gold", "type": "Notebook", "dependsOn": ["Notebook_Bronze_to_Silver"] }
  ]
}

Deze drie voorbeelden zijn bewust functioneel identiek — hetzelfde referentiepatroon, drie verschillende platformen. Dat is precies het punt: de architectuur staat los van het gekozen platform, alleen de syntax verandert.

Best Practices

• Ontkoppel ingestion volledig van transformatie. Ingestion-code mag geen businesslogica bevatten; zijn enige taak is data zo ruw mogelijk laten landen.
• Behandel elke laag als onafhankelijk herbouwbaar. Als je silver of gold niet vanaf nul kunt herbouwen vanuit bronze, heb je geen medallion-architectuur — je hebt alleen een naamgevingsconventie.
• Kies je platform op basis van workload, niet van hype. SQL-zware analytics wijst naar Snowflake, Python/ML-zware workloads wijzen naar Databricks, diepe Microsoft-integratie wijst naar Fabric.
• Leg transformatielogica vast als code, gereviewd en getest via CI/CD — nooit in een GUI-tool waar wijzigingen niet te diffen zijn.
• Documenteer de afhankelijkheidsgrafiek expliciet, of laat een tool als dbt die automatisch afleiden uit ref()-aanroepen, zodat niemand een tabel per ongeluk breekt door een upstream-wijziging.

Veelgemaakte Fouten

• Over-engineering vanaf dag één. Een volledige medallion-architectuur met vijf lagen en real-time streaming bouwen voor een dataset van tien miljoen rijen die één keer per dag wordt bijgewerkt. Begin eenvoudig; voeg complexiteit toe wanneer een concrete eis dat rechtvaardigt, niet vooraf.
• Platformkeuze op basis van hype in plaats van fit. Overstappen naar een nieuw platform omdat een concurrent het gebruikt, zonder de workload-eisen te analyseren die daadwerkelijk bepalen welk platform past.
• Kostengovernance negeren. Geen budgetalerts, geen auto-suspend op warehouses, geen review van clustergroottes — waardoor compute-kosten ongemerkt groeien tot iemand de rekening ziet.
• Geen data contracts tussen teams. Downstream-consumenten die stilletjes breken omdat een bronteam een tabel wijzigt zonder enige vorm van afspraak of versiebeheer op het schema.
• Eén enorme monolithische transformatiejob. In plaats van kleine, onafhankelijk testbare modellen (het dbt-patroon), één gigantische SQL-of Spark-job die alles in één keer doet — onmogelijk te debuggen als er iets misgaat, en alles moet opnieuw draaien voor elke kleine wijziging.

Performance Tips

• Scheid compute per workload. Een apart, klein warehouse of cluster voor interactieve BI-queries en een apart, groter warehouse voor nachtelijke batchjobs voorkomt dat de twee elkaar in de weg zitten en maakt kosten per workload zichtbaar.
• Gebruik incrementele modellen agressief in de silver- en gold-laag. Volledige herberekening is acceptabel in bronze (waar data toch al ruw binnenkomt), maar wordt snel onbetaalbaar in silver/gold naarmate historie opbouwt.
• Monitor query-patronen, niet alleen jobduur. Een pipeline die binnen zijn tijdvenster blijft, kan alsnog inefficiënt zijn — kijk naar bytes gescand, niet alleen naar kloktijd.
• Cache of materialiseer dure, veelgebruikte joins in een aparte tussenlaag in plaats van dezelfde zware join in meerdere downstream-modellen te herhalen.

Interviewvragen

"Hoe zou je een dataplatform ontwerpen voor een bedrijf dat net begint met data engineering?" Let op: een pleidooi voor eenvoud eerst — een basale bronze/silver/gold-structuur op één platform, geen premature streaming of multi-platform-complexiteit, met ruimte om later uit te breiden.

"Wanneer zou je Databricks kiezen boven Snowflake, en andersom?" Let op: een concreet, workload-gebaseerd antwoord (SQL-analytics vs. ML/Python-zwaar), niet een oppervlakkige featurevergelijking.

"Leg uit wat medallion architecture is en waarom elke laag bestaat." Let op: begrip van foutisolatie en onafhankelijke herbouwbaarheid als de kernreden, niet alleen "bronze is ruw, gold is schoon".

"Wat is het verschil tussen orchestratie en declaratieve pipelines zoals dbt of Delta Live Tables?" Let op: orchestratie bepaalt wanneer en in welke volgorde stappen draaien (imperatief); declaratieve tools leiden dat automatisch af uit gedefinieerde afhankelijkheden en een gewenste eindtoestand.

"Hoe zou je kostenbeheersing inbouwen in een nieuw dataplatform vanaf het begin?" Let op: auto-suspend/auto-scaling instellingen, aparte compute per workload, budgetalerts, en periodieke review van query-patronen — niet pas kostenbeheersing toevoegen nadat de rekening al hoog is.

Relevante Documentatie

• Snowflake Architecture Overview — officiële uitleg van de storage/compute-scheiding.
• Databricks Lakehouse Architecture — hoe Delta Lake ACID-garanties toevoegt aan een data lake.
• Microsoft Fabric Architecture — hoe de unified Fabric-lagen samenhangen.
• dbt Labs: How We Structure Our dbt Projects — de industriestandaard voor bronze/silver/gold-structurering binnen dbt.

Samenvatting

Een modern dataplatform draait niet om welk specifiek product je kiest, maar om drie architectonische principes die platformonafhankelijk zijn: ingestion losgekoppeld van transformatie, storage en compute die onafhankelijk schalen, en transformatielogica vastgelegd als versiebeheerde, testbare code. Medallion architecture (bronze/silver/gold) is het patroon dat deze principes in de praktijk brengt, met foutisolatie als kernvoordeel. De keuze tussen Snowflake, Databricks en Fabric is een workload-vraag, geen religieuze — SQL-zware analytics, Python/ML-zware verwerking, en Microsoft-ecosysteemintegratie wijzen elk een andere kant op. De verschuiving richting declaratieve pipelines (dbt, Dynamic Tables, Delta Live Tables) vermindert de handmatige orchestratielast binnen een platform, maar vervangt orchestratietools als Airflow niet voor cross-platform-coördinatie. Met deze architectuurprincipes op zak ben je klaar voor de platformspecifieke hoofdstukken die hierna volgen.