Introductie in Data Engineering

Introductie

Data engineering is het vakgebied dat zich bezighoudt met het verplaatsen van data van de plek waar het ontstaat naar de plek waar het bruikbaar is — betrouwbaar en op schaal. Dat klinkt eenvoudig. In de praktijk betekent het systemen ontwerpen die data binnenhalen uit tientallen bronnen met verschillende formaten en update-frequenties, die data opslaan zodat je er goedkoop en snel op kunt bevragen, die data omzetten naar iets wat een business user of een machine learning-model daadwerkelijk kan gebruiken, en dat allemaal op een manier die blijft werken als een bronsysteem dinsdagnacht om 3 uur ineens zijn schema wijzigt.

Het vakgebied bestaat omdat niets hiervan vanzelf gaat. Een productiedatabase is geoptimaliseerd voor transacties, niet voor analyse — een zware aggregatiequery daartegen uitvoeren vertraagt de applicatie die hij bedient, en soms blokkeert het rijen die een klant op dat moment probeert te wijzigen. Een dashboard dat rechtstreeks op ruwe applicatietabellen is gebouwd, breekt zodra een product-engineer een kolom hernoemt, omdat niemand buiten het applicatieteam wist dat die kolom stroomafwaarts werd gebruikt. Data engineers bouwen de laag ertussenin: pipelines, warehouses en transformatielogica die operationele chaos omzetten in iets stabiels genoeg om een bedrijf op te bouwen.

Het is de moeite waard om de scope precies af te bakenen, want "data engineering" wordt vaak als verzamelnaam gebruikt voor alles wat met data te maken heeft. Dit hoofdstuk — en dit handbook — richt zich op analytische data engineering: het bouwen van de systemen die rapportage, analytics en machine learning aandrijven. Dat is iets anders dan, hoewel overlappend met, backend engineering (het bouwen van de applicatiedatabases zelf) en MLOps (het deployen en monitoren van modellen in productie). De grenzen zijn vaag bij kleinere bedrijven waar één persoon alle drie doet, maar de vaardigheden en denkmodellen zijn verschillend genoeg om apart te behandelen.

Een Korte Geschiedenis: van ETL Developer naar Data Engineer

Begrijpen waar de rol vandaan komt, verklaart waarom die er nu zo uitziet. Door de jaren 2000 en vroege 2010 heette de equivalente rol meestal "ETL Developer" of "BI Developer", met tools als Informatica, SSIS of Talend. Het patroon was star: Extract uit bronsystemen, Transform de data via een dedicated ETL-server (omdat het doelwarehouse — meestal een on-premises SQL Server- of Oracle-instantie — beperkte en dure compute had), en pas dan Load alleen het uiteindelijke, gemodelleerde resultaat naar het warehouse. Transformatielogica leefde in proprietary tool-configuraties die lastig te versiebeheren waren en nog lastiger te testen.

Twee dingen braken dit model open. Ten eerste ontkoppelden cloud data warehouses (Redshift in 2012, daarna Snowflake, daarna BigQuery) storage van compute en maakten warehouse-compute goedkoop en elastisch — ineens was het logischer om ruwe data eerst te laden en die binnen het warehouse te transformeren met SQL, omdat je niet langer een premium betaalde voor die compute. Dit is de verschuiving van ETL naar ELT, uitgebreid behandeld in ETL vs ELT. Ten tweede explodeerde de diversiteit en het volume aan databronnen — event streams, third-party API's, SaaS-tools, IoT — sneller dan point-and-click ETL-tools redelijkerwijs konden configureren. De rol ging echte software engineering-vaardigheden vereisen: versiebeheer, testen, code review, CI/CD. "Data Engineer" als aparte functietitel brak door tussen ongeveer 2015 en 2018, en begin jaren 2020 was het een van de meest gevraagde rollen in tech geworden — een trend die verder wordt uitgewerkt in Becoming a Data Engineer.

Wat Data Engineers Daadwerkelijk Bouwen

Vacatureteksten zeggen vaak "beheert data-infrastructuur", wat je bijna niets vertelt. Concreet valt het dagelijkse werk van een data engineer meestal in vier categorieën.

Ingestion pipelines. Code (of geconfigureerde tools) die data ophaalt uit bronsystemen: applicatiedatabases via change data capture (CDC), third-party API's (Stripe, Salesforce, HubSpot), event streams via Kafka of Kinesis, bestanden die door externe partners in cloud storage worden gezet. Dit is het deel dat de meeste mensen voor zich zien bij "data pipeline", maar het is vaak het minst intellectueel uitdagende deel van het werk zodra een patroon staat — het moeilijke zit in de lange staart aan edge cases: rate limits, paginering, gedeeltelijke fouten, API-schemawijzigingen.

