LinkedIn DAG in der Praxis
Modulare Tasks & Dynamische Generierung
Im ersten Beitrag unserer Airflow Blogpost-Serie haben wir die moderne Marketing-Datenlandschaft betrachtet und erläutert, warum Orchestrierung das Herzstück eines skalierbaren Data Stacks ist. Jetzt wird es praktisch.
In diesem Beitrag zum Thema LinkedIn DAG zeigen wir, wie ein produktionsreifer Airflow-DAG (Directed Acyclic Graph) für die Verarbeitung von LinkedIn-Daten in Snowflake aufgebaut ist. Dabei geht es darum, wie man Tasks so gestaltet, dass sie modular, wiederverwendbar und dynamisch generiert sind.
Warum das DAG-Design entscheidend ist
Airflow ermöglicht es, Workflows als Directed Acyclic Graphs (DAGs) zu definieren. Doch nicht jeder DAG ist gleich aufgebaut:
- Schlecht gestaltete DAGs sind schwer zu warten.
- Zu komplexe Tasks erschweren das Debugging.
- Lineare Pipelines führen zu langen Laufzeiten und frustrierten Stakeholder:innen.
Ein gutes DAG-Design hingegen sorgt dafür, dass Pipelines:
- Skalierbar sind (mehr Endpoints, Kund:innen oder Kampagnen problemlos verarbeiten).
- Wartbar bleiben (einfach zu debuggen und zu erweitern).
- Resilient sind (Fehler abfangen und automatisch neu starten).
Tipp: Tasks klein und zielgerichtet halten
Ein Airflow-Task lässt sich mit einer Person am Fließband vergleichen: Sie sollte eine Aufgabe haben – und diese zuverlässig erledigen.
Im Beispiel unseres LinkedIn-DAGs haben wir die Aufgaben klar getrennt:
- Access Token abrufen: Ein Task, der ausschließlich für die Authentifizierung zuständig ist.
- Daten abrufen: Ein Task pro LinkedIn-Endpoint, der die Ergebnisse in S3 schreibt.
- Daten laden: Eine TaskGroup, die zunächst über einen S3 Sensor prüft, ob die Daten in S3 verfügbar sind, und anschließend per Snowflake Operator die Daten in Snowflake lädt.
Diese Modularität zahlt sich aus, wenn ein Fehler auftritt. Statt den gesamten DAG neu auszuführen oder sich durch einen riesigen „Alles-in-einem“-Task zu arbeiten, kann einfach ein einzelner Schritt erneut gestartet werden.
Dynamische Task-Generierung mit Konfigurationsdateien
Marketing-APIs wie LinkedIn bieten oft mehrere Endpoints (z. B. Ads, Campaigns, Creatives, Spend usw.). Würde man jeden einzelnen manuell im DAG hinterlegen, entstünde schnell redundanter und schwer wartbarer Code.
Eine effizientere Lösung: Die Endpoints werden in einer YAML-Konfigurationsdatei definiert, und Airflow generiert automatisch die entsprechenden Tasks.
Die Vorteile davon sind:
- DRY-Prinzip: Kein wiederholtes Kopieren von Python-Operatoren für jeden Endpoint.
- Wiederverwendbarkeit: Neue Endpoints lassen sich durch ein einfaches Update der Konfigurationsdatei hinzufügen, ohne den DAG-Code anzupassen.
- Flexibilität: Ein einzelner Endpoint kann separat erneut ausgeführt werden, ohne die restlichen Tasks zu beeinflussen.
Dieses Vorgehen sorgt für Skalierbarkeit – insbesondere in einer Welt, in der sich Marketingplattformen und APIs ständig weiterentwickeln.
Wie es weitergeht
Mit modularen und dynamisch generierten Tasks ist die Grundlage für eine skalierbare LinkedIn-Ingestions-Pipeline gelegt. Doch für produktionsreife Datenpipelines braucht es mehr als sauberes Design – sie müssen auch robust sein.
Im nächsten Beitrag geht es darum, wie sich DAGs durch Logging, Alerting und Fehlerbehandlung so absichern lassen, dass Probleme früh erkannt werden und Marketing- und Sales-Teams sich nicht mehr wundern müssen, warum Dashboards verspätet sind.