Skillbyte Podcast #4: Apache Airflow - Zuverlässige Automatisierung geschäftskritischer Workflows

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Apache Airflow - Zuverlässige Automatisierung von geschäftskritischen Workflows

// Inhalt //

1. Was ist Apache Airflow?
2. Wer hat Airflow entwickelt?
3. Welche Unternehmen setzen Airflow ein?
4. Wie funktioniert Airflow im Detail?
5. Welche Erfahrungen hat Skillbyte mit Apache Airflow gemacht?

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Herzlich willkommen zum Skillbyte Podcast Nr. 4 Ich freue mich heute ganz besonders auf das spannende Thema PGR Flow Automatisierung von Workflows. Und wenn ihr Leser Fragen habt im Verlaufe des Podcast oder Zuhörer fragen muss ich ja besser sagen, dann könnt ihr die gerne einsenden an Podcast skillbyte je nachdem wo er uns hört auf dieser oder iTunes. Lass uns gerne eine 5 Sterne Bewertung da oder einen Kommentar und sagt uns, was wir besser machen können oder auch was euch gefällt. Das motiviert uns ganz toll und so können wir unseren Podcast noch besser auf euch zuschneiden.

Und heute freue ich mich ganz besonders, denn ich habe den Oliver dabei.

Hallo Maurice, das ist in der Tat das erste Mal, dass ich hier beim Skillbyte Podcast mitwirkte und ich freue mich, was über Flow, Empathie, Flow erzählen zu können und mit dir darüber reden zu können. Denn das ist eine Technologie, die ich in aktuellen Projekten für Skillbyte bei den Kunden sehr viel einsetze und darüber viel entwickelt habe in letzter Zeit.

Ja, ich freue mich auch mit dir darüber jetzt zu sprechen in den nächsten 30 45 Minuten. Du hast es eingangs schon erwähnt. Du hast ja jetzt in den letzten Monaten dich sehr intensiv mit Flow beschäftigt. Vielleicht möchte zu unseren Zuhörern kurz sagen, um was es sich dabei handelt. Was genau ist der PGR Flow?

Patrick R+V ist ein skillbyte Tool, eine Plattform fürs Styling von Jobs allgemein. Wir setzen zurzeit vor allem im Haluk das Deck ein. Prinzipiell ist es aber möglich, damit jede Art von von Prozess in irgendeiner Form zu zu automatisieren, sei das jetzt in der Cloud oder auch nur System eigene Prozesse, als wenn man damit quasi das gute, altbekannte Cron ablösen wollte. Es ist aber viel, viel mächtiger als das, was man so zum Beispiel von Chrome als Styling Tool für Unix System Prozesse kennt.

Das ist komplett in Python geschrieben. Das macht es gerade auch für Einsteiger, die in diese in diese Bereich wechseln, sehr angenehm. Man kann sehr schnell darin entwickeln. Es hat eine sehr anschaulich und intuitiv zugängliche Weboberfläche, um sich die Ergebnisse und das das Ganze, die ganze Orchestrierung, die man damit machen will, anzuschauen und ist auch schnell aufgesetzt, ihn in seiner Cluster oder oder Umgebung, wo man es auch immer betreiben möchte.

Genau das ist mir auch aufgefallen, als ich dir über die Schulter geschaut habe, oder ich benutze eher Flow ja auch selber mehr so aus Anwendungs Perspektive, dass man einerseits natürlich die Jobs starten kann, auf der anderen Seite hat man eine ganz gute Übersicht welche Jobs laufen gerade? Welche sind vielleicht nicht erfolgreich durchgelaufen, welche sind erfolgreich durchgelaufen und man so eine Art Stundenplan hat, woran man dann sehen kann, was funktioniert hat und was nicht. Und das auf eine sehr übersichtliche Art und Weise.

Gestartet wurde das Projekt ja vor einigen Jahren von einem Entwickler, glaube ich von Airbnb. Deshalb heißt es glaube ich auch eher Flow oder das er hat es da rein geschafft in die namens Bezeichnung.

Ja genau das ist auch mein Kenntnisstand. Es ist soweit ich weiß, von vornherein als Open-Source-Projekt angelegt worden und wird noch immer bei Airbnb und auch diversen anderen Enterprise Level Unternehmungen im Politikbetrieb eingesetzt. Vor allem eben im Big Data Umfeld zur Styling und generell zur Orchestrierung von ihm. Im deutschen Umfeld würde man sagen Ettl Prozessen, also extrahieren, transformieren, laden oder transform load. Also wenn man generell Datenmengen in irgendeiner Form von A nach B transportieren und damit Informationen auf dem Weg noch machen will.

Dafür eignen sich ganz hervorragend.

Also eigentlich ein Werkzeug, um das Data Warehouse bei Patria Du bist ja auch ein Data Warehouse zu bestücken. Verschiedenen oder mit Daten aus verschiedensten Quellen.

