Datenteams, die mit komplexen Aufnahmeprozessen arbeiten, lieben Apache Airflow.
Sie können Ihre Workflows in Python definieren, das System lässt sich umfangreich erweitern und bietet große Bandbreite an Plug-ins. 86 Prozent der Benutzer geben an, zufrieden zu sein und sie weiterhin anderen Workflow-Engines vorzuziehen. Ebenso viele sagen, dass sie das Produkt weiterempfehlen.
Aber wie jede Software, und insbesondere Open-Source-Software, hat auch Airflow mit einer Reihe von Lücken und Mängeln zu kämpfen, die kompensiert werden müssen. Für Entwickler, die sich gerade erst mit der Software vertraut machen, bedeutet das, dass der Einstieg langsam und der Fortschritt schwierig ist. In diesem Artikel sprechen wir über diese Probleme und einige mögliche Lösungsansätze.
Branchen-Newsletter
Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Ihr Abonnement wird auf Englisch geliefert. In jedem Newsletter finden Sie einen Abmeldelink. Hier können Sie Ihre Abonnements verwalten oder sich abmelden. Weitere Informationen finden Sie in unserer IBM Datenschutzerklärung.
Airflow ist wie ein Arbeitstier mit Scheuklappen. Es korrigiert seinen Kurs nicht, falls etwas mit den Daten schief geht, sondern nur mit der Pipeline. Praktisch jeder Benutzer hat schon einmal eine Version von Airflow erlebt, die ihn über einen erledigten Auftrag informiert, und beim Überprüfen der Daten festgestellt, dass eine Spalte fehlt und alles falsch ist oder tatsächlich gar keine Daten durch die Systeme geleitet wurden.
Dies gilt insbesondere dann, wenn die Datenorganisation ausgereift ist und man von 10 azyklischen Datengrafiken (DAGs) auf Tausende kommt. In dieser Situation verwenden Sie wahrscheinlich diese DAGs, um Daten aus externen Datenquellen und APIs aufzunehmen, was die Kontrolle der Datenqualität in Airflow noch schwieriger macht. Sie können den Quelldatensatz nicht „bereinigen“ oder Ihre Governance-Richtlinien dort implementieren.
Es ist zwar möglich, Slack-Benachrichtigungen zu erstellen, um jeden Durchlauf manuell zu überprüfen, Airflow als nützlichen Teil Ihres Unternehmens zu integrieren und Ihre SLAs zu erfüllen, aber Sie möchten Qualitätsprüfungen automatisieren. Und dafür brauchen Sie nicht nur einen Überblick darüber, ob ein Auftrag ausgeführt wurde, sondern auch, ob er korrekt ausgeführt wurde. Und wenn es nicht richtig lief, warum und woher der Fehler stammt. Andernfalls stoßen Sie jeden Tag aufs Neue auf dieselben Probleme.
Das ist keine einfache Herausforderung, und wenn wir ehrlich sind, ist das der Grund, warum IBM Databand gegründet wurde. Die meisten Tools zur Observability wie Datadog und New Relic wurden nicht für die Analyse von Pipelines entwickelt und können daher nicht feststellen, wo Probleme ihren Ursprung haben, gleichzeitig auftretende Probleme gruppieren, um eine Ursache zu ermitteln, oder Fixes vorschlagen.
Allerdings ist die Notwendigkeit der Observability auch innerhalb der Airflow-Community noch nicht vollständig geklärt. Heute geben nur 32 % an, dass sie eine Bewertung der Datenqualität umsetzen, obwohl die Tatsache, dass die Verfasser der Umfrage danach fragen, ein Hinweis auf eine Verbesserung ist. Diese Frage wurde in den Umfragen von 2019 oder 2020 nicht gestellt.
Wie überwacht man die Datenqualität in Airflow? Im Grunde gelangt man dank Airflow schon halb ans Ziel. Die Wartungszuständigen weisen darauf hin: „Wenn Workflows als Code definiert werden, werden sie besser wartbar, versionierbar, testbar und kollaborativer.“
Airflow bietet diese formale Darstellung von Code. Was Sie benötigen, ist ein Observability-Tool, das speziell für die Überwachung von Datenpipelines entwickelt wurde. Systeme, die zur Produktüberwachung entwickelt wurden, stellen eine Zwischenlösung dar, sind aber in der Regel Teil des Prozesses, da die entsprechenden Lizenzen bereits vorhanden sind.
Wir haben festgestellt, dass Unternehmen auf ihrem Weg zur vollständigen Observability-Reife mehrere Phasen durchlaufen:
Das Erlernen von Airflow erfordert viel Zeit. Zahlreiche Artikel und Threads auf Stack Overflow dokumentieren die Schwierigkeiten von Entwicklern, die an grundlegenden Fragen wie „Warum hat der von mir geplante Job nicht begonnen?“ scheitern. (Eine häufige Antwort: Der Airflow Scheduler beginnt die Planung am Ende des geplanten Zeitraums, nicht am Anfang.) Dazu später mehr.)
Außerdem müssen Sie Celery Executor und entweder RabbitMQ oder Redis erlernen, um kompetent mit Airflow umgehen zu können – daran führt kein Weg vorbei.
Diese Reibung ist so groß, dass einige Unternehmen, wie das CMS-Softwareunternehmen Bluecore, beschlossen, es sei einfacher, im Grunde ihre eigene Airflow-Schnittstelle zu programmieren. Auf diese Weise musste nicht jeder neu eingestellte oder zugewiesene Entwickler alle neuen Operatoren lernen, sondern konnte sich auf die Kubernetes-Operatoren verlassen, mit denen er bereits vertraut war.
Diese Lernhürden sind ein so wiederkehrendes Problem für die Community, dass „Onboarding-Probleme“ eine eigene Frage in der Airflow-Community-Umfrage 2021 (siehe unten) bekommen.
Zu den größten Beschwerden der Benutzer zählten „ein Mangel an Best Practices für die Entwicklung von DAGs“ und „keine einfache Möglichkeit zum Starten“. Dieses letzte Problem wurde teilweise in der Airflow Version 2.0 behoben (die nach der Umfrage veröffentlicht wurde), aber diese Version läuft auf einer SQLite-Datenbank, in der keine Parallelisierung möglich ist und alles sequenziell abläuft.
In der Schnellstartanleitung von Airflow heißt es: „Das ist sehr einschränkend“ und „Sie sollten sehr schnell darüber hinauswachsen.“
Der Hauptanwendungsfall von Airflow ist die Planung von regelmäßigen Batches, nicht von häufigen Durchläufen, wie sogar die eigene Dokumentation bestätigt: „Es wird erwartet, dass Workflows größtenteils statisch sind oder sich langsam ändern.“ Dadurch, dass es für diejenigen, die ad hoc und fortlaufend Daten erfassen oder übertragen müssen, nur wenige Funktionen gibt, ist die Lösung für einige ETL- und Data-Science-Anwendungsfälle nicht ideal.
Aber da wäre noch mehr. Wir haben dies bereits angedeutet, aber der Airflow Scheduler führt schedule_interval-Jobs am Ende des Startintervalls des Airflow Schedulers aus, nicht am Anfang. Das bedeutet, dass Sie mehr den Taschenrechner einsetzen müssen, als Ihnen vielleicht lieb ist, und dass Sie gelegentlich überrascht werden.
Und um diese geplanten Aufträge ordnungsgemäß auszuführen, müssen Sie die Airflow-spezifischen Feinheiten zwischen Operatoren und Aufgaben, die Funktionsweise von DAGs, die Standardargumente, die Airflow-Metadatenbank, den Home Director zum Bereitstellen von DAGs und vieles mehr kennen.
Die Lösung? Sie könnten in Erwägung ziehen, sich den 6 % der Airflow-Benutzer anzuschließen, die ihre eigene grafische Benutzeroberfläche entwickeln und die Operatoren so umbenennen, dass sie für sie mehr Sinn ergeben.
Viele traditionelle Softwareentwicklungs- und DevOps-Praktiken fehlen bei Airflow, und eine davon ist die Möglichkeit, Versionen Ihrer Pipelines zu verwalten. Es gibt keine einfache Möglichkeit, das von Ihnen Erstellte zu dokumentieren und bei Bedarf zu einer früheren Version zurückzukehren. Wenn Sie beispielsweise eine Aufgabe aus Ihrem DAG löschen und neu bereitstellen, verlieren Sie die zugehörigen Metadaten der Task-Instanz.
Das macht Airflow etwas anfällig, und wenn man kein Skript geschrieben hat, um dies selbst zu erfassen, wird die Fehlersuche deutlich schwieriger. Es ist nicht möglich, mögliche Fixes gegen historische Daten zu testen, um sie zu validieren.
Auch hier bietet Airflow die formale Code-Repräsentation. Ihre Herausforderung besteht darin, die fehlende Funktionalität mithilfe anderer Softwareentwicklungs- und DevOps-Tools zu ergänzen.
Hierzu gibt es nicht viel mehr zu sagen. Sofern Sie keine speziellen Docker Compose-Dateien verwenden, die nicht Teil des Haupt-Repositorys sind, ist dies nicht möglich.
Airflow Scheduler funktioniert nicht? Holen Sie sich lieber noch einen Kaffee. Möglicherweise haben Sie ein zeitaufwändiges Debugging vor sich.
Das liegt daran, dass Airflow unserer Meinung nach nicht ausreichend zwischen orchestrierenden und ausführenden Operatoren unterscheidet. Viele Operatoren machen beides. Das mag zwar bei der anfänglichen Codierung der Plattform hilfreich gewesen sein, ist aber ein fataler Fehler, der die Fehlersuche sehr erschwert. Wenn etwas schiefgeht, müssen Ihre Entwickler jedes Mal zuerst ihre DataFlow-Parameter und dann den Operator selbst überprüfen.
Aus diesem Grund können Tools wie Databand eine große Hilfe sein. Databand hilft Ihnen dabei, den Zustand Ihrer Infrastruktur auf jeder Ebene zu verstehen: globaler Airflow, DAG, Task und Benutzeroberfläche. Anstatt Zeit mit dem Erlernen hochspezifischer Funktionen zu verbringen, ermöglicht Databand den Dateningenieuren, sich wirklich auf die Lösung von Problemen für das Unternehmen zu konzentrieren.
Wie jeder Open-Source-Mitwirkende, der sich die Zeit nimmt, neue Änderungen vorzuschlagen, hoffen wir, dass dieser Artikel als die Liebeserklärung verstanden wird, die er ist. Wir von Databand engagieren uns aktiv in der Airflow-Community und freuen uns darauf, dass sie über ihre aktuellen Grenzen hinauswächst und noch mehr ETL- und Data-Science-Anwendungsfälle besser bedienen kann.
Wie wir bereits erwähnt haben, planen 86 % der Benutzer, bei diesem Programm zu bleiben und es anderen Betriebssystemen vorzuziehen. Weitere 86 % würden es uneingeschränkt empfehlen. Wir sind froh, dass wir zu beiden Gruppen gehören - es ist ein großartiges Tool. Und für diejenigen unter Ihnen, die sich gerade erst mit Airflow vertraut machen, ist zu beachten, dass sich der Airflow Scheduler lohnen kann, wenn Sie die oben genannten Probleme im Hinterkopf haben. Erfahren Sie, wie Databand alle Ihre Airflow-Observability-Aktivitäten zusammenführt, um Ihre Apache Airflow-Observability zu vereinfachen und zu zentralisieren. Wenn Sie bereit sind, einen genaueren Blick darauf zu werfen, buchen Sie noch heute eine Demo.
IBM Cloud Infrastructure Center ist eine mit OpenStack kompatible Softwareplattform für die Verwaltung der Infrastruktur von Private Clouds auf IBM zSystems und IBM LinuxONE.
Entdecken Sie Server, Speicher und Software für die Hybrid-Cloud- und KI-Strategie Ihres Unternehmens.
Finden Sie die richtige Cloud-Infrastrukturlösung für Ihre Geschäftsanforderungen und skalieren Sie Ressourcen nach Bedarf.