Storage design. Bepalen hoe data georganiseerd wordt zodra die binnenkomt: partitioneringsstrategie (op datum is het meest gebruikelijk, maar niet altijd juist), bestandsformaten (Parquet, Delta, Iceberg — behandeld in Delta Lake), en tabelstructuren in een warehouse. Slechte storage design toont zich pas maanden later als trage queries en oplopende compute-kosten, wat precies de reden is dat het makkelijk fout gaat en duur is om later te repareren. Een tabel gepartitioneerd op de verkeerde kolom betekent dat elke query de hele dataset scant, ongeacht het toegepaste filter.

Transformatielogica. SQL of code die ruwe, rommelige data omzet naar schone, gemodelleerde tabellen: deduplicatie, type-casting, businesslogica, joins over bronnen heen, slowly changing dimension-verwerking. Hier zit het meeste echte engineering-oordeel, en het wordt uitgebreid behandeld in de hoofdstukken over dbt en Medallion Architecture. Een verrassend groot deel van "data engineering" in een volwassen organisatie is eigenlijk dit — niet bytes verplaatsen, maar businesslogica correct vastleggen en onderhoudbaar houden terwijl het bedrijf verandert.

Orchestratie en betrouwbaarheid. Pipelines plannen, fouten en retries afhandelen, alerteren wanneer data niet op tijd binnenkomt, en zorgen dat een fout in de ene pipeline niet stilletjes alles stroomafwaarts corrumpeert. Dit is de operationele helft van het werk die makkelijk wordt onderschat totdat je om 2 uur 's nachts gepiept wordt omdat een valuta-conversie-API stilletjes nulls begon terug te geven.

De Moderne Data Engineering Stack

De meeste dataplatformen worden tegenwoordig samengesteld uit gespecialiseerde tools in plaats van één monolithisch systeem — een patroon dat de industrie de "modern data stack" noemt. De lagen begrijpen is belangrijker dan specifieke productnamen uit je hoofd leren, want de producten veranderen elke paar jaar en de lagen niet.

Ingestion. Tools als Fivetran, Airbyte, of de copy-activity van Azure Data Factory halen data uit bronnen en laden die, grotendeels ongewijzigd, naar storage. Dit is de "EL" in ELT. Voor use cases met hoog volume en lage latency is deze laag mogelijk in plaats daarvan een Kafka- of Event Hubs-stream. Zie Azure Data Factory.

Storage. Een cloud data warehouse (Snowflake, BigQuery, Redshift) of een lakehouse (Databricks, Microsoft Fabric) bevat de data, waarbij storage-kosten losstaan van compute-kosten — je betaalt voor de schijfruimte die je data inneemt, onafhankelijk van de compute die je opstart om die te bevragen. Deze ene architectuurkeuze maakt de rest van de moderne stack economisch haalbaar. Zie Snowflake, Databricks en Microsoft Fabric.

Transformatie. dbt, Spark, of platte SQL-scripts draaien binnen het warehouse om ruwe data om te vormen naar gemodelleerde, betrouwbare tabellen. Dit is de "T" in ELT — transformatie gebeurt na het laden, met de eigen compute van het warehouse, wat de bepalende verschuiving is ten opzichte van de oudere ETL-aanpak.

Orchestratie. Airflow, Dagster, of de native scheduler van een platform (Fabric pipelines, Databricks Workflows) bepaalt wanneer elke stap draait, in welke volgorde, en wat er gebeurt als iets faalt. Orchestratie maakt van een verzameling scripts een systeem dat je kunt vertrouwen.

Serving. BI-tools (Power BI, Tableau, Looker), reverse ETL-tools die gemodelleerde data terugduwen naar operationele tools (Salesforce, HubSpot), of API's ontsluiten de uiteindelijke, gemodelleerde data naar de mensen en systemen die het daadwerkelijk gebruiken. Deze laag wordt vaak over het hoofd gezien in discussies over data engineering, maar is het hele punt — een perfect gebouwde pipeline die niemand kan bevragen is waardeloos.

Officiële referentiepunten per laag staan onderaan dit hoofdstuk.

Batch versus Streaming

