In einer Welt, in der immer mehr Organisationen data driven sind, das Datenvolumen intensiv wächst und analytische Plattformen in die Cloud verlagert und immer komplexer zu deployen werden, wollen data engineers dennoch die bestmöglichen Antworten auf geschäftliche Fragen liefern.
Apache Airflow ist ein bekanntes Tool zum Erstellen, Planen und Überwachen von data workflows. In diesem Artikel beschreibe ich eine Verbesserung, die wir in unserem Projekt eingeführt haben, um schneller bessere DAGs in besserer Qualität zu liefern.
Warum brauchen wir eine lokale Umgebung?
Als Entwickler und data engineers wollen wir ein hochwertiges Produkt liefern, das bereit für den Produktionseinsatz ist – ohne Bugs und Performance-Probleme. Um dieses Ziel zu erreichen, nutzen wir lokale Umgebungen, um unseren Code zu entwickeln, zu testen und zu optimieren.
Lokale Umgebung für Apache Airflow
Produktionsumgebungen sind manchmal sehr komplex, z. B. nutzen sie Kubernetes clusters und Verbindungen zu cloud services, und das Deployment dauert lange. Wie kann man eine sinnvolle Vereinfachung einführen und den Code testbar machen? Schauen wir uns das am Beispiel von Apache Airflow an.
Im vorherigen Artikel haben wir über use cases und den allgemeinen Zweck von Apache Airflow geschrieben.
Wenn du neu in diesem Thema bist, empfehle ich dir einen Blick auf https://dsstream.com/when-should-you-consider-using-apache-airflow-use-cases/
Ich gehe davon aus, dass du mit Airflow vertraut bist, es regelmäßig nutzt und dich fragst, wie man DAGs besser schreiben und testen kann. Du bist nicht allein – bei uns kommt dieses Thema auch regelmäßig in den retro meetings auf 😊
Unsere Produktions- und Preprod-Umgebung läuft in der Cloud auf Kubernetes Engine, die Synchronisierung der DAGs dauerte jedes Mal 2 bis 5 Minuten, was für effiziente Entwicklung viel zu lange ist.
Um schneller hochwertige pipelines zu liefern, haben wir uns entschieden, lokale Airflow-Umgebungen zu starten. Kubernetes lokal zu nutzen war für uns zu viel Overhead, da wir uns auf die Entwicklung der DAGs und nicht auf die Konfiguration konzentrieren wollten. Wir haben uns für eine einfachere Lösung entschieden und Docker Compose verwendet.
Docker Compose als Lösung
Docker Compose ist ein Tool zum Definieren und Ausführen von Multi-Container-Docker-Anwendungen. Mit Compose kannst du die gewünschte Anzahl an Containern, deren Builds und storage design festlegen und dann mit einem einzigen Befehl alle Container bauen, starten und konfigurieren.
Es ist eine großartige Lösung für Entwicklung und Testing.
Es gibt eine offizielle Docker Compose-Datei, die von der Airflow Community bereitgestellt wird, aber um die Produktionseinstellungen besser zu spiegeln, haben wir sie etwas angepasst. Wir haben Bibliotheken wie black, pylint und pytest hinzugefügt, um den Code zu prüfen, sowie Skripte, die uns beim Rebuild des Images und bei den Cloud-Verbindungseinstellungen helfen.
Vorteile der lokalen Airflow-Umgebung auf Basis von Docker Compose im Vergleich zur Remote-Umgebung
Die wichtigsten Vorteile, die wir bei der Nutzung der lokalen Airflow-Umgebung mit Docker Compose festgestellt haben, sind:
- schnelles DAG-Update – das Verzeichnis mit den DAGs ist als Volume gemountet, das Update der DAGs ist so schnell wie die Werte des Parameters SCHEDULER_DAG_DIR_LIST_INTERVAL, also innerhalb von Sekunden möglich,
- einfacher Log-Zugriff – das Verzeichnis mit den Logs ist ebenfalls als Volume gemountet und ermöglicht es uns, Logdateien schnell zu grep-en, tail-en oder einfach zu lesen,
- einfache Konfigurationsänderung – wir nutzen die Konfiguration in einer .env-Datei, was uns erlaubt, Parameter transparent zu ändern, ohne airflow.cfg zu überschreiben, und uns die Möglichkeit gibt, viele .env-Dateien zu haben und einfach zwischen Setups zu wechseln,
- einfaches Redeploy des Images – wir haben die volle Kontrolle über die Umgebung.
Mehr über das Airflow 2.0 Setup mit DAG Versioning und Serialization findest du hier.
Use Cases für die lokale Airflow-Umgebung auf Basis von Docker Compose
Die lokale Airflow-Umgebung mit Docker Compose war für uns nicht nur bei der Entwicklung von DAGs hilfreich, sondern auch bei:
- Upgrade der Airflow version,
- Hinzufügen von python dependencies,
- Testen neuer Versionen von Bibliotheken,
- Testen neuer Integrationen (wie BigQuery) – wenn wir uns gefragt haben, wo wir anfangen sollen, haben wir das Cloud SDK mit persönlichen credentials genutzt und die Entwicklung schnell und effizient gemacht.
Die lokale Airflow-Umgebung mit Docker-Compose war für uns nicht nur bei der Entwicklung von DAGs hilfreich, sondern war auch eine große Hilfe, wenn wir: - die Airflow-Version aktualisieren, - Python-Abhängigkeiten hinzufügen, - neue Versionen von Bibliotheken testen - neue Integrationen (wie BigQuery) testen wollten, als wir uns fragten, wo wir anfangen sollten, haben wir das Cloud SDK mit persönlichen Anmeldeinformationen verwendet und die Entwicklung schnell und effizient gestaltet.Wenn Sie bei Ihrer Arbeit auf ähnliche Herausforderungen stoßen und Erfahrungen austauschen oder nutzen möchten unsere Unterstützung bitte Kontaktiere uns.
Cloudstack vs openstack was sind sie und wie vergleichen
Serverless computing best practices und tipps
Azure sql authentifizierung mit ad