Absolut genau so. Ob man jetzt, dass das System hat Hbf hat oder aber wirklich als reines Teilsystemen ist, dass man unabhängig vom von der Benutzung oder ob man so etwas wie Empathie benutzen will oder ob man was ganz anderes machen will und die ganzen Sachen alle in der Cloud hat. Ob das jetzt bei Apps ist oder bei Google. Die Schnittstellen dazu werden zum Beispiel alle schon von den von der Entwickler Community und dem den Entwicklern bereitgestellt. Also man ist mit Erfrorene extrem flexibel, um Schnittstellen zu anderen Plattformen weit jenseits des Ökosystems zu finden.

Auch relationale Datenbanken, wie man sie seit Jahrzehnten kennt, kann man direkt ansteuern mit Air Flow. Also man kann das wirklich in seinem kompletten Technologies Deck, wie er vielleicht sehr natürlich gewachsen sein kann, in einem Unternehmen direkt einsetzen und damit los arbeiten.

Es ist auch, also ich habe es noch nicht selber gesehen, aber es ist ja wohl auch Cluster. Und kann über mehrere Knoten, also Rechner, Verbünde oder Server skalieren, so dass wenn ein Knoten ausfällt, automatisch ein anderer Rechner, die das der Jobs übernehmen kann.

Ja genau. Der Flow selber besteht aus mehreren verschiedenen Diensten, die prinzipiell alle so aufgesetzt werden können, dass sie hoch verfügbar sind oder zumindest Teile oder Mechanismen sofort greifen können. Das ist sehr praktisch. Das ist auch in dem aktuellen Umfeld, in dem ich es jetzt einsetze und dafür entwickelt habe, der Fall, so dass eigentlich ein Single Point of Fela sein könnte. Ist es aber glücklicherweise nicht. Das Kind, über den du schon erwähnt hast, dass es wirklich das Herzstück von so einem Setup, weil dieser Dienst dafür sorgt, dass eben die verschiedenen Jobs voneinander wissen, miteinander interagieren können und einfach regelmäßig zu den gewünschten Standpunkten laufen können, der überwacht das Ganze.

Das kann man entsprechend hoch verfügbar anlegen. Das ist kein Problem. Er benutzt eine Datenbank im Hintergrund, wo die Informationen über die verschiedenen Jobs und auch der Austausch von Informationen zwischen verschiedenen Jopp Abschnitten, zwischen Tasks, wie es in dem Umfeld heißt, stattfindet und so weiter. Die kann man natürlich auch hoch verfügbar anlegen, so dass im Falle von Ausfällen alles immer noch funktionieren kann. Und der Flow kann auch in einem Cluster Modus selber arbeiten. Also man kann wirklich einen ganzen Cluster von Knoten nehmen, die die Arbeit wirklich ausführen.

Jenseits dieses Hosts oder Dienstes viel mehr. Und das können beliebig viele sein. Das kann der komplette Cluster Umgebung sein, also dass er Flows skalierbar ist und auch Ausfall sicher oder in hoher Verfügbarkeit Umgebungen eingesetzt werden kann. Das sieht man schon an der ich sag jetzt mal Kundenliste. Also wer setzt er Flow ein? Das sind natürlich Airbnb, haben wir eben schon drüber gesprochen. Slack, Spotify läuft also oder Lift, der Konkurrent Strip der Zahl Dienstleister, also vornehmlich große Konzerne, die komplexe, regelmäßig ablaufende Big Data Jobs damit betreiben möchten oder natürlich funktionsfähiger betreiben möchten, da sie ja zu ihrem Kerngeschäft beitragen.

Also ich könnte mir vorstellen, dass die Auswertung, wo welche Route gefahren wird, bei Lift natürlich auch sofort ins System zurück fließt, um dann eben dynamisch die Fahrpreise anzupassen oder dabei hoch Last Szenarien z.B. wenn ein Konzert endet und alle nach Hause fahren möchten, dann eben entsprechend Knoten zugeschaltet werden können, um diese Landspitze abzufangen.

Ja, zum Beispiel. Wir haben das jetzt in den aktuellen Prozessen im Einsatz, um zum Beispiel Data Warehouse zu befüllen mit Daten, die dann in Business Intelligence Prozessen genutzt werden, wo einfach sehr kontinuierlich im 5 Minuten oder ein Stunden Rhythmus Rohdaten eintreffen auf bestimmten sag mal Randt Knoten des Clusters, die von von außen zugänglich sind und dann müssen die Daten auch eingesammelt werden. Die müssen aufbereitet werden, dann müssen sie ins Warehouse und in die entsprechenden Kataloge eingetragen werden. Und man möchte natürlich auch darüber informiert sein, wie gerade der Stand der Dinge ist.

Das heißt, man kann auch damit direkt schon Prozesse anstoßen in diesem Flow Orchester, die dann die Datenqualität automatisch überwachen. Also all solche Sachen. Also das ist extrem wichtig und vielseitig. Und dadurch, dass es Schnittstellen zu allen gängigen Datenhaltung Umgebungen besitzt, kann es auch in bestehende Systeme super integriert werden. Damit haben wir sehr gute Erfahrungen gemacht. Also es ist kein man muss, wenn man es einsetzen will, keine komplett neue Infrastruktur und keinen komplett neuen Technologie Stack anschaffen, sondern man kann es auch hervorragend in bestehende Systeme integrieren.