Een fundamentele keuze bij elk pipeline-ontwerp is of data in batches beweegt (verwerk alles wat is opgebouwd sinds de laatste run, volgens een schema) of als een stream (verwerk elk event continu, zodra het binnenkomt). Deze keuze bepaalt bijna alles wat erna komt.

Batch processing is eenvoudiger te bouwen, makkelijker te doorgronden, makkelijker te backfillen en goedkoper om te draaien — je start compute op, verwerkt een blok data, en sluit hem weer af. De meeste analytics use cases (dagelijkse omzetrapportages, wekelijkse cohortanalyse) hebben geen data nodig die verser is dan een paar uur oud, dus batch blijft om goede redenen de standaard. De afweging is latency: als je pipeline elke 6 uur draait, is je data per definitie tot 6 uur oud.

Streaming verwerkt elk record zodra het binnenkomt — met tools als Kafka, Kinesis, Spark Structured Streaming of Flink — en is nodig wanneer het bedrijf echt sub-minuut-versheid nodig heeft: fraudedetectie, real-time personalisatie, operationele dashboards die live systeemgezondheid tonen. Streaming-systemen zijn aanzienlijk moeilijker correct te bouwen: je moet omgaan met events die niet in volgorde binnenkomen, exactly-once-verwerkingsgaranties, en state die blijft bestaan in een systeem dat nooit echt "klaar" is met draaien.

De praktische vuistregel waar de meeste ervaren engineers op uitkomen: kies standaard voor batch, en grijp alleen naar streaming als er een specifieke, gekwantificeerde businessvereiste is voor lage latency die batch écht niet kan halen. Een groot deel van "we hebben real-time nodig" blijkt bij nader inzien te betekenen "we hebben dit binnen het uur nodig", wat een goed afgestelde batch-pipeline die elke 15 minuten draait prima aankan, tegen een fractie van de engineering- en operationele kosten.

Een Dag uit het Leven van een Data Pipeline

Neem een concreet voorbeeld: een e-commercebedrijf wil dagelijks omzet per productcategorie zien, en de bron is een orders-tabel in een productie-Postgres-database.

Stap 1 — Extract & Load. Een nachtelijke job leest nieuwe en gewijzigde rijen uit orders met een updated_at-watermark, niet met een volledige tabelscan, en zet die, grotendeels ongewijzigd, in een raw.orders-tabel in het warehouse. Dit is de bronze-laag: ongewijzigd, maar nu bevraagbaar zonder productie aan te raken. De extractiejob moet het geval afhandelen waarin de vorige run halverwege faalde — opnieuw draaien mag geen dubbele rijen creëren of rijen overslaan, wat precies de reden is dat de watermark-aanpak gecombineerd moet worden met idempotent laden (hieronder meer).

Stap 2 — Clean & Standardize. Een transformatiestap dedupliceert rijen (dezelfde order kan tweemaal voorkomen als er tijdens extractie een netwerk-retry plaatsvond), zet order_date om naar een echt datumtype, verwijdert testorders die door het QA-team zijn geplaatst, en valideert dat verplichte velden zoals customer_id niet null zijn. De output komt in silver.orders terecht — één schone, betrouwbare rij per echte order. Hier vang je ook misvormde records op en zet je die apart, in plaats van ze stilletjes downstream-aggregaties te laten breken.

Stap 3 — Model & Aggregate. Een laatste stap koppelt silver.orders aan silver.products, groepeert op categorie en dag, en schrijft het resultaat naar gold.revenue_by_category. Dit is wat het BI-dashboard daadwerkelijk bevraagt — een kleine, snelle, vooraf geaggregeerde tabel in plaats van een query die miljoenen ruwe orderrijen scant bij elke dashboard-refresh.

Elke stap is een aparte, testbare eenheid. Als stap 2 breekt, is de output van stap 1 er nog steeds en krijgt stap 3 gewoon geen verse data — het produceert niet stilletjes rommel op basis van halfgeschoonde input. Die scheiding, geformaliseerd als bronze/silver/gold, is het onderwerp van het hoofdstuk Medallion Architecture, en het is een van de meest bepalende architectuurbeslissingen in dit hele handbook, omdat het bepaalt hoe gracieus je platform degradeert wanneer er onvermijdelijk iets misgaat.

Codevoorbeelden

Hieronder zie je hoe de extract-, load- en transformstappen hierboven er in de praktijk uitzien — bewust vereenvoudigd voor de leesbaarheid, maar structureel hetzelfde patroon dat op veel grotere schaal in productie draait.

