NiFi Ingestion Blog Serie. TEIL III - Kein Programmieren, einfach ziehen und ablegen, was Sie brauchen, aber wenn es nicht da ist... - benutzerdefinierte Prozessoren, Skripte, externe Dienste

Apache NiFI, eine Big Data Processing Engine mit grafischer WebUI, wurde entwickelt, um Nicht-Programmierern die Möglichkeit zu geben, Daten-Pipelines schnell und kodierungsfrei zu erstellen und sie von den schmutzigen, textbasierten Methoden der Implementierung zu befreien. Leider leben wir in einer Welt der Kompromisse, und diese Funktionen haben ihren Preis. In unserer Blogserie möchten wir Ihnen unsere Erfahrungen und Erkenntnisse aus der Arbeit mit produktiven NiFI-Pipelines vorstellen. Dies wird in den folgenden Artikeln geschehen:

Apache NiFi - warum lieben und hassen Dateningenieure es gleichzeitig?

Teil I - Schnelle Entwicklung, mühsame Pflege

Teil II - Wir haben bereitgestellt, aber zu welchem Preis... - CI/CD des NiFi-Flows

Teil III - Kein Programmieren, einfach ziehen und ablegen, was Sie brauchen, aber wenn es nicht da ist... - benutzerdefinierte Prozessoren, Skripte, externe Dienste

Teil IV - Ein Universum aus Flow-Dateien - NiFi-Architektur

Teil V - Es geht schnell und einfach, was kann da schon schiefgehen - ein Jahr Geschichte eines bestimmten NiFi-Flusses

Ich habe nur eine Regel und die lautet ... - Empfehlungen für die Verwendung von Apache NiFi

In diesem Beitrag befassen wir uns mit der Erstellung von Datenflüssen mit fertigen Prozessoren, den Einschränkungen eines solchen Ansatzes und den von uns angewandten Lösungen. Frühere Beiträge können Sie in unserem Blog lesen .

Was sollten Sie tun, wenn Sie die Grenzen erreichen?

Wir sind echte Fans von Lego, was typisch für viele Ingenieure ist ;-) Lego bietet verschiedene Bausteinserien für unterschiedliche Altersgruppen an und das bringt unterschiedliche Möglichkeiten für das, was man bauen kann. Mit Lego Technic kann man fast alles bauen, aber es braucht einige Zeit, um etwas Komplexes zu bauen, selbst wenn man erwachsen ist. Andererseits kann man mit Lego Duplo schon im Alter von drei Jahren sehr schnell hohe Gebäude bauen. Das einzige Problem ist, wenn man mehr Details hinzufügen möchte, denn die riesigen Duplo-Quader verhindern, dass man individuelle Dinge bauen kann. Zum Glück kann man verschiedene Lego-Serien mischen und zum Beispiel Lego Classic über Duplo verwenden.

Wenn Datenflüsse aus Lego gebaut wurden, dann steht NiFi definitiv für Duplo. Sie können wirklich schnell großartige Dinge bauen und es gibt einige Optionen, um eine benutzerdefinierte Logik zu erstellen, wenn kein fertiger NiFi-Prozessor vorhanden ist.

Es ist schnell, einfach und kostenlos - benutzerdefinierte Groovy-Skripte

Eine wirklich schöne Erweiterung ist der ExecuteGroovyScript-Prozessor, mit dem Sie Skripte in Groovy schreiben können. Er ist gut in NiFi integriert und nur ein paar Zeilen Groovy-Code können wirklich komplexe Probleme lösen. Der Prozessor ermöglicht es Ihnen, einen Skriptkörper in ein Textattribut zu setzen und schon sind Sie fertig. Der einzige Nachteil ist das manuelle Testen innerhalb von NiFi, wenn das Skript geändert wird. Da dieser Ansatz viele Probleme schnell löst, kann er innerhalb von NiFi Flow sehr beliebt werden. Irgendwann stellen Sie fest, dass Flow Dutzende von Inline-Groovy-Skripten enthält, die einige Logikelemente gemeinsam haben.

Dies kann mit einem Groovy-Projekt gelöst werden, das Klassen anstelle von Skripten enthält, die vollständig mit Unit-Tests abgedeckt und in eine jar-Datei verpackt sind. Sobald eine jar-Datei auf allen NiFi-Knoten bereitgestellt ist, wird sie in den Klassenpfad der ExecuteGroovyScript-Prozessoren aufgenommen. Anstatt Inline-Skripte zu schreiben, werden Klassenmethoden aus der jar-Datei verwendet. Der gravierende Nachteil, auf den wir gestoßen sind, war, dass beim Hochladen neuer Jars auf NiFi-Knoten der Klassenpfad für jeden Prozessor manuell neu geladen werden musste, damit die neue Version geladen wurde. Ein weiterer Nachteil war, dass Groovy-Code Flowfile-Attribute lesen kann und beide Systeme eng miteinander gekoppelt sind. Mit anderen Worten: Wenn Sie ein Attribut in NiFi ändern möchten, müssen nicht nur alle NiFi-Prozessoren überprüft werden, sondern Sie müssen auch sicherstellen, dass der Groovy-Code, der in einem anderen Repository gespeichert ist, dadurch nicht beschädigt wird. So wird der monolithischste aller Monolithen gebaut.

Wir müssen tiefer gehen - benutzerdefinierte Prozessoren?