Was sicherlich auch einer der großen Vorteile ist.

Jetzt vielleicht die Integration in bestehende Systeme. Da würde ich gerne näher darauf eingehen. Also wenn wir uns jetzt einfach mal vorstellen, dass unsere Zuhörer, die haben schon Jobs oder die haben verschiedene Systeme, die Jobs durchführen, auch automatisiert durchführen. Und in diese Umgebung kommt jetzt eine Air Flow Instanz hinzu und ich möchte jetzt verschiedene Jobs, ich sag mal umziehen auf die Flow Technologie. Dann würde ich ja eine Installation durchführen auf einem oder auf zwei Knoten, erst mal testweise um mich mit der Technologie vertraut zu machen und dann um.

Also ich sage mal einen Eintrag in einer Tabelle startet hier einen Job und einen Eintrag in der er Flow Tabelle. Den würde ich dann über einen sogenannten DAC anlegen, also direkt. Gerichteten anzüglichen Graphen ist er quasi so eine Art Datei, die beschreibt, wie der Job abzulaufen hat Wie können sich unsere Zuhörer das vorstellen? Was gehört in diese Datei hinein?

Du hast es gerade schon gesagt der Name für diese, ich sag mal, baut für diese Module, die dann quasi einen kompletten Job darstellen, eben Duck oder Geek. Und es ist, wenn man sich ein bisschen mal mit sowas beschäftigt hat, eben eingerichteter a zyklischer Grab. Das heißt ein Ablauf, ein Ablauf Diagramm, wenn man so will, was zum Beispiel keine Schleifen enthält, damit das sich auch nicht fest laufen kann in so einem System. Und dann kann man sich wirklich einen von links nach rechts in der Zeit fortentwickeln, den Programmablauf in wirklichen Blöcken vorstellen.

Und jeder dieser Blöcke stellt eine sogenannte erprobt Task da, also eine Aufgabe, die vom System einem dieser Flow Worker, was eben in so einer klasse Umgebung dann durchaus mehrere sein können, abgearbeitet wird. Und das kann man dann eben so beliebig fein die Aufgaben aufteilen, wie die Umgebung das nötig macht oder wie das die Aufgabe das nötig macht oder wie man es selber für sinnvoll erachtet. Da gibt es verschiedene Dinge, die man da berücksichtigen kann und sollte.

Das heißt, ich habe quasi eine große Aufgabe. Sagen wir mal eine typische Ettl Strecke wäre Extract. Also lade aus der Produktions Datenbank die Bestellungen des Tages. T wäre dann transform, also wande die irgendwie um oder bilde die Summen nach regionalen Zulassungen könnte ich ja sagen und lade die in mein Data Warehouse, lade die nachher Dube. Das wäre ja so ein Beispiel Job und der besteht also aus drei Schritten und ich würde sozusagen in diesen DAC diese drei Schritte nacheinander mit aufnehmen.

Na ja, und der erste Prozess, also diese Extraktion aus einem bestehenden Datenbanksystem. Da würde man wahrscheinlich dann eine Teilaufgabe definieren oder einen sogenannten Operator, der dann der nennt sich Scope oder der eine Technologie anspricht, die Scope heißt und würde dann aus der ich sage mal Produktions Datenbank in der Nacht zur Last Abendzeit die Daten übertragen oder abziehen, erst abziehen und herunterladen, damit diese dann transformiert werden können. Die Transformation wäre ein weiterer Operator. Also wenn man das dann HF machen würde, wäre das der Hive Operator und dann die Entladung.

Also dass man die so transformierten Daten an ihren Bestimmungsort lädt, könnte man dann auch mit Hive machen beispielsweise. Und dann hätte ich so einen einfachen dreistufigen DAC. Richtig.

Genau das wäre ein klassisches Beispiel dafür. Und man kann jetzt in diesem Scope Operator zum Beispiel wenn man zum Beispiel nicht auf einer klassischen Datenbank lesen würde, wäre der Scope Operator nicht das richtige Werkzeug, um die Daten einzuladen. Wenn man die Daten zum Beispiel, sagen wir mal von dem FTP-Server laden will, weil die an meiner Quelle zum Beispiel als CSV-Datei oder als Paar Brawl einfach nur liegen und ich kann die abholen, dann bietet er dir die Möglichkeit. Du hast eben diesen Begriff Operator verwendet, der wird, der ist eins der eins sechs eins der Schlüssel Bausteine in dem ganzen Szenario.

Es gibt aber neben den Operatoren auch noch sogenannte Hubs oder Haken, die von Air Flow bereitgestellte Schnittstellen zu externen Systemen sind. Und dann könnte man zum Beispiel hingehen und dadurch das erfuhr in Python geschrieben. Das hat man natürlich auch die ganze Vererbung Mechanik von objektorientierten Programmierung. Das heißt, man könnte hingehen und einen eigenen Operator schreiben, anstatt einen fertigen Scope Operator, den er vor allem zur Verfügung stellt und mit einem Hook, zum Beispiel dem FTP Hook zu seinem entfernten FTP-Server connecten oder FTP-Server die Daten von dort runterladen vermittels dieses Hooks, der das komplette Verbindungs Management für einen übernimmt.

