Hoe pak je een data engineering project aan?

Elk data engineering project begint met hetzelfde fundamentele proces, ongeacht de schaal of complexiteit. Voordat je een regel code schrijft, moet je antwoord hebben op een aantal cruciale vragen:

• Wat is de databron? Is het een database, een API, een bestandssysteem, een streaming feed? Hoe vaak wordt de data bijgewerkt?
• Wie gebruikt de data en waarvoor? BI-dashboards, machine learning modellen, operationele rapporten? Dit bepaalt de vorm en frequentie van de output.
• Wat zijn de kwaliteitseisen? Hoeveel latency is acceptabel? Hoeveel fouten zijn toelaatbaar? Wat zijn de gevolgen van verkeerde data?
• Wat is het datavolume? Megabytes per dag of terabytes per uur? Dit bepaalt of je batch of streaming nodig hebt, en welke tools je kiest.
• Wat zijn de compliance-eisen? Bevat de data persoonsgegevens (AVG)? Zijn er sector-specifieke regelgeving (financieel, zorg)?

Na het beantwoorden van deze vragen ontwerp je de architectuur: welke lagen, welke tools, hoe worden data getransformeerd en opgeslagen. Dan pas begin je met bouwen — liefst iteratief, startend met de meest kritieke databron.

Project 1: Retail analytics platform

Context

Een middelgrote Nederlandse retailer met 45 winkels wil inzicht in verkoopprestaties per winkel, per productcategorie en per dag. Momenteel exporteert het kassasysteem dagelijks CSV-bestanden naar een netwerkschijf. Analisten importeren deze handmatig in Excel. Het doel: een geautomatiseerd data platform dat dagelijks bijgewerkte dashboards levert in Power BI.

Architectuur

• Bron: kassasysteem CSV-exports op Azure Blob Storage (automatisch geüpload via script)
• Ingestie: Azure Data Factory triggert dagelijks bij aankomst van nieuwe bestanden
• Opslag: Azure Data Lake Storage Gen2 in een Bronze/Silver/Gold structuur
• Verwerking: Azure Databricks met PySpark; Bronze → validatie en schema-controle → Silver; Silver → aggregaties en sterschema → Gold
• Serving: Azure Synapse SQL Pool voor Power BI connectie
• Rapportage: Power BI met dagelijks automatisch bijgewerkte dashboards

Datamodel (Gold-laag)

Een klassiek sterschema met:

• fact_verkoop — verkoopregels met bedrag, aantal, tijdstempel, FK's naar dimensies
• dim_winkel — winkelgegevens (naam, stad, regio, oppervlakte)
• dim_product — producthiërarchie (artikel, subcategorie, categorie, merk)
• dim_datum — datumtabel met week, maand, kwartaal, feestdagen
• dim_klant — geanonimiseerde klantgroepen (loyaliteitsprogramma-segment)

Resultaat en geleerde lessen

De gemiddelde tijd van "data in kassasysteem" tot "zichtbaar in dashboard" daalde van 2 werkdagen naar 4 uur. De voornaamste technische uitdagingen waren: inconsistente kolomnamen tussen CSV-exports van verschillende kassasysteem-versies (opgelost met een schema-mapping configuratiebestand) en duplicate records bij herleveringen van bestanden (opgelost met een SCD Type 1 upsert-logica op basis van een samengestelde sleutel).

Project 2: Real-time fraudedetectie

Context

Een Nederlandse betaalverwerker verwerkt 50.000 transacties per minuut. Het fraude-team werkt met batchrapporten van de vorige dag — te traag om actief in te grijpen. Het doel: een streaming pipeline die binnen 30 seconden na een transactie een risicoscore berekent en verdachte transacties markeert voor review.

Architectuur

• Ingestie: elke transactie wordt als event gepubliceerd op Azure Event Hubs (Kafka-compatibel)
• Stream processing: Azure Databricks Structured Streaming leest van Event Hubs, verrijkt de transactie met klanthistorie (lookups op Delta-tabellen) en berekent features
• Scoring: een ML-model (geladen als Databricks model serving endpoint) krijgt de features en retourneert een risicoscore
• Actie: transacties boven drempelwaarde worden gepubliceerd op een aparte Event Hub voor het reviewsysteem van het fraude-team
• Historische opslag: alle transacties en scores worden weggeschreven naar Delta Lake voor model retraining en compliance

Technische uitdagingen

