Aan de slag: Airflow¶

Deze pagina behandelt specifiek het product Airflow: een klantgebonden Apache Airflow-instantie voor het plannen van productiejobs. Het is een optionele toevoeging aan het platform — zie Aan de slag: Sovereign Data Platform voor het basis Sovereign Data Platform (notebooks en bevragen), waar Airflow-jobs tegen draaien.

Management summary¶

Het is een eigen, klantgebonden Apache Airflow-instantie, geen gedeelde scheduler, om de pipelines die je organisatie al interactief bouwt in notebooks onbeheerd, op een schema, in productie te draaien.

Zonder Airflow betekent “draai dit elke nacht” dat iemand moet onthouden om het te draaien, of een cronjob die iemand handmatig buiten het platform onderhoudt, zonder gedeeld zicht op of het daadwerkelijk gelukt is. Airflow maakt daar een kleine hoeveelheid gedeclareerde, versiebeheerde code van, met ingebouwde retries, alerting, en een gedeeld overzicht van wat er draaide, wanneer, en of het geslaagd is.

Het aanzetten kost niets extra om in te richten: het is een vlag (enableAirflow: true) op een al geprovisionede klantomgeving, geen aparte inkoop. Zie de prijspagina op de marketingsite voor wat het aan de rekening toevoegt.

Wat is Apache Airflow¶

Apache Airflow is een open-source workflow-orchestrator. Je declareert wat er moet draaien en in welke volgorde als Python-code, en Airflow regelt wanneer: scheduling, het opnieuw proberen van mislukte runs, en één gedeelde plek om te zien wat wel en niet gelukt is, in plaats van die logica verspreid over cronjobs en scripts op iemands laptop.

Kernconcepten¶

DAG (Directed Acyclic Graph): Een Python-bestand dat een set taken declareert en de volgorde waarin ze draaien — zie DAGs ontwikkelen voor hoe je er één schrijft op dit platform. “Acyclic” betekent dat afhankelijkheden altijd voorwaarts wijzen: niets kan afhankelijk zijn van iets dat (direct of indirect) afhankelijk is van zichzelf.
Task / Operator: Een task is één knooppunt in de DAG; een operator is de herbruikbare klasse die bepaalt wat die task daadwerkelijk doet (een notebook draaien, een API aanroepen, wachten op een bestand). Het meeste DAG-code is bestaande operators aan elkaar koppelen, niet nieuwe logica schrijven.
Schedule: Wanneer de runs van een DAG verschuldigd zijn — een cron-expressie, een preset zoals @daily, of (in moderne Airflow) data-aware scheduling die een DAG triggert zodra een andere DAG een dataset produceert waar deze van afhankelijk is.
DAG run / Task instance: Eén concrete uitvoering van een DAG voor een gegeven schema-interval, opgebouwd uit één task instance per task — elk met zijn eigen status (queued, running, success, failed, retrying) en eigen logs.
Scheduler en DAG processor: Achtergrondprocessen die je DAG-bestanden parsen en bepalen wat er vervolgens moet draaien. Je hebt hier niet rechtstreeks mee te maken, maar “mijn DAG verschijnt niet” of “mijn DAG draait niet volgens schema” is bijna altijd terug te voeren op hoe deze twee hem parsen en plannen.
Connection: Een benoemde, centraal opgeslagen set credentials/config die een task gebruikt om iets externs te bereiken (een git-repo, een database, een API) — zie Beheerdershandleiding Airflow: connecties beheren. DAG-code verwijst naar een connection bij naam; het hardcodeert de credential zelf nooit.
XCom: Een klein stukje data dat de ene task aan de andere doorgeeft (een berekende waarde, een bestandspad) — geen mechanisme voor bulk-datatransfer.
Grid view / Graph view: De twee belangrijkste manieren om in de UI naar de runhistorie en structuur van een DAG te kijken: Grid voor status over tijd across runs, Graph voor de afhankelijkheidsstructuur van één run.

Voor de gezaghebbende, versiegebonden referentie hierover, zie de officiële Apache Airflow-documentatie — in het bijzonder de eigen core concepts guide. Deze pagina en DAGs ontwikkelen behandelen alleen wat specifiek is voor het draaien van Airflow op dit platform.

Hoe het past op dit platform¶

Identiteit¶

Standaard authenticeert Airflow tegen hetzelfde klantgebonden Keycloak-realm als de rest van het platform (zie de sectie “Identity” in Aan de slag: Sovereign Data Platform), dus is er geen aparte login. Als je organisatie Airflow-toegang liever vanuit de eigen Azure-tenant beheert, ondersteunt Airflow ook rechtstreekse authenticatie tegen Microsoft Entra ID: zie Onboarding: Microsoft Entra ID voor de volledige onboarding-walkthrough, en Toegang beheren: Airflow-rollen voor dagelijks rolbeheer zodra dat is ingesteld.

Je pipelines draaien¶

Dankzij de custom Airflow providers van het platform (zie Custom Airflow providers) is “draai dit notebook volgens een schema als productie-Spark-job” een kleine hoeveelheid DAG-code in plaats van handmatig geschreven Kubernetes pod-specs. Airflow task pods en de Spark-driver pods die ze aanmaken draaien beide onder een namespace-gebonden spark-driver-identiteit — een job van de ene klant kan nooit bij de namespace van een andere klant komen. Zowel het interactieve (notebook) als het geplande pad delen dezelfde container-image en dezelfde Hive Metastore catalog, dus er is geen verschil tussen hoe een job zich gedraagt in een notebook en hoe hij zich gedraagt in productie.

Volgende stappen¶

Verkrijg toegang — zie Toegang beheren: Airflow-rollen (of Onboarding: Microsoft Entra ID als Entra ID-inlog voor het eerst wordt ingesteld).
Schrijf je eerste DAG — zie DAGs ontwikkelen, dat behandelt hoe DAG-code daadwerkelijk bij deze Airflow-instantie terechtkomt, het notebook-first ontwikkelpad, en platformspecifieke best practices.
Zet externe systemen op die je DAGs nodig hebben — zie Beheerdershandleiding Airflow: connecties beheren.