Die Krisenstabs werden von Erfror verschlüsselt abgelegt. Das ist auch alles sehr durchdacht gemacht, muss ich sagen. Und dann könnte man damit seine Daten einladen und man könnte zum Beispiel anstelle des Operators auch die Daten in einem Microsoft Server ablegen, der Main Data Warehouse darstellt. Also man kann natürlich viel im Stack machen, aber man ist bei weitem nicht darauf limitiert.

Stimmt, wir benutzen ihn hauptsächlich oder bei unseren Kunden, hauptsächlich im Umfeld oder benutzen Dub Umfeld. Da ist man bin ich gedanklich relativ nahe immer an dieser Architektur. Aber du hast natürlich recht, es gibt ja Operators, also die, die mir jetzt spontan einfallen oder die wir einsetzen sind natürlich verhilft Jobs fürs. Für ganz ordinäre Skripte, die dann entweder per WGT über irgendwas runterladen oder sonstige Verzeichnisse erstellen oder so. Dann gibt es noch die Scope Operatoren, da haben wir schon angesprochen, die laden Daten aus SQL Datenbanken irgendwo hin und in einem Beispiel benutzen wir halt auch Rest Jobs, also wo man Überrest, Endpunkte oder APIs gewisse Dienste anstößt oder eben auch Status Informationen kontrolliert, um zu gucken, ob angestoßene Jobs ordnungsgemäß durchlaufen.

Dann hat man diese verschachtelten, ja diesen Mix aus Operatoren, die tun etwas und Sensoren. Das sind natürlich die anderen Komponenten, die zum Beispiel Status Informationen abfragen. Man könnte kann sich das so vorstellen Ein Operator sagt führe eine Aktion durch und ein Sensor prüft dann hinterher. Wurde die Datei angelegt oder liefert die Rest API den Rückgabewert erfolgreich durchgeführt zurück, um eben zu überprüfen, dass ich in einem richtigen Zustand bin, um weitere Tasks anzustoßen. Und am Ende erscheint dann in dieser Überfülle dieser Übersicht hat man so eine schöne Grafik mit den einzelnen Teilaufgaben und sieht, welche Kästchen davon grün sind, welche gelb sind, welche noch oder oder hellgrün, welche noch bearbeitet werden und welche eben auch Fehler geworfen haben.

Wenn dem denn so ist.

Genau. Und ich würde gerne noch das letzte Stichwort Fehler eingehen. Die meisten, die vorher schon mal was in Richtung Skillbyte oder automatisierte Prozesse oder sogar Orchestrierung von von größeren Szenarien auf gemacht haben, werden sich mit dem Problem konfrontiert gesehen haben, was passiert, wenn mal ein Prozess fehlschlägt oder ich korrupte Daten habe und dadurch ja Prozesse ins Stottern geraten und irgendwelche Dinge einfach schief laufen können. Das kann ja immer mal der Fall sein. Der Flow hat den sehr angenehmen Vorteil, dass es sehr gesprächig konfiguriert werden kann.

Man hat viele Möglichkeiten, über das Logging von Air Flow die Prozesse zu studieren, wenn mal wirklich was schiefgegangen ist, was ein sehr großer Vorteil ist. Man muss sich also nicht durch die System Logs seines oder eines Hosts oder oder seiner seiner VM erst mal durchkämpfen, sondern kann da anfangen. Er Flow informiert über E-Mail Notifications, wenn einzelne Tasks oder ganze Decks fehlgeschlagen sind und es wird dieses Lock automatisch mit ausgeliefert. Man kann natürlich das Logging selber noch verstärken, indem man in seinem entwickelten Code noch mehr Logging unterbringt.

Ganz klar. Und du hast eben den Begriff des Sensors erwähnt. Wenn der Sensor mal, also basierend auf der auf dem was der Sensor findet, ist die Datei da ist sie nicht da. War der Prozess erfolgreich, war der Prozess nicht erfolgreich, können auch Verzweigungen in meinem DAC auftreten. Ich kann also auf Grundlage dieses Sensor Ergebnisses entscheiden. Wie verfahre ich weiter? Wenn die Datei da ist, protestiere ich sie. Wenn sie nicht da ist, höre ich auf und fange in der Stunde noch mal an, ob sie wieder da ist oder ich sende eine E-Mail raus, dass die Datei nicht da ist, obwohl sie da sein wollte.

Und so kann man sich dann eben die Ablauf Logik wesentlich komplexer und auch Ausfall sicherer und viel besser überwacht gestalten als das zum Beispiel mit Conn möglich wäre.

Ja, das stimmt, oder? Da müsste man in dem chron. Script selber dafür Sorge tragen, dass eine E-Mail verschickt wird oder dass sich der fehlgeschlagene Job wie auch immer bemerkbar macht.