De grootste uitdaging was de latency van lookups: elke transactie moest verrijkt worden met 90 dagen klanthistorie (gemiddeld bedrag, transactiefrequentie, meest voorkomende locaties). Een directe Delta Lake lookup per transactie was te traag bij 50k transacties/minuut. De oplossing: een in-memory cache (Redis) van de meest recente klantprofielen, bijgewerkt elke 5 minuten door een aparte Databricks job. De streaming pipeline raadpleegt Redis, niet Delta Lake.

Resultaat

Gemiddelde latency van transactie tot risicoscore: 12 seconden (ruim binnen het doel van 30 seconden). Fraudedetectie-percentage steeg met 34% vergeleken met het oude batch-systeem doordat de scoring nu plaatsvindt terwijl transacties nog open staan.

Project 3: IoT-data van productiemachines

Context

Een productiebedrijf in de maakindustrie heeft 200 CNC-machines, elk met sensoren die elke seconde temperatuur, trillingsniveaus en productietelling rapporteren. Het doel: een platform dat machine-uitval voorspelt (predictive maintenance) en real-time productie-KPI's bijhoudt.

Architectuur

• Edge: IoT-gateways per productiehal aggregeren sensordata en sturen elk 10 seconden een pakket naar Azure IoT Hub
• Streaming ingestie: Azure IoT Hub → Azure Event Hubs → Databricks Structured Streaming
• Verwerking: Databricks verwerkt de streamingdata, berekent rolling averages (5 min, 1 uur) en detecteert anomalieën (3σ-afwijkingen van baseline)
• ML: een LSTM-model (Long Short-Term Memory neural network) getraind op historische sensordata + storingslogs voorspelt kans op storing in de komende 24 uur
• Alerting: bij hoge storingskans: automatisch bericht naar het onderhoudsteam via Microsoft Teams webhook
• Opslag: Delta Lake met time-travel voor analyse van historische patronen

Geleerde lessen

IoT-projecten kennen specifieke uitdagingen. Sensoren gaan offline, sturen dubbele berichten of leveren corrupted data. Robuuste data quality controles in de Bronze-laag zijn essentieel: valideer of de machine-ID geldig is, of de timestamp binnen een acceptabel window valt, en of sensorwaarden binnen fysieke limieten liggen. Een temperatuursensor die plotseling 5000°C rapporteert is een defecte sensor, niet een echte meting.

Project 4: Data warehouse migratie naar de cloud

Context

Een verzekeraar heeft een on-premise SQL Server Data Warehouse (8 TB, 300 tabellen, ~200 dagelijkse ETL-jobs in SSIS). Het systeem is 12 jaar oud, de server nadert end-of-life en de licentiekosten zijn hoog. Doel: migratie naar Azure Databricks + Azure Synapse Analytics met minimale downtime.

Aanpak in fases

1. Inventarisatie (4 weken): catalogiseer alle tabellen, ETL-jobs en downstream afhankelijkheden. Welke rapporten gebruiken welke tabellen? Dit is cruciaal om niks te missen.
2. Architectuurontwerp (2 weken): ontwerp de nieuwe Bronze/Silver/Gold structuur. Vertaal SSIS-packages naar PySpark notebooks/modules. Ontwerp het nieuwe sterschema in Synapse.
3. Parallelle bouw (12 weken): bouw de nieuwe pipeline naast het bestaande systeem. Draai beide systemen parallel en vergelijk output dagelijks. Zolang de resultaten niet overeenkomen, is de migratie niet klaar.
4. Validatie (4 weken): intensieve validatieperiode. Laat data-eigenaren en analisten de nieuwe dashboards valideren ten opzichte van de oude rapporten. Los discrepanties op.
5. Cutover: op een rustig moment (weekend) wordt het nieuwe systeem de primary source. Het oude systeem blijft nog 4 weken op read-only beschikbaar als fallback.

Resultaat

De migratie duurde in totaal 22 weken. De nachtelijke ETL-runtime daalde van 6,5 uur naar 45 minuten dankzij Spark-parallellisatie. De jaarlijkse kosten daalden met 40% (licenties vs. cloud-kosten). Twee SSIS-packages bleken ongedocumenteerde business-logica te bevatten die tijdens de validatiefase ontdekt werd — een klassieke valkuil bij migraties.

Project 5: Marketing data platform

Context

Een e-commercebedrijf heeft data verspreid over tien systemen: Google Analytics, Meta Ads, Google Ads, CRM (HubSpot), e-mailplatform (Klaviyo), webshop (Shopify) en klantenservice (Zendesk). Marketeers halen data handmatig op per platform en combineren ze in Excel. Het doel: een geïntegreerd marketing data platform dat alle kanalen samenvoegt.

