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.

Om dit concreet te houden, volgen we doorheen het hoofdstuk één doorlopend voorbeeld: een fictief maar realistisch SaaS-bedrijf, "Flowmetric", dat facturatiesoftware verkoopt aan MKB-klanten. We volgen hoe hun dataplatform evolueert van een eerste dashboard voor de founder tot een platform dat honderden interne gebruikers en een extern klantenportaal bedient. De architectuurbeslissingen die daarbij spelen, zijn geen hypothetische theorie — het zijn dezelfde beslissingen die ik bij vrijwel elke opdracht opnieuw tegenkom.

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.

Case Study: Flowmetric van Startup naar Schaal

Fase 1 — één founder, één spreadsheet, dan één warehouse (0-10 medewerkers). Flowmetric begint zoals bijna elk bedrijf: de founder wil weten hoeveel omzet er binnenkomt. In deze fase is de "architectuur" één Snowflake-warehouse (of een gratis BigQuery-sandbox), data komt handmatig of via een enkel Fivetran-connectortje binnen uit Stripe, en er is precies één dbt-project met een man of twee, drie modellen. Dit is prima. De fout die ik hier het vaakst zie is niet te weinig architectuur, maar te veel: een team van twee mensen dat een Kafka-cluster opzet voor 500 events per dag omdat "we willen schaalbaar zijn." Bouw in fase 1 het simpelste dat werkt, met de medallion-basisstructuur (bronze/silver/gold) er al wél in, omdat die structuur later vrijwel niets kost om aan te houden en achteraf invoeren pijnlijk is.

Fase 2 — meerdere teams, meerdere bronsystemen (10-100 medewerkers). Flowmetric heeft nu een salesteam met een eigen CRM, een supportteam met een ticketsysteem, en een productteam dat event-tracking wil. Dit is het punt waarop ingestion een systeem wordt in plaats van een los scriptje: Fivetran of Airbyte voor de SaaS-bronnen, een eigen CDC-pipeline voor de productiedatabase omdat een dagelijkse volledige export te traag wordt. De silver-laag krijgt voor het eerst echte datakwaliteitsregels, omdat er nu mensen zijn die de cijfers gebruiken die de engineer die de pipeline bouwde nooit heeft gesproken. Dit is ook het moment waarop data contracts (verderop in dit hoofdstuk) van "aardig om te hebben" naar "noodzakelijk" gaan, omdat het productteam een kolom hernoemt zonder dat iemand in het dataeam het weet — en het omzetdashboard van de CFO een week lang stil staat op nul.

Fase 3 — platform als product, honderden gebruikers (100+ medewerkers). Flowmetric heeft nu een intern datateam van vijf mensen, een self-service BI-cultuur met tientallen analisten die zelf dbt-modellen bouwen, en een extern klantenportaal dat live metrics toont — wat betekent dat het dataplatform niet langer alleen intern is, maar onderdeel van het product zelf, met bijbehorende eisen aan uptime en latency. Hier verschijnen governance en toegangsbeheer als eerste-klas architectuurbeslissing (zie verderop), een formeel orchestratieplatform vervangt losse cron-jobs, en de vraag "welk warehouse-platform gebruiken we" krijgt een heel ander gewicht dan in fase 1 — een migratie op dit niveau kost al snel maanden.

Het punt van deze case study is niet dat elk bedrijf deze exacte fasen doorloopt, maar dat architectuur die in fase 1 correct aanvoelt (simpel, weinig lagen, één platform) in fase 3 problematisch wordt, en andersom — een fase 3-architectuur toepassen in fase 1 is de meest voorkomende vorm van over-engineering die ik zie bij startups en early-stage teams.

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. Voor Flowmetric in fase 2 betekent dit: de ruwe Stripe-facturen, de ruwe CRM-deals, de ruwe supporttickets, elk in hun eigen bronze-tabel, ongefilterd. 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 — relevant, want Stripe bewaart lang niet alle historische API-responses in dezelfde vorm.

Silver bevat schone, gededupliceerde, correct getypeerde data — één betrouwbare rij per entiteit, maar nog niet noodzakelijk geaggregeerd of verrijkt met businesslogica. Voor Flowmetric: één rij per factuur, gededupliceerd, met een consistent valutaformaat ongeacht of de brondata in centen of euro's stond. 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. Voor Flowmetric: gold.mrr_per_maand, gold.churn_per_segment — tabellen die letterlijk de vraag beantwoorden die iemand in een dashboard stelt, zonder dat die persoon een join hoeft te schrijven.

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.