Ja, oder? Wenn man mit einem Job versucht festzustellen, ob ich sage mal Prozesse aus der Vergangenheit des gleichen Typus noch immer laufen, dann muss ich mir die Unix Prozesse all dies angucken und jede Menge für mich immer so ein bisschen müßige Arbeit mit mit System befehlen halt machen und gucken was läuft gerade auf meinem System. Wie komme ich an die Informationen? Und da bietet einem Flo einfach viel mehr und viel intuitiver Handhabung. Das ist schon ein großer Vorteil, würde ich sagen.

Ja, was ich auch sehr, sehr komfortabel oder als sehr, sehr komfortabel empfinde, ist bei der Entwicklung der DAX. Man hat ja immer mal die kommt an einen Punkt, wo man eine Daten an Datenbank Namen eintragen muss oder einen Pfad oder einen S-H Host, wo dann eben Daten runter werden müssen. Und es gibt da die Konfiguration, Variablen und auch die Connections. Das heißt, man hinterlegt in Flow selber eine Konfiguration Variablen nennen wir sie einfach mal Server Pfad und in dem Deck sagt man dann nur noch dem Operator und mache die Transformation auf dem Server Pfad.

Und je nach Umgebung handelt es sich um die. Entwicklungsumgebung oder die Produktions Umgebung und die beiden Installationen haben dann hinter der gleichnamigen Variable Server Pattern den entsprechend eingetragenen echten Server Namen. Also entweder Entwicklung oder Produktion wird dann automatisch darauf zugegriffen und man kann eben den gleichen DAC in allen Umgebungen verwenden.

Genau das ist sehr sehr praktisch. Diese ganzen Informationen, also die über Verbindungen zu anderen Systemen, was er dann eben die Grundlage von diesen bereits erwähnten Hooks nach außen sind, genau wie die Informationen über die Decks selber und das Gefühligen der Decks. Die legt er also alle in einer eigenen relationalen Datenbank ab. Das kann eine gute Datenbank sein, Lemuria, DB oder auch eine PostgreSQL Datenbank. Das ist alles gut möglich, das kann man sich aussuchen, je nachdem.

Wenn man zum Beispiel schon was in seinem Technologies Deck hat, kann man das dafür einfach benutzen. Da ist er sehr flexibel. Neben diesen Connections gibt es auch noch verschiedene andere Möglichkeiten, diese Datenbank innerhalb von ER sinnvoll zu benutzen, zum Beispiel mit System Variablen. Du hast gerade diesen diesen Part genannt. Da könnte man dann zum Beispiel Sachen noch weitere drin ablegen. Einfach als als String Objekte oder als als Jason Dictionary gibt es verschiedenste Möglichkeiten. Oder aber auch die Kommunikation zwischen den einzelnen Tasks eines Tags kann darüber ablaufen, denn jeder einzelne Tag ist ein Prozess, der auf einem Worker Host ausgeführt wird.

Das heißt, wenn der Prozess abgeschlossen ist, sind die ganzen zur Laufzeit erzeugten Informationen werden alle abgeräumt. Wenn man das in irgendeiner Form weiterreichen will, kann man das natürlich entweder über lokale oder geteilte Systeme machen. Da ist man allerdings natürlich nicht ganz vor Ausfall gefeit, es sei denn, man legt sehr viel Wert drauf. Oder aber wenn die Informationen nicht so viel Speicherplatz brauchen, dann kann man sie einfach als sogenanntes XCOM Objekt über Flow zwischen den Tasks eines Decks oder auch Zwischendeck hin und her schieben, weil das Ganze dann einfach so realisiert wird.

Als Jason Objekt und dann in meiner Flow internen Datenbank abgelegt wird, so dass das auch wenn man die Datenbank außer sicher angelegt hat, gegen Ausfälle gesichert ist. Und es ist von allen erfror Maschinenbaus erreichbar. Das ist unglaublich praktisch. Wenn man im Cluster Modus betreibt, dann wird auch Worker WK1 eine Task ausgeführt und auf Wolke 27 auch. Und die können sich über diese Datenbank gegenseitig Informationen zuspielen.

Ah okay. Also zum Beispiel wenn man ich sage mal dynamische Ziele hat. Oder man muss Dateien irgendwie hochladen und man des Server, wo man es hin laden muss, entscheidet sich erst im Laufe von einem Job. Es kann ja sein, dass je nach Auswertung das Ergebnis von einer vorherigen Stufe, das auf einen unterschiedlichen Server geladen werden muss. Und dann könnte man das per XCOM dann verteilen und sagen Okay, bei dem und dem Ergebnis muss es auf die und jene Server geladen werden.

Genau das ist sehr, sehr praktisch. Man muss halt nur aufpassen, dass die Information, die transportiert werden soll, über diese Diese XCOM Schnittstelle innerhalb der Flows muss eben realisierbar sein. Das ist natürlich für ganz normalen Text oder oder für die meisten simplen Python Objekte ist das überhaupt kein Problem. Man kann sogar ein bisschen weiter gehen und natürlich ganze Python Klassen und daraus erzeugte Objekte dann auch sie realisieren. Das ist sicherlich ganz interessant und man kann zum Beispiel auch Instanzen von diesen Hooks darüber weiterreichen.

