Data Panda haalt DAG-runs, task instances, SLA-misses, de connectie-inventaris en operator-logs uit Airflow naar je warehouse, naast de data die die pipelines laden. Vanop één plek voeden we dashboards, automatisaties, AI-flows en interne apps die eindelijk antwoorden op de vraag welke DAGs je team echt nodig heeft.
Apache Airflow is het open-source platform waarop data-teams hun pipelines plannen, draaien en opvolgen. Engineers schrijven elke pipeline als een Python-DAG (een graaf van taken met dependencies, retries en timing-regels), Airflow plant ze, draait ze, en houdt een record bij van elke run, elke taak en elke retry. De community onderhoudt een lange lijst providers voor de warehouses, SaaS-systemen en cloud-services die die taken aanraken, zodat dezelfde scheduler ELT naar Snowflake doet, een dbt-run start en bij een fout Slack pingt.
Wat teams op Airflow bouwen, gaat van nachtelijke ELT naar het data-warehouse over ML-trainingjobs, data-kwaliteitschecks en rapportgeneratie tot klantgerichte exports. Met de run-historiek van Airflow naast je warehouse-data wordt de vraag welke DAG fragiel is, welk team eigenaar is en wat elke run je kost een dashboard, in plaats van een blik in de web-UI.
DAG-runs, task instances en SLA-misses landen in het warehouse, naast de data die de pipelines effectief laden.
Task-failures en SLA-misses gaan naar het team dat de DAG bezit, niet naar een generieke data-eng-inbox.
AI-functies draaien op warehouse-historiek van dag_run en task_instance, niet op de live web-UI.
Interne apps koppelen elke DAG aan een team, een SLA en een downstream verbruiker.
Een lijst van concrete rapporten, automatisaties en AI-toepassingen die we op Apache Airflow-data hebben gebouwd. Kies er een die bij je situatie past.
Welke van onze Airflow-DAGs ging dit kwartaal meer dan twee keer kapot, en wie is eigenaar?
De tabellen dag_run en task_instance hebben het antwoord, maar niemand op het team heeft tijd om de metastore zelf te bevragen. Trek ze naar het warehouse, koppel op DAG-tag en de team-eigenaarschap-map die je in je CRM of HR-tool bijhoudt, en de volgende kwartaalreview opent met een pagina lijst. De meeste BE/NL-teams zien dat tien DAGs voor de helft van de fouten staan, en dat twee ervan niet eens door het team in de wiki worden gedraaid.
Waarom komt ons ochtendrapport te laat terwijl Airflow zegt dat elke DAG geslaagd is?
Bijna altijd omdat de SLA op de verkeerde taak in een lange DAG staat, of omdat een sensor wacht op een upstream die wel slaagde, maar pas na het rapportvenster. Zet de tabel sla_misses in het warehouse en koppel ze aan welk downstream rapport of welke app de data effectief verbruikte. Het gesprek verschuift van Airflow als verdachte naar de echte upstream-eigenaar bij naam.
Moeten we van self-hosted Airflow naar Astro, MWAA of Cloud Composer?
Self-hosted op Kubernetes heeft de laagste sticker-prijs en de hoogste operations-tijd zodra de Airflow-versie meer dan twee minor releases achter upstream loopt. Astronomer Astro neemt de upgrade- en schaling-zorgen weg en wordt geleverd door het bedrijf dat het grootste deel van de upstream-commits levert. MWAA en Cloud Composer passen als je al op AWS of GCP zit en één factuur wil. De warehouse-view die wij bouwen werkt hetzelfde op alle vier de paden, dus de keuze gaat over operations-tijd, niet over je data.
Finance krijgt een kost-per-DAG-run-view die Airflow-worker-tijd en warehouse-credit-kost terugkoppelt naar het team dat de pipeline plande. Cloud-facturen zijn geen enkele lijn op de IT-P&L meer, maar een cijfer dat je toewijst aan een productlijn.
Sales- en CS-leads krijgen een melding wanneer een pipeline die de klant-360-view voedt kapot gaat of een SLA mist, voor ze met oude cijfers in de QBR stappen. De melding noemt het eigenaar-data-team en het downstream rapport, in plaats van een generieke Airflow-link te plakken.
Data- en platform-leads krijgen een DAG-eigenaarschapsbord, een connectie-inventaris met laatst-gebruikt-tijdstippen en een on-call dashboard op de live scheduler. De overdracht als een ingenieur vertrekt is geen wiki-pagina meer die sinds 2023 niet meer is bijgewerkt.
DAG-runs, taak-durations en de Snowflake query-historiek landen in hetzelfde warehouse, zodat je eindelijk ziet of een trage ELT Airflow was die wachtte, of Snowflake die scande. De warehouse-kost-per-DAG-view vervangt een maandelijkse discussie tussen data-team en finance.
Wanneer BigQuery slot-verbruik op een dinsdagochtend piekt, toont de warehouse-view welke DAG welke query draaide, op welke dataset, met hoeveel scan. Slot-kost-toewijzing wordt geen gok meer, maar een kolom op de DAG-eigenaarschapstabel.
Task-failures en SLA-misses gaan naar het juiste Slack-kanaal op basis van DAG-tag, niet naar een generieke data-engineering-firehose. De on-call ingenieur ziet zijn fouten, het analytics-team ziet de zijne, en de verkeerde-team-meldingen vallen weg.
Wanneer dezelfde DAG in een kwartaal drie keer faalt op een klantgericht data-product, opent of updatet de warehouse-view een case op de data-product-eigenaar in Salesforce. Het gesprek over die pipeline wordt een opvolgbaar dossier in plaats van een Slack-draad die wegscrolt.
Je houdt de rapporteringstool die je al hebt. Wij koppelen hem aan het warehouse waar je Apache Airflow-data staat.
OAuth-authenticatie. Standaard read-only. Wij tekenen een DPA en je admin houdt de sleutels.
Data stroomt naar je warehouse op het schema dat jij kiest. Bijna real-time of 's nachts, aan jou. Jij bent eigenaar.
We bouwen het eerste dashboard, de eerste workflow of AI-toepassing samen met jou, en geven de sleutels over. Of we blijven erbij voor doorlopende levering.
Wij zetten de basis op. Jouw team bouwt erop verder.
Beste match Teams die al een BI-analist of data engineer in huis hebben en zelf willen bouwen.
Wij bouwen het geheel, van A tot Z.
Beste match Teams zonder BI- of dev-capaciteit in huis. Jij zegt wat je nodig hebt en wij leveren het.
Jij. Ze komt in jouw warehouse terecht, op jouw cloud-account. Wij verkopen ze niet door en aggregeren ze niet. Stop je met ons, dan blijft het warehouse van jou en blijft het draaien.
Bijna real-time voor de meeste operationele systemen. Voor zwaardere bronnen plannen we per uur of per nacht. Je kiest op basis van wat de rapporten nodig hebben.
Nee. Heb je er geen, dan helpen we je er een kiezen en zetten we het op als deel van de eerste levering. Gangbare startpunten zijn Snowflake, Microsoft Fabric of een kleine Postgres-start.
Alle vier. De Airflow-metastore toont dezelfde tabellen dag_run, task_instance, sla_miss, connections en variables, of de scheduler nu op je eigen Kubernetes draait, op Astronomer Astro, op Amazon MWAA of op Google Cloud Composer. De warehouse-view die wij bouwen leest die metastore, dus de observability blijft hetzelfde. De keuze tussen self-hosted en managed gaat over wie het upgrade- en schaling-werk draagt, niet over je data.
Voor de warehouse-view niet: het schema waarop wij lezen is stabiel gebleven over de hele Airflow 2.x-lijn en door naar Airflow 3, dus een instantie met versie-achterstand voedt nog steeds dezelfde dashboards. Voor het team zelf maakt het wel uit: een self-hosted Airflow die meer dan twee minor versies achter upstream loopt, is de meest voorkomende reden waarom BE/NL data-teams naar Astronomer Astro of een managed cloud-variant gaan. De warehouse-view is op beide paden hetzelfde.
Wij trekken de connectie- en variabele-inventaris met de geheime payloads weggelaten. De warehouse-view ziet connectie-identifiers, het connectie-type, de host, het schema en het laatst-gebruikt-tijdstip, maar niet het wachtwoord of token. Dat volstaat om stille of ongebruikte connecties te zien, zonder geheimen uit de metastore of uit je secrets-backend te kopieren.
We bekijken je Apache Airflow-opzet en de systemen eromheen. Samen kiezen we wat we als eerste bouwen.