Een Concreet Kostenvoorbeeld

Featurevergelijkingen zijn abstract; kosten zijn dat niet. Stel Flowmetric in fase 2 heeft een nachtelijke batchjob die 45 minuten draait op een medium-compute-node, plus continu een klein aantal interactieve BI-queries overdag. Ruwweg vertaalt zich dat naar twee zeer verschillende kostenprofielen, afhankelijk van hoe bewust je het inricht:

• Zonder workload-scheiding (één warehouse/cluster voor alles, altijd op medium-formaat): je betaalt het medium-tarief 24/7, ook tijdens de 22 uur per dag dat er niemand een query draait — dit is verreweg de meest voorkomende manier waarop teams onnodig geld verbranden.
• Met workload-scheiding en auto-suspend (een XS-warehouse voor interactieve BI-queries dat na 60 seconden inactiviteit stopt, en een apart medium-warehouse dat alleen 45 minuten per nacht draait voor de batchjob): je betaalt alleen voor de daadwerkelijke 45 minuten batch-compute plus de paar cumulatieve minuten dat er echt een BI-query loopt — in de praktijk vaak een besparing van 70-90% ten opzichte van het eerste scenario, zonder dat de gebruikerservaring merkbaar verandert.

Dit exacte patroon — auto-suspend, workload-scheiding, rechtsizing — is platformonafhankelijk: Snowflake noemt het warehouse-sizing, Databricks noemt het cluster-autoscaling en job-vs-all-purpose-clusters, Fabric regelt het via capacity-toewijzing. De architectuurles is hetzelfde ongeacht het platform: compute die niet actief gebruikt wordt, hoort niet te draaien, en dat is een instelling, geen toeval.

De praktische vuistregel voor platformkeuze: 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. Bij Flowmetric wordt dit concreet zodra het externe klantenportaal live metrics toont: op dat moment is een verkeerd ingestelde rol niet langer een intern ongemak, maar een datalek naar een klant van een andere klant.

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.

Data Contracts: de Grens Tussen Teams Vastleggen

Terug naar het moment in fase 2 waarop het productteam bij Flowmetric een kolom hernoemt en het omzetdashboard breekt. Dit is geen ongeluk dat je met meer alertheid voorkomt — het is een architectuurprobleem: er was geen expliciete, afdwingbare afspraak tussen het team dat de brondata produceert en het team dat die consumeert. Een data contract is precies die afspraak, vastgelegd als code in plaats van als document dat niemand meer leest:

# contracts/orders.yml — afspraak tussen het productteam (bron) en het datateam (consument)
contract:
  table: production.orders
  owner: product-team
  consumers: [data-team, finance-team]
  schema:
    - name: order_id
      type: string
      nullable: false
    - name: customer_id
      type: string
      nullable: false
    - name: amount_cents
      type: integer
      nullable: false
      description: "Bedrag in centen, NOOIT euro's — zie ADR-014"
    - name: status
      type: string
      allowed_values: [pending, paid, refunded, cancelled]
  breaking_change_policy: "Kolommen verwijderen of hernoemen vereist 30 dagen aankondiging in #data-contracts"

Dit bestand is geen documentatie in de zin van "leuk om te hebben" — het is idealiter gekoppeld aan een CI-check die faalt als het productteam een pull request opent die het schema van production.orders breekt zonder dit bestand bij te werken, vergelijkbaar met hoe dbt-tests (behandeld in Data Quality & Testing) silver- en gold-modellen bewaken. Het verschil is de richting: dbt-tests bewaken wat jouw team bouwt; data contracts bewaken wat een ander team aan jou levert — en dat is precies de grens waar de meeste platform-brede incidenten ontstaan.

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. Voor Flowmetric in fase 3, met tientallen onderling afhankelijke modellen, is dit het verschil tussen een Airflow-DAG die niemand meer durft aan te passen en een dependency graph die dbt of DLT automatisch afleidt en visualiseert.

Een Referentiearchitectuur