Also wir haben das jetzt in einer Form im Einsatz, dass wir eine weitere Datenbank benutzen, um den Status der verarbeiteten Rohdaten zu überwachen. Und dann wird das Verbindungs Objekt, was die Verbindung von Erfüllung zu dieser weiteren Datenbank über den Datei Status. Dieses Verbindungs Objekt wird über XCOM weitergereicht, weil es eben innerhalb von Python in einer Klasse existiert und dann eben dieses Objekt dann realisierbar ist und so weitergereicht werden kann. Also das ist ein sehr ausgefuchste System, das sehr flexibel.

Also man kann sich da jede Menge Fälle überlegen, in denen das sinnvoll ist, oder? Ich glaube bei Flow ist es ganz wichtig, dass man erkennt Okay, man ist nicht, man hat sehr viele Möglichkeiten und man wird nicht festgelegt auf eine vorherige Struktur, sondern man hat überall Erweiterungsbau Möglichkeiten. Entweder du hast es eben schon angesprochen, erweitere ich mit Python direkt eine Schnittstelle von Flow und ich kann auch das Open Source ist den Source Code erweitern, wenn das nötig sein sollte.

Ich weiß wir. Bugfix hängen drin betrieben und gewisse Probleme nachgestellt und das ist schon auf jeden Fall ein Vorteil, dass man direkter reinschauen kann und so viele Möglichkeiten hat.

Auf jeden Fall. Die Community der Entwickler ist auch groß, vielseitig aufgestellt und sehr aktiv. Wenn man bereit ist, die auch kleinere kleinere Patches sich aus dem auf dem GitHub Repository zu ziehen, dann kann man da sehr schnell auch Entwicklungen dran betreiben. Das muss man sich natürlich überlegen, ob das in der Produktions Umgebung unbedingt angebracht ist, aber es findet für rege Entwicklung statt und es gibt auch für den nächsten großen Release sehr flott. 2 ist die Liste der neuen Möglichkeiten und Features die geboten werden auch wirklich sehr sehr groß.

Okay, also was ich auch immer an eher Flow ja fast mit das im Betrieb nicht. Wir haben jetzt sehr viel von der Entwicklung gesprochen. Also wie lege ich diese Tasks Animate er Flow gestartet und überwacht werden kann, sondern im täglichen Betrieb habe ich ja ein Sammelsurium von Tasks. Bei einem unserer Kunden haben wir so 40 bis 60 Tasks würde ich sagen, die jeden Tag ausgeführt werden, teilweise mehrmals am Tag und man hat eben auf einen Blick hat man diese Übersicht über die Entweder schaut man sich einen Job im Detail an und guckt welche einzelnen Ausführung Stufen gibt es da drin und sieht dann eben grüne Kästchen für erfolgreiche Ausführung, Stufen oder rote Kästchen für eben nicht erfolgreiche Ausführung Stufen.

Da hat man dann das es eben auch schon angesprochen, sehr viel Logging Möglichkeit um zu gucken okay, warum hat der Job es nicht geschafft? Warum ist er nicht erfolgreich durchgelaufen? Und was ich dann super praktisch finde ist, dass man diese einzelnen Stages also sagen wir mal, bei so einem 3 stufigen Job ist nur die letzte Stufe nicht erfolgreich durchgelaufen, dann kann man die letzte Stufe noch mal anstoßen. Also oft ist es ja dann so, dann sieht man ah okay, die Daten waren zu der und der Uhrzeit noch nicht da.

Ich lass es jetzt einfach noch mal laufen, dann muss das durchlaufen. Da das dann sehr einfach möglich. Ja, im Grunde mit zwei Klicks, dass man den Job noch mal anstößt oder die fehlgeschlagene Stufe des Jobs noch mal anstößt und da direkt eingreifen kann.

Absolut. Das ist über das Web Interface von jedem, der sich mit dem Thema beschäftigt oder als Data Engineer dafür zuständig ist, wirklich genau. Im Optimalfall muss man das aber ja gar nicht machen. Im Optimalfall hat man sein Deck so entwickelt, dass der bis zu einem gewissen Grad gegen jeden Ausfall ist man natürlich nie gefeit ganz klar, aber doch selbst heilend und sehr Schadens resistent ist. Aber ich habe eben ganz kurz erwähnt, dass man die Möglichkeit hat, auch Verzweigungen in seinen Decks zu machen, die auf Entscheidungen basieren.

Da sind nicht nur Sensoren für zuständig, die das proaktiv machen, sondern auch es gibt die Möglichkeit, auf fehlgeschlagene Tasks zu reagieren. In den Decks, die ich in der Vergangenheit entwickelt habe, ist es dann zum Beispiel so, dass wenn ein, sagen wir mal, eine Task fehlschlägt, die hätte Dateien herunterladen sollen und dann ist die Verbindung abgebrochen. Deswegen ist der Download einer Datei unvollständig. Dann möchte ich diese unvollständige, weil möglicherweise korrupte Datei nicht weiterverarbeiten.