Extractie met een watermark, zodat we alleen ophalen wat er is veranderd sinds de laatste run:

# extract_load.py — haalt nieuwe orders op uit Postgres naar het warehouse
import snowflake.connector
import psycopg2

def get_watermark(sf_conn):
    """Geeft de laatste updated_at terug die we al hebben geladen, of het epoch."""
    cur = sf_conn.cursor()
    cur.execute("SELECT MAX(updated_at) FROM raw.orders")
    result = cur.fetchone()[0]
    return result or "1970-01-01"

def extract_new_orders(pg_conn, since):
    cur = pg_conn.cursor()
    cur.execute(
        "SELECT id, customer_id, order_date, amount, updated_at "
        "FROM orders WHERE updated_at > %s ORDER BY updated_at",
        (since,)
    )
    return cur.fetchall()

def load_to_staging(sf_conn, rows):
    """Laad eerst naar een staging-tabel — schrijf nooit direct naar raw.orders,
    zodat een mislukte load die tabel nooit half-geschreven achterlaat."""
    cur = sf_conn.cursor()
    cur.executemany(
        "INSERT INTO staging.orders (id, customer_id, order_date, amount, updated_at) "
        "VALUES (%s, %s, %s, %s, %s)",
        rows
    )

Idempotent laden met MERGE, zodat het opnieuw draaien van deze job na een gedeeltelijke fout nooit duplicaten creëert:

-- merge_raw.sql — staging naar raw, idempotent by design
MERGE INTO raw.orders AS tgt
USING staging.orders AS src
ON tgt.id = src.id
WHEN MATCHED THEN
  UPDATE SET amount = src.amount, updated_at = src.updated_at
WHEN NOT MATCHED THEN
  INSERT (id, customer_id, order_date, amount, updated_at)
  VALUES (src.id, src.customer_id, src.order_date, src.amount, src.updated_at);

Deduplicatie en opschoning naar de silver-laag, met ROW_NUMBER() om alleen de laatste versie van elke order te bewaren:

-- transform_silver.sql — dedup + opschonen, één rij per echte order
CREATE OR REPLACE TABLE silver.orders AS
SELECT
    order_id,
    customer_id,
    order_date,
    amount,
    updated_at
FROM (
    SELECT
        id AS order_id,
        customer_id,
        CAST(order_date AS DATE) AS order_date,
        amount,
        updated_at,
        ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC) AS rn
    FROM raw.orders
    WHERE amount > 0        -- test-/geannuleerde orders eruit
      AND customer_id IS NOT NULL
)
WHERE rn = 1;

Dat patroon van ROW_NUMBER() OVER (PARTITION BY ...) voor deduplicatie is een van de meest voorkomende dingen die je als data engineer zult schrijven — het krijgt een veel diepere behandeling, inclusief performance-overwegingen en Snowflake's QUALIFY-shortcut, in SQL for Data Engineers.

Een minimale Airflow DAG die de stappen samenbrengt met goede foutafhandeling:

# orders_pipeline_dag.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

default_args = {
    "retries": 2,
    "retry_delay": timedelta(minutes=5),
    "email_on_failure": True,
}

with DAG(
    "orders_pipeline",
    schedule="0 3 * * *",       # dagelijks om 03:00
    start_date=datetime(2026, 1, 1),
    default_args=default_args,
    catchup=False,
) as dag:

    extract = PythonOperator(task_id="extract_load", python_callable=run_extract_load)
    merge = PythonOperator(task_id="merge_raw", python_callable=run_merge)
    clean = PythonOperator(task_id="build_silver", python_callable=run_silver_transform)
    aggregate = PythonOperator(task_id="build_gold", python_callable=run_gold_aggregate)

    extract >> merge >> clean >> aggregate

Let op de retries en retry_delay — tijdelijke fouten (een haperende databaseverbinding, een API-timeout) zijn de norm in productiepipelines, niet de uitzondering. Een pipeline die hard faalt bij de eerste tijdelijke fout piept onnodig iemand op, meerdere keren per week.

Data Engineer versus Data Analist versus Data Scientist versus ML Engineer

Deze rollen worden voortdurend door elkaar gehaald, dus hier is het praktische verschil in termen van waar elke rol daadwerkelijk verantwoordelijk voor is:

Een data analist gaat ervan uit dat de data al schoon en beschikbaar is. Het werk van een data engineer is om die aanname waar te maken — en waar te houden terwijl bronsystemen, businesslogica én datavolume tegelijk veranderen. Een data scientist bouwt voort op beide, en heeft in toenemende mate ook pipeline-vaardigheden nodig, aangezien feature engineering op schaal zelf een data engineering-probleem is — een trend die verder wordt behandeld in AI for Data Engineers. De grens tussen data engineer en ML engineer is behoorlijk vervaagd nu feature stores en real-time inference-pipelines gemeengoed zijn geworden; bij veel organisaties is het inmiddels hetzelfde team.

Performance Tips

• Filter vóór je joint, niet erna. Een WHERE-clausule toepassen na een grote join dwingt het warehouse om de volledige dataset te joinen voordat rijen worden weggegooid. Duw filters zo vroeg mogelijk in de query — de meeste moderne query-optimizers doen dit automatisch, maar niet altijd, zeker niet over CTE's heen.
• Partitioneer op de kolom waar je het meest op filtert. Als 90% van de queries op datum filtert, partitioneer dan op datum. Partitioneren op de verkeerde kolom betekent dat elke query data scant die hij niet nodig heeft, ongeacht de WHERE-clausule.
• Let op de grootte van je warehouse-compute, niet alleen op querycomplexiteit. Een klein warehouse dat een complexe query draait, wacht en staat in de rij; een enorm warehouse dat een triviale query draait, verbrandt credits zonder enig voordeel. De juiste compute-grootte kiezen voor de workload is een grotere kostenhefboom dan bijna elke query-optimalisatie — zie het hoofdstuk Snowflake voor concrete sizing-richtlijnen.
• Incrementeel verslaat volledige refresh op schaal. Een volledige fact table elke nacht herberekenen is prima bij 10 miljoen rijen en rampzalig bij 10 miljard. Incrementele modellen (alleen nieuwe/gewijzigde data verwerken) zijn de meest impactvolle performanceverbetering die beschikbaar is in een volwassen dbt-project.
• Vermijd SELECT * in productiemodellen. Naast leesbaarheid breekt het stilletjes downstream-modellen wanneer een bovenliggende tabel een kolom krijgt of verliest, en het voorkomt dat het warehouse ongebruikte kolommen kan overslaan in kolomgeoriënteerde opslagformaten.

Best Practices

• Maak pipelines idempotent. Dezelfde job tweemaal draaien mag nooit duplicaten of onjuiste data opleveren. De MERGE- en ROW_NUMBER()-patronen hierboven zijn de twee meest gebruikte manieren om dit af te dwingen.
• Gebruik een watermark, geen volledige herlaad, voor incrementele bronnen — een hele tabel dagelijks herladen wordt duur en traag naarmate data groeit, en wordt uiteindelijk fysiek onmogelijk binnen je batch-window.
• Scheid ruwe van gemodelleerde data. Transformeer nooit data op de plek zelf; bewaar altijd een ongewijzigde bronze-kopie zodat je downstream-lagen kunt herbouwen als transformatielogica verandert of er maanden later een bug wordt ontdekt.
• Versiebeheer je transformatielogica. SQL en pipeline-code horen in Git, gereviewd als elke andere code — zie Git & Branching Strategies.
• Alerteer op afwezigheid van data, niet alleen op pipeline-fouten. Een pipeline die "slaagt" maar nul rijen laadt omdat een bovenstroomse API stilletjes zijn responsformaat wijzigde, is een faalmodus die monitoring op alleen jobstatus nooit zal opvangen — zie Monitoring & Observability.
• Documenteer aannames, niet alleen code. "Deze tabel gaat uit van één rij per order" is waardevoller voor de volgende engineer dan een comment die uitlegt wat een JOIN doet.

Veelgemaakte Fouten

• Alles zelf bouwen. Een eigen ingestion-framework schrijven terwijl een managed tool (Fivetran, Airbyte) 90% van de behoefte dekt in een fractie van de tijd. Custom ingestion-code is een onderhoudslast die zichzelf zelden terugverdient, en het is de meest voorkomende vorm van verspilde engineering-inspanning die ik zie bij nieuwe dataeams.
• Geen schema-contracten. Bronschema's als vast beschouwen, waardoor pipelines breken — of erger, stilletjes verkeerd laden — wanneer een bronteam zonder waarschuwing een kolom toevoegt, hernoemt of van type verandert.
• Tests overslaan. Transformatie-SQL uitrollen zonder validatie dat rijaantallen, uniekheid of referentiële integriteit kloppen — zie Data Quality & Testing.
• "Het draaide" verwarren met "het werkte". Een pipeline kan succesvol afronden en toch foute cijfers opleveren. Datavalidatie is een aparte zorg naast orchestratiestatus, en die twee door elkaar halen is precies hoe foute cijfers in een directiedashboard belanden.
• Voortijdig streamen. Een Kafka-gebaseerde streamingpipeline bouwen voor een dashboard dat toch maar één keer per dag wordt ververst. Match de architectuur met de daadwerkelijke latency-eis, niet met wat technisch indrukwekkend is.
• Geen kostenzicht. Pipelines onbeperkt op te grote compute laten draaien omdat niemand naar de warehouse-rekening kijkt totdat finance vraagt waarom de kosten zijn verdrievoudigd.

Interviewvragen

"Loop met me door hoe je een pipeline zou ontwerpen om data van een productiedatabase naar een warehouse te laden." Let op: incrementele extractie met een watermark, scheiding van ruwe/bronze en gemodelleerde/silver data, idempotentie via MERGE of dedup-logica, en hoe ze schemawijzigingen zouden afhandelen zonder downstream-tabellen te breken.

"Wat is het verschil tussen ETL en ELT, en waarom maakt het uit?" Let op: het begrip dat ELT eerst ruwe data laadt en transformeert met de compute van het warehouse, wat verklaart waarom het domineert op moderne cloudplatformen — volledige uitleg in ETL vs ELT.

"Hoe zou je detecteren dat een pipeline onvolledige data heeft geladen, ook al is de job zelf geslaagd?" Let op: controles op afwijkende rijaantallen, freshness-checks, het vergelijken van het daadwerkelijke volume met een verwachte bandbreedte — niet alleen "de logs checken".

"Wat maakt een pipeline idempotent, en waarom maakt dat uit?" Let op: een duidelijk voorbeeld (zoals het MERGE-patroon hierboven) en het begrip dat retries en backfills onvermijdelijk zijn in productie, waardoor niet-idempotente pipelines uiteindelijk data corrumperen.

"Wanneer kies je voor batch processing boven streaming, en andersom?" Let op: afwegingen in kosten en complexiteit, de herkenning dat de meeste als "real-time" omschreven businessvereisten in werkelijkheid minuten latency tolereren, en specifieke streaming use cases (fraudedetectie, live operationele dashboards) waar het echt nodig is.

"Hoe ga je om met een bronsysteem dat zonder waarschuwing zijn schema wijzigt?" Let op: detectie van schema drift, defensief parsen (niet aannemen dat een kolom bestaat), alerteren in plaats van stilletjes falen, en idealiter een data contract of afspraak met het bronteam.

"Wat is in jouw eigen woorden het verschil tussen een data engineer en een data analist?" Let op: een heldere articulatie dat engineers de systemen bouwen en onderhouden die data betrouwbaar en beschikbaar maken, terwijl analisten die data gebruiken om businessvragen te beantwoorden — niet een vaag "engineers schrijven meer code".

Relevante Documentatie

• Snowflake Documentation — officiële referentie voor warehouse-architectuur en SQL.
• Databricks Documentation — lakehouse-architectuur, Delta Lake en Spark.
• dbt Labs Documentation — patronen en best practices voor de transformatielaag.
• Microsoft Fabric Documentation — Microsofts unified analytics-platform.
• Apache Airflow Documentation — orchestratieconcepten en DAG-ontwerp.

Samenvatting

Data engineering is de praktijk van het bouwen van betrouwbare systemen die data verplaatsen en hervormen — geen vage verzamelnaam voor "data-infrastructuur", en anders dan de rol van ETL Developer waaruit het is voortgekomen. De moderne stack scheidt ingestion, storage, transformatie, orchestratie en serving in aparte lagen, doorgaans volgens een ELT-patroon waarbij transformatie plaatsvindt binnen het warehouse ná het laden. Batch blijft de verstandige standaard; streaming is een bewuste keuze voor een specifieke, gekwantificeerde latency-eis, geen standaardarchitectuur. Het bronze/silver/gold-patroon uit de pipeline-walkthrough van dit hoofdstuk — extract met een watermark, idempotent laden, dedupliceren en opschonen, dan modelleren en aggregeren — is het fundament voor bijna alles wat verderop in dit handbook aan bod komt, te beginnen met de SQL-patronen die het mogelijk maken, in het volgende hoofdstuk.