Skripte bieten zwar eine großartige Schnittstelle, um die Funktionen von Nifi zu erweitern, aber sie haben einige Einschränkungen, sowohl in Bezug auf die Benutzerfreundlichkeit als auch auf die Wartung. Um die Anpassungsmöglichkeiten zu maximieren, können wir unsere eigenen Prozessoren erstellen, die im Vergleich zu Skripten einige bemerkenswerte Vorteile bieten. Der erste ist die bessere Abstraktion. Im Falle von Prozessoren kann der Benutzer in die eingebaute Dokumentation schauen, die Hilfemeldungen neben dem Eigenschaftsnamen überprüfen usw. Im Falle von Skripten hingegen ist ein Blick in den Skriptcode fast immer notwendig. Außerdem können wir so viele Ausgabeverbindungen definieren, wie wir wollen, anstatt nur Erfolg und Misserfolg. Da jeder benutzerdefinierte Prozessor nur ein Maven-Projekt ist, kann er außerdem alle herkömmlichen Programmierfunktionen nutzen, die Versionierung mit VCSs wie Git, die Verwendung von Test-Frameworks und die Erstellung von CI/CD-Pipelines. Darüber hinaus bietet NiFi eine Schnittstelle zum Hinzufügen neuer Komponenten in einer Plugin-ähnlichen Weise, so dass Sie nichts neu kompilieren müssen. Seit Version 1.8 gibt es sogar die Möglichkeit, während der Laufzeit dynamisch neue Komponenten hinzuzufügen, und der Wechsel zwischen den Versionen der Komponenten ist auf der Ebene der WebUI möglich. Leider ignoriert NiFi Komponenten, die dieselbe Version haben wie die zuvor geladenen. Es ist also nicht möglich, das jar dynamisch durch eine bereits vorhandene Version zu ersetzen.

All diese Mechanismen sind großartig für Programmierer, aber da NiFi ein Tool ist, das für Menschen entwickelt wurde, die nicht unbedingt gerne programmieren, ist die zusätzliche Komplexität bei der Erstellung von Komponenten ein großer Nachteil im Vergleich zu Skripts. Alles muss in Übereinstimmung mit dem NiFi-Framework erfolgen,

- Allein die Notwendigkeit, Maven oder ein ähnliches System zu verwenden, ist eine große Komplikation, insbesondere wenn eine Aufgabe, die von einer Komponente ausgeführt wird, recht einfach ist. Ein weiterer Nachteil ist, dass Sie über ssh auf den NiFi-Cluster zugreifen oder CI/CD konfigurieren müssen, um einen benutzerdefinierten Prozessor in Nifi einzubauen, was aus Sicherheitsgründen problematisch sein könnte. Genau wie bei den Skripten handelt es sich nur um das Hinzufügen zusätzlicher Teile zu einem monolithischen System.

Auslagerung der Geschäftslogik von NiFi

Niemand plant den Bau von monolithischen Monstern. Es sind nur winzige Bausteine von eng gekoppelten Dingen, die jeden Tag nach und nach hinzugefügt werden. Der beste Weg, um eine enge Kopplung zu vermeiden, ist der Einsatz moderner Entwicklungsmethoden wie.... Microservices. Microservices sorgen für die Kapselung der Geschäftslogik in elegante und winzige Komponenten, die eine klare Definition der API haben, die sie offenlegen. Das ist etwas, das in unseren Projekten wirklich funktioniert hat. Wann immer eine komplexe Logik erforderlich ist, lohnt es sich, anstelle von Dutzenden von untestbaren NiFi-Prozessoren einen REST-Service-Endpunkt zu erstellen. Wir bevorzugen diesen Ansatz vor allem, weil NiFi problemlos HTTP/HTTPS-Anfragen senden und JSON-Antworten verarbeiten kann. Es gibt zahlreiche ausgereifte Frameworks für das Schreiben von Rest-Services in einer Sprache Ihrer Wahl. Das Fehlen von Unit-Tests in NiFi ist eine ernsthafte Einschränkung. Wenn Sie komplexe Dinge bauen und über Unit-Tests verfügen, können Sie Ihren Code leicht refaktorisieren und ihn jeden Tag verbessern. Ohne diese Tests sind Verbesserungen riskant und werden oft vermieden, so dass die Codebasis oder der NiFi-Flow schwer zu pflegen ist. Außerdem können Microservices von anderen Systemen zur Kommunikation mit NiFi verwendet werden.

Der Ansatz mit Microservices funktioniert gut, solange keine großen Datenmengen über das Netzwerk gesendet werden. Mit anderen Worten, er eignet sich für Szenarien, in denen komplexe Logik von großen Datenmengen getrennt gehalten werden kann. In anderen Fällen können Apache Spark-Jobs von NiFi aus angestoßen werden.

Fazit

Was wir geliebt haben? NiFi ist wie Lego Duplo und es ist großartig, dass es mit anderen Legosteinen wie Groovy-Skripten, benutzerdefinierten Prozessoren oder der Auslagerung von Logik auf Microservices erweitert werden kann. Jeder der Ansätze hat seine Vor- und Nachteile. Es ist immer gut, wenn Sie mehrere Optionen haben und diejenige auswählen, die Ihren Bedürfnissen am besten entspricht.

Was wir gehasst haben? Wenn wir mit echter Geschäftslogik arbeiten, bevorzugen wir Apache Spark für größere Datenmengen oder Restdienste mit kleineren Datenmengen. Mit anderen Worten, für benutzerdefinierte Logik vermeiden wir lieber NiFi.