Und ich möchte auch nicht dokumentiert haben, dass die erfolgreich bearbeitet wurde. Dann würde dem Deck jetzt eine Task ausgelöst werden durch das Fehlschlagen dieser ersten Download Task, die den Ursprungszustand meines Systems vor dem Download wiederherstellt, sprich die löscht alle Dateien, die in dem Zyklus heruntergeladen wurden, löscht eventuelle Einträge in einer Status Datenbank, zum Beispiel wo der Download dokumentiert wurde, damit in der nächsten Runde diese fehlgeschlagenen Downloads noch einmal neu angestoßen werden können. Das heißt, ich habe da schon Möglichkeiten, das einfach über den Zug, über die verschiedenen Zyklen meines Decks, das automatisch alles über die Zeit, sich wieder erholen zu lassen und sich selbst zu heilen.

Und letztlich kann man auch jeder Task noch verschieden viele Möglichkeiten einräumen, sich selbst neu zu starten, weil zum Beispiel gerade Daten nicht da waren und sagt Man versucht in einer halben Stunde noch mal, bevor der Deck erst am nächsten Tag zum Beispiel wieder läuft. Also auch da gibt es sehr, sehr viele Möglichkeiten.

Genau das ist ja auch Kerngeschäft von uns als Skillbyte, dass wir unseren Kunden helfen, der Flow Tasks, die wirklich kritische Vorgänge unterstützen, sehr, sehr stabil umsetzen, dass sie sich eben weitestgehend selbst heilen können oder auch dann, wenn sie gescheitert sind. Ich sage mal, sich so weit wieder selbst bereinigen können, dass man einfach sagen kann Ok, warte noch mal fünf Minuten, probiere es noch einmal und probiere es noch einmal und erst dann schicke bitte eine E-Mail raus, weil wenn du es dreimal nicht geschafft hast, dann scheint scheint wohl eine Voraussetzung für diesen Job nicht erfüllt zu sein.

Also. Es ist schon ein oder er Floh erlaubt es sehr, sehr robuste Jobs umzusetzen, die auch grafisch dann sehr gut dargestellt werden können. In dieser Weboberfläche ja, da hast du in der Vergangenheit die geschäfts kritischsten Jobs umgesetzt, die am sichersten laufen mussten.

Ja, im Rahmen dessen, was wir bisher von Skillbyte aus für unsere Kunden an Projekten realisiert haben. Im Zusammenhang mit Air Flow in Big Data Umgebungen würde ich dir da beipflichten. Da ist auch dann eben viel Erfahrung für mich gewonnen worden, weil man natürlich auch erst mal alle Fehlerquellen seines Prozesses kennen muss, um sie abfangen zu können. Man kann sich im Vorfeld alle möglichen Gedanken machen, aber erst wenn man jedes Problem auch mal erlebt hat, weiß man, wie man darauf reagieren muss, um es dann anschließend sinnvoll vorher abzufangen oder automatisch darauf reagieren zu können, wenn es nochmal auftritt.

Ein Punkt, den ich noch kurz anbringen wollte. Das ist mir jetzt auch wieder aufgefallen, weil ich in letzter Zeit wieder viel mit den Leuten zu tun hatte, die solche bestehenden Prozesse, die wir durch Erfahrung Prozesse abgelöst haben, gesprochen haben. Und das waren viele Leute für ein und den gleichen Prozess. Mit Air Flow hat man eigentlich alles an einem Punkt gesammelt. Man kann quasi jeden Prozess, würde ich jetzt soweit sagen, egal wie komplex ist, damit abbilden und auch darüber kontrollieren.

Es ist nicht mehr nötig, Leute zu haben, die in irgendeiner Form bestimmte bestimmte Systeme überwachen, wo einfach mit einem Job irgendwas drauf läuft. Oder man hat die nächste Abteilung, die über CF Pakete betreut, die in einem Server Umfeld dann wieder Dinge verrichten oder Leute die explizit nur für den Zweck zuständig sind. Das kann man wirklich mit weniger Person Power in der Flow einfach alles sammeln. Das spart auch unglaublich Humanressourcen bzw. die können dann eben effizienter eingesetzt werden und sinnvollere Dinge tun als jeden Morgen drauf zu gucken, ob der Server noch läuft oder ob der Job durchgeführt ist.

Aber das was du sagst empfinde ich auch als große Stärke von eher flau. Darüber hinaus ist es auch glaube ich ganz, ganz wichtig, unseren Zuhörern zu sagen Dieser Druck, der ist ja am Ende eine Datei. Das heißt, ich habe den kompletten Ablauf eines Jobs mit allen Fehler, Möglichkeiten oder zeigenden Ausbildungsmöglichkeiten in einer Datei, die liegt in Git Repository, um die es Versionierung war. Die kann von den Entwicklern oder den Verantwortlichen dann eben angesehen angepasst werden.