Een representatieve architectuur voor een platform op het niveau van Flowmetric in fase 2-3, 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. Merk op dat het externe klantenportaal uit fase 3 hier niet rechtstreeks op gold inhaakt, maar via een aparte "Serving"-laag (API's, reverse ETL) — een extern-gerichte applicatie mag nooit direct tegen je warehouse bevragen, zowel om performance-isolatie als om governance-redenen.

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.

Warehouse-sizing als infrastructuur-als-code, zodat het kostenvoorbeeld van hierboven (workload-scheiding, auto-suspend) reproduceerbaar en reviewbaar is in plaats van een eenmalige handmatige klik in een dashboard:

# warehouses.tf — Terraform, workload-scheiding zoals hierboven beschreven
resource "snowflake_warehouse" "bi_interactive" {
  name           = "BI_INTERACTIVE_WH"
  warehouse_size = "X-Small"
  auto_suspend   = 60      # seconden — stop bijna direct na de laatste query
  auto_resume    = true
}

resource "snowflake_warehouse" "nightly_batch" {
  name           = "NIGHTLY_BATCH_WH"
  warehouse_size = "Medium"
  auto_suspend   = 300
  auto_resume    = true
}

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.
• Formaliseer data contracts tussen teams, niet alleen tests binnen je eigen team — de meeste platform-brede incidenten ontstaan op de grens tussen teams, niet binnen één team.
• Match de architectuur aan de huidige fase van je organisatie, niet aan waar je over drie jaar hoopt te zijn — zie de Flowmetric-case study hierboven.
• Laat externe/klantgerichte applicaties nooit rechtstreeks tegen het warehouse bevragen — altijd via een aparte serving-laag (API, reverse ETL) voor performance-isolatie en governance.

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, precies het scenario uit het kostenvoorbeeld hierboven.
• 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.
• Externe applicaties direct op het warehouse aansluiten. Een klantenportaal dat rechtstreeks tegen gold-tabellen queryt lijkt in fase 1 een snelle oplossing, maar koppelt de latency en beschikbaarheid van je analytics-platform aan die van je product — één zware interne backfill kan dan een klant-facing feature vertragen.
• Eén architectuur voor alle fases proberen te bouwen. Proberen in fase 1 al de governance- en schaal-eisen van fase 3 te implementeren, wat vooral vertraging oplevert zonder dat er nog gebruikers zijn die er baat bij hebben.

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 — zie het Terraform-voorbeeld hierboven.
• 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.
• Zet auto-suspend standaard laag (60-120 seconden) op elk interactief warehouse/cluster, en behandel een hogere waarde als een bewuste uitzondering, niet als standaardinstelling.
• Meet vóór je optimaliseert. Een architectuurwijziging die "logisch" klinkt maar niet gemeten is tegen een concreet knelpunt (kosten, latency, doorlooptijd) is giswerk — begin bij de metriek, niet bij de oplossing.

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.

"Wat is een data contract, en welk probleem lost het op?" Let op: een expliciete, afdwingbare afspraak tussen een producerend en consumerend team over een schema, met een concreet voorbeeld van hoe dat een productieincident had kunnen voorkomen — niet alleen "het is documentatie".

"Hoe zou je een externe, klant-facing feature op je dataplatform aansluiten zonder je interne analytics te vertragen?" Let op: het besef dat directe queries tegen het warehouse vanuit een externe applicatie een architectuurfout is, en een voorstel voor een aparte serving-laag (API, reverse ETL, of een gerepliceerde read-store).

"Hoe pas je je architectuur aan naarmate een organisatie groeit van 10 naar 200 medewerkers?" Let op: herkenning dat architectuur moet meegroeien met organisatorische complexiteit (meerdere teams, meerdere bronnen, externe gebruikers) in plaats van in één keer "compleet" gebouwd te worden — de kern van de Flowmetric-case study.

Relevante Documentatie

• Snowflake Architecture Overview — officiële uitleg van de storage/compute-scheiding.
• Snowflake Warehouse Considerations — sizing en auto-suspend in de praktijk.
• 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.
• dbt Labs: Data Contracts — hoe dbt schema-afspraken native ondersteunt via model contracts.

Samenvatting

Een modern dataplatform draait niet om welk specifiek product je kiest, maar om architectonische principes die platformonafhankelijk zijn: ingestion losgekoppeld van transformatie, storage en compute die onafhankelijk schalen, transformatielogica vastgelegd als versiebeheerde code, en expliciete data contracts op de grenzen tussen teams. Medallion architecture (bronze/silver/gold) is het patroon dat deze principes in de praktijk brengt, met foutisolatie als kernvoordeel. De Flowmetric-case study laat zien dat de juiste architectuur niet vaststaat, maar meegroeit met de fase van de organisatie — wat in fase 1 verstandige eenvoud is, is in fase 3 een risico, en andersom. De keuze tussen Snowflake, Databricks en Fabric is een workload-vraag met een reëel, meetbaar kostenaspect (zoals het warehouse-sizingvoorbeeld liet zien), geen religieuze discussie. Met deze architectuurprincipes op zak ben je klaar voor de platformspecifieke hoofdstukken die hierna volgen.