Architectuur

• Ingestie: Fivetran als ELT-tool voor gestandaardiseerde connectoren naar alle bronnen. Automatisch dagelijks geladen naar Snowflake.
• Transformaties: dbt (data build tool) voor alle transformaties in Snowflake. Alle SQL-modellen in Git, volledig getest en gedocumenteerd.
• Data model: centrale fct_marketing_attributie tabel die elke conversie koppelt aan touchpoints via een multi-touch attributiemodel.
• Rapportage: Looker Studio dashboards met realtime connectie naar Snowflake-views.

dbt model voorbeeld

-- models/marts/marketing/fct_campagne_prestaties.sql
with
campagnes as (
    select * from {{ ref('stg_google_ads__campagnes') }}
    union all
    select * from {{ ref('stg_meta_ads__campagnes') }}
),
kosten as (
    select
        campagne_id,
        sum(kosten) as totale_kosten,
        sum(klikken) as totale_klikken,
        sum(vertoningen) as totale_vertoningen
    from {{ ref('int_advertentiekosten') }}
    group by 1
),
conversies as (
    select
        campagne_id,
        count(*) as aantal_conversies,
        sum(bestelwaarde) as totale_omzet
    from {{ ref('int_conversies') }}
    group by 1
)
select
    c.campagne_id,
    c.campagne_naam,
    c.kanaal,
    k.totale_kosten,
    cv.aantal_conversies,
    cv.totale_omzet,
    safe_divide(k.totale_kosten, cv.aantal_conversies) as kosten_per_conversie,
    safe_divide(cv.totale_omzet, k.totale_kosten) as roas
from campagnes c
left join kosten k using (campagne_id)
left join conversies cv using (campagne_id)

Projecten voor je portfolio

Als je data engineering wil leren of je portfolio wil opbouwen, zijn dit geschikte projecten om zelf te bouwen:

• Public API ingestie: haal dagelijks data op van een publieke API (bijv. OpenWeatherMap, de Buienradar API, of de NS API) en sla dit op in Delta Lake op Databricks Community Edition. Bouw een eenvoudig dashboard in Databricks SQL.
• Kaggle dataset pipeline: kies een grote Kaggle-dataset (bijv. NYC taxi trips of e-commerce orders), bouw een volledig Bronze/Silver/Gold pipeline in PySpark en maak een sterschema in de Gold-laag.
• Streaming simulatie: genereer synthetische streaming data (bijv. gesimuleerde webshop-orders) met een Python-script, verwerk via Spark Structured Streaming en toon live statistieken.
• dbt project: neem een publieke dataset in BigQuery (via de gratis BigQuery sandbox) en bouw een volledig dbt-project met staging-modellen, intermediate-modellen, marts en tests.

Veelgemaakte fouten in data engineering projecten

1. Beginnen met tools, niet met requirements: "we bouwen een Kafka-pipeline" voor je überhaupt weet of streaming nodig is. Start altijd met de businessvraag.
2. Geen data quality checks: een pipeline die corrupt data doorstuurt naar downstream systemen is erger dan geen pipeline. Bouw validatie in vanaf dag één.
3. Over-engineering van het begin: een MKB-bedrijf met 10 GB data per maand heeft geen Spark-cluster nodig. Kies de eenvoudigste tool die het werk doet.
4. Ongedocumenteerde bronnen: wat betekent de kolom "status_cd" in het bronsysteem? Als je dit niet weet voor je begint, weet je het ook niet als je klaar bent — en dan kloppen je rapporten niet.
5. Geen monitoring: een pipeline die stil faalt is slechter dan een pipeline die luid faalt. Implementeer altijd alerting op pipeline-fouten.

Conclusie

Data engineering projecten variëren enorm in scope en complexiteit, maar de fundamentele aanpak is steeds hetzelfde: begrijp de databronnen en het businessdoel, ontwerp een robuuste architectuur, bouw iteratief en valideer continu. De meest succesvolle projecten zijn niet de technisch meest geavanceerde — het zijn de projecten waarbij de engineers het businessprobleem het best hebben begrepen.

Of je nu werkt aan een kleine retail-analytics oplossing of een enterprise-grade streaming platform: de principes van goede data engineering — kwaliteit, traceerbaarheid, betrouwbaarheid en onderhoudbaarheid — zijn altijd hetzelfde. Begin met het simpelste dat werkt en bouw van daaruit verder.