Man kann neue Notification E-Mail-Adressen zum Beispiel aufnehmen, die sich sofort auswirken und hat quasi auf einen Blick an zentraler Stelle alle Übersicht über die einzelnen Jobs. Und das ist sehr, sehr praktisch für die Entwicklung und auch für den Betrieb hinterher. Was ich wirklich empfehlen würde unseren Zuhörern ist mal sich der Flow Punkt Empathie, Punkt. Org anzuschauen. Da gibt es auch Screenshots, dass man sich mal ein Bild davon machen kann, wie so eine WR, wie die Webanwendung aussieht oder wie auch die einzelnen Jobs dann dargestellt werden.

Eben genau mit den einzelnen Status Information und dieser tabellarischen Liste oder diesem Stundenplan, wo man dann sehen kann, welche Jobs aktiv sind, wann der nächste Run ist, wie der letzte Run gelaufen ist. Und man bekommt sehr viele Informationen über die einzelnen Jobs unter Flow. Punkt Apache, Punkt org was gerade noch mal sehr indirekt eigentlich gesagt hat, schiebt er Flow Helm. Das Ganze ist, das haben wir eingangs gesagt, ja ein reines Open-Source-Projekt mit einer, wie ich schon mehrfach gesagt habe, sehr regen Entwickler Community.

Das führt aber auch dazu, dass man immer mal wieder über Dinge stolpern kann, die vielleicht etwas umständlicher gelöst werden müssen oder in denen man selber noch etwas Zeit und Energie in die Weiterentwicklung von Flow oder einzelnen Spezial Komponenten stecken müsste.

Du meinst Bugs? Der Herrgott wird aber Bugs in der Flow.

Also ich würde nicht so weit gehen. Das ist alles, das alles als Bugs zu bezeichnen. Aber es gibt zum Teil noch etwas Entwicklungspotential an der einen oder anderen Stelle voll die gesamte Benutzer Erfahrung nicht schmälern. Es ist tolle Software, aber es ist am Ende des Tages Open Source Software, die immer noch weiterentwickelt wird und da muss man sich einfach darüber im Klaren sein. Also wenn man es in sehr wichtigen Prozessen in produktive Umgebungen einsetzen möchte, sollte man sich dieser Eigenschaft einfach bewusst sein und so lange getestet.

Haben vorher und ausgiebig getestet, haben also keine Software, die out of the Box. Das alles für mich tut es, wie man das vielleicht bei Enterprise Software eher hätte.

Also es gibt diese Blog blutigen Ecken, sag ich mal, die ganz bei ganz frischen Entwicklungen natürlich. Wobei man sagen muss, der Flow ist seit Januar 2019 von Apache zum Top Level Project ernannt worden und genießt dadurch natürlich schon eine erhöhte Aufmerksamkeit und erhöhte Entwicklungsgeschwindigkeit. Und wenn man Bugs meldet, wird da auch zeitnah zumindest ein Kommentar zu abgegeben. Und ich glaube auch, dass im Kern die Software sehr stabil ist und sie ja auch jetzt. Wir setzen ja schon mehrere Monate oder man kann schon sagen über ein Jahr ein und haben auch mit Flow selbst recht wenig Probleme gehabt, sondern dann sind es eher die Jobs, die darunter liegen, wo man dann nachgucken muss, woran es jetzt klemmt.

Und von daher hätte ich da schon ein hohes Vertrauen. Aber natürlich, bei Open-Source-Software ist man selber verantwortlich. Ganz klar, weil es keinen, wenn man die Software einfach so einsetzt, keinen Hersteller gibt dahinter, den man anrufen kann im Problemfall. Ja, das ist richtig.

Genau das sollte man sich einfach bewusst sein. Und ich glaube, wir haben viele positive Dinge und unsere persönlichen Empfehlungen zu dem Thema abgegeben. Ich würde es immer wieder weiterempfehlen, weil es einfach wirklich gut funktioniert und das tut, was man möchte, wenn man sich intensiv genug damit auseinandergesetzt hat. Wie gesagt, die Entwicklung der Community ist es rege und das ein oder andere Ticket und Request von uns ist dann ja auch schon beantwortet worden.

Ja, super. Also das war noch mal eine ganze Menge Informationen zu Apache Flow, dem super geeigneten Data Warehouse Styling Tool von Airbnb. Und wenn die Zuhörer Fragen haben oder uns Feedback senden wollen, dann können sie das gerne jederzeit tun. An Podcasts Skillbyte, oder? Wenn euch der Podcast gefallen hat, lasst euch ihr lasst uns gerne eine Bewertung da eine möglichst positive Bewertung natürlich. Oder schickt uns eure Fragen ein und sagt, was wir besser machen können. Abonniert uns und schaut auf unser skillbyte Blog auf www.

Skillbyte slash blog vorbei. Wir freuen uns und vielen, vielen Dank an dich, Oli, für deine Expertise zu dem Podcast.

Vielen Dank Maurice. Das hat mir sehr viel Spaß gemacht und ich freue mich von unseren Zuhörern zu hören. Und wir können sicherlich auch bei der einen oder anderen Frage weiterhelfen.

Ja, das können wir. Bis dann.