Data-orkestratie

Wat is data-orkestratie?

Data-orkestratie is het plannen, in de juiste volgorde uitvoeren en bewaken van al je datataken samen. Denk aan de pijplijn die je bronsystemen inlaadt, de transformaties die daarop draaien, het notebook dat een berekening doet, de kwaliteitscheck en de refresh van je rapporten. Elk van die taken kan apart bestaan, maar ze horen bij elkaar: de ene mag pas starten als de andere klaar is.

Zonder orkestratie plan je elke taak los in. De load van je warehouse om 5u, de refresh van het rapport om 6u. Dat werkt tot de dag dat de load uitloopt en het rapport ververst met halve data. Niemand krijgt een melding, want technisch is er niets gefaald. De cijfers kloppen alleen niet.

Een orkestrator maakt de afhankelijkheden expliciet. Je zegt niet "draai om 6u" maar "draai zodra de load klaar is". Vergelijk het met een verkeerstoren: die laat een vliegtuig pas vertrekken als de baan vrij is, in plaats van elk toestel op een vast uur te laten opstijgen en te hopen dat het past.

Van losse schedules naar orkestratie

Niet elk dataplatform heeft een orkestrator nodig. Heb je drie taken die niets met elkaar te maken hebben, dan volstaat een gewone planner: een cron job, een geplande refresh in Power BI, een sync die elk uur draait. Daar een orkestrator voor opzetten is werk zonder opbrengst.

De omslag komt zodra taken op elkaar wachten. Herkenbare signalen:

• Het rapport mag pas verversen nadat het warehouse geladen is.

• Eén bron levert te laat en je hele ochtendketen schuift op.

• Je taken lopen over meerdere systemen: een load hier, een transformatie daar, een refresh ergens anders.

• Als er 's nachts iets faalt, zoek je 's ochtends in vijf verschillende logs naar de oorzaak.

Vanaf dat punt verdient een orkestrator zichzelf terug. Elke afhankelijkheid die je vandaag met een tijdstip en wat geluk oplost, wordt een expliciete regel die een machine bewaakt.

De bouwstenen van een orkestrator

De afhankelijkheidsgraaf

Elke orkestrator draait rond hetzelfde model: taken zijn blokjes, en pijlen tussen die blokjes zeggen "start pas als dit klaar is". Technisch heet dat een DAG, een directed acyclic graph. Dat klinkt zwaarder dan het is: gericht betekent dat de pijlen één kant uitgaan, acyclisch dat je nooit in een cirkel kan belanden. Taak A kan niet op taak B wachten terwijl B op A wacht.

In Apache Airflow schrijf je die graaf uit in Python-code. In Fabric Data Pipelines klik je hem samen op een canvas. Het idee is identiek.

Triggers: op schema of op event

Een run start op een schema (elke nacht om 2u, elk uur, elke maandag) of op een event: een bestand dat in je lakehouse toekomt, een andere pipeline die klaar is, een handmatige start. Event-triggers halen de gok uit je planning. Je wacht niet tot een tijdstip waarop het bestand er meestal is, je start wanneer het er effectief is.

Retries en backfills

Veel fouten zijn tijdelijk: een API die even niet antwoordt, een netwerk dat hapert. Een orkestrator probeert een gefaalde taak automatisch opnieuw, met een wachttijd ertussen, zodat je niet voor elke hapering uit bed moet.

Een backfill draait een keten opnieuw voor het verleden. Vind je een fout in een transformatie, dan laat je de orkestrator de voorbije maanden dag per dag opnieuw verwerken in plaats van zelf scripts te knutselen.

Alerting en overzicht

Een orkestrator toont op één plek wat er loopt, wat klaar is en wat faalde, met de logs erbij. Faalt een taak definitief, dan krijg je een melding en houdt de orkestrator de taken tegen die ervan afhangen. Beter een rapport met de cijfers van gisteren dan een rapport met halve cijfers van vandaag.

Tools voor data-orkestratie

Apache Airflow is de open-source referentie. Je definieert je DAG's in Python, Airflow plant ze in, voert ze uit en toont in een web-interface wat er loopt en wat faalde. Het project wordt onderhouden binnen de Apache Software Foundation en je vindt het terug in veel datateams die hun orkestratie als code beheren.

Fabric Data Pipelines is de orkestrator binnen Microsoft Fabric. Je bouwt een pipeline op een canvas met activiteiten: data kopiëren, een notebook draaien, een dataflow starten, condities en loops. Pipelines starten op schema of op events, zoals een bestand dat in OneLake landt, en de monitoring hub toont alle runs op één plek. Wie liever in code werkt, kan binnen Fabric ook Apache Airflow-jobs draaien.

dbt orkestreert één stap bijzonder goed: de transformaties in je warehouse. Uit de verwijzingen tussen je modellen leidt dbt zelf de juiste volgorde af, je hoeft die nergens apart te onderhouden. De run zelf start dbt niet in: die trap je af vanuit een orkestrator of een geplande job.

Data-orkestratie versus workflow engine

De twee lijken op elkaar: allebei voeren ze stappen in volgorde uit, houden ze de status bij en proberen ze opnieuw bij fouten. Het verschil zit in wat er door de stappen stroomt.

Een workflow engine stuurt bedrijfsprocessen aan waar vaak mensen in zitten: een klantdossier dat op goedkeuring wacht, een onboarding die weken kan duren. Zo'n proces leeft per dossier en kan lang stilliggen. Een data-orkestrator stuurt datataken tussen systemen aan: laden, transformeren, verversen. Geen mens in de lus, wel veel volume en een strak nachtvenster.

Concreet: klantonboarding met een goedkeuringsstap hoort in een workflow engine zoals Camunda. De nachtelijke keten van bronsysteem naar warehouse naar rapport hoort in een orkestrator zoals Airflow of een Fabric-pipeline.

Wat maakt orkestratie betrouwbaar?

Idempotente taken. Retries en backfills zijn pas veilig als een taak twee keer draaien hetzelfde resultaat geeft als één keer. Een taak die bij elke run rijen toevoegt, maakt van elke retry dubbele data. Idempotentie is daarom de stille voorwaarde onder heel het retry-verhaal.

Expliciete afhankelijkheden. Alles wat op iets anders wacht, wacht via de graaf en niet via de klok. Elke afhankelijkheid die alleen in het hoofd van een collega bestaat, is een storing die op je wacht.

Eén plek voor falen. Als het rapport leeg is, wil je binnen de minuut zien welke taak faalde en waarom. Moet je daarvoor in vijf tools zoeken, dan zijn het in de praktijk nog altijd verspreide schedules.

Waar moet je op letten bij data-orkestratie

Planning op de klok is een verborgen afhankelijkheid. "Refresh om 6u, want de load is om 5u meestal klaar" is een race condition met een wekker. Negen dagen op tien gaat het goed, tot een trage bron de load laat uitlopen en je rapport halve data toont. Staat de afhankelijkheid in de graaf, dan bestaat dat scenario niet meer.

Afhankelijkheden buiten de orkestrator. Het script op de laptop van een collega, de SaaS-tool die op eigen houtje 's nachts synct: de graaf kleurt groen terwijl de keten stuk is. Breng ook die taken onder in de orkestrator, of laat ze minstens een signaal geven waar de orkestrator op wacht.

Retries op taken die niet tegen herhaling kunnen. Automatisch opnieuw proberen op een taak die mails verstuurt of rijen toevoegt, veroorzaakt dubbele mails en dubbele rijen. Maak de taak eerst idempotent, zet de retries pas daarna aan.

Alert-moeheid. Als elke kleine hapering een melding stuurt, kijkt na twee weken niemand nog. Alerteer op wat actie vraagt en laat de rest in het logboek staan.

FAQ over data-orkestratie

1. Is data-orkestratie hetzelfde als ETL?
Nee. ETL is het werk zelf: data ophalen, transformeren en laden. Orkestratie beslist wanneer dat werk draait, in welke volgorde, en wat er gebeurt als een stap faalt.

2. Wat is het verschil met een gewone planner?
Een planner start taken op een tijdstip. Een orkestrator kent ook de afhankelijkheden tussen taken, probeert opnieuw bij fouten, kan het verleden opnieuw verwerken en toont de hele keten op één plek.

3. Heb ik Airflow nodig voor een klein dataplatform?
Meestal niet. Zit alles binnen Microsoft Fabric, dan kom je ver met Data Pipelines. Airflow loont wanneer je veel taken hebt, veel maatwerk, of orkestratie over meerdere platformen heen.

4. Wat gebeurt er als een taak 's nachts faalt?
De orkestrator probeert opnieuw volgens de ingestelde retries. Blijft de taak falen, dan houdt hij de afhankelijke taken tegen en krijg je een melding. Je rapport toont dan de cijfers van gisteren in plaats van halve cijfers van vandaag.

5. Moet elke taak in de orkestrator zitten?
Elke taak waar iets anders van afhangt wel. Een losstaande export die nergens op wacht en waar niets op wacht, mag gerust een gewone geplande taak blijven.