Apache NiFi, eine Big Data Processing Engine mit grafischer WebUI, wurde entwickelt, um Nicht-Programmierern die Möglichkeit zu geben, Datenpipelines schnell und ohne Programmieraufwand zu erstellen und sie von den schmutzigen, textbasierten Implementierungsmethoden zu befreien. Leider leben wir in einer Welt der Kompromisse, Funktionen haben ihren Preis. In unserer Blogserie möchten wir 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 IV - Ein Universum aus Flow-Dateien - NiFi-Architektur
Ich habe nur eine Regel und die lautet ... - Empfehlungen für die Verwendung von Apache NiFi
Dieser Beitrag stellt unseren Ansatz für CI/CD von NiFi-Flows vor. Frühere Beiträge können Sie in unserem Blog lesen .
NiFi Registry - das Repository für die NiFi-Flows
NiFi ist dafür bekannt, keine Fehler zu verzeihen. Das Fehlen einer eingebauten Funktion zum Rückgängigmachen von Änderungen veranlasste die Entwickler, ein externes Versionierungssystem zu schaffen, das ein Rollback auf die letzte Arbeitsversion ermöglicht. So wurde NiFi Registry geboren. Auf den ersten Blick ist es sehr nützlich, da es eine einfache Versionierung durch jede Prozessgruppe in NiFi ermöglicht. Commits werden direkt vom Web-Canvas der Prozessgruppe aus durchgeführt, was die Nutzung vereinfacht.
Man könnte meinen, dass es sich bei NiFi um eine Art Git handelt, aber NiFi Registry fehlt es an vielen Funktionen eines modernen VCS. Es gibt einige Gründe, warum dies der Fall ist. Erstens ist das Speichern von Flows komplizierter als das Speichern von Code. Komponenten des Flusses verweisen oft auf andere Komponenten innerhalb und außerhalb von versionierten Prozessgruppen. Außerdem enthalten sie interne Metadaten, die nicht in ein Repository verschoben werden können. Zweitens erschwert diese zusätzliche Komplexität die Nutzung der ausgereiften Lösungen, die in anderen VCS implementiert sind. Am auffälligsten sind Funktionen, die sich auf Zweige beziehen, wie z.B. Zusammenführen oder Umbasieren. Wenn Sie mit jemandem bei der Entwicklung eines Ablaufs zusammenarbeiten, wäre es am bequemsten, wenn Sie zwei Versionen des Ablaufs erstellen würden. Jeder Mitarbeiter nimmt dann seine Änderungen vor und fügt anschließend Teilergebnisse zu einem Gesamtergebnis zusammen. Das ist leider nicht möglich - einer von Ihnen wird seine Änderungen manuell wiederholen müssen.
Intro zum Albtraum der Umwelttrennung
Mit den oben genannten Einschränkungen lässt sich immer noch arbeiten, solange Sie innerhalb Ihres Teams synchronisieren. Abgesehen davon werden VCS auch verwendet, um Migrationen zwischen Umgebungen zu verbessern. Irgendwann wird der Fluss von der Entwicklungsumgebung in die Test- und Produktionsumgebung übergehen. Genau wie bei regulären Anwendungen ist eine automatisierte Migration vorzuziehen, da sie Zeit spart und weniger fehleranfällig ist. Es gibt zwei mögliche Ansätze, um dies zu erreichen: eine Registrierung für alle Umgebungen oder für jede DEV/TEST/PROD. Die erste Option ist wahrscheinlich einfacher, wirft aber eine Reihe von Sicherheitsfragen auf. Die offensichtlichste ist, dass das Produktionssystem von der Entwicklung aus ohne Einschränkungen verändert werden kann. Aufgrund dieser potenziellen Sicherheitsbedenken haben wir uns für die zweite Option entschieden. Das heißt, wir brauchten eine Möglichkeit, alles, was wir migrieren wollten, zu erhalten und zu importieren. Außerdem brauchten wir eine Möglichkeit, dies automatisch zu tun. Glücklicherweise bieten sowohl NiFi als auch NiFI Registry eine REST-API für alle Operationen, die Sie über eine Weboberfläche durchführen können. Leider ist dies nur eine einfache REST-API. Wenn wir sie für die Automatisierung nutzen wollen, müssen wir die Verbindung zu den Komponenten, die Zuordnung aller Entitäten zu den Objekten und so weiter handhaben.
Das NiFi Toolkit ist die Rettung! ... nun ja, irgendwie...
Um das oben genannte Problem zu lösen, hat die Apache-Gemeinschaft das NiFi Toolkit entwickelt . Dabei handelt es sich um Befehlszeilen-Dienstprogramme, die die REST-APIs nutzen, z. B. zum Importieren und Exportieren von Flows, zum Starten und Stoppen von Prozessgruppen und Clusterknoten. Obwohl das NiFi Toolkit viele nützliche Funktionen bietet, unterstützt es immer noch nicht die Migration von einer NiFi-Registry zu einer anderen. Hierfür müssen Sie auf jeden Fall etwas Code schreiben.
Im Code von NiFi Registry finden wir POJOs für alle Entitäten, die von der REST API verwendet werden, sowie einige Hilfsmethoden, die die Kommunikation mit unseren Komponenten erleichtern. Das Toolkit ist ein wirklich praktischer Wrapper, aber das ist auch schon alles. Jede Logik außer der Kommunikation muss von uns selbst implementiert werden. Es gibt zum Beispiel keinen Befehl zum Importieren/Exportieren aller Ströme innerhalb eines Buckets. Die einzige verfügbare Option ist das Importieren/Exportieren einer einzelnen Bewegung.
Bei der Erstellung von Deployment-Skripten haben wir beschlossen, NiFi Toolkit zu erweitern und eine Java-Anwendung zu erstellen, die die vorhandenen POJOs und Methoden nutzt. Irgendwann stellte sich heraus, dass zwar alle POJOs vorhanden waren, aber nur eine Handvoll Hilfsmethoden implementiert waren. Sie möchten den Status Ihrer Prozessgruppe abfragen? Das ist kein Problem. Sie möchten den Status aller Prozessoren innerhalb dieser Prozessgruppe abfragen? Ja... nein. Das müssen Sie selbst implementieren. Und als ob das nicht schon schlimm genug wäre - wenn Sie den Code des NiFi Toolkits integrieren möchten, ohne den Quellcode zu ändern, müssen Sie einige ziemlich hässliche Hacks durchführen.
Zusätzliche Hürden im Detail
Bei der Erstellung der automatisierten Bereitstellung für Flows mussten wir eine Menge zusätzlicher Probleme lösen, die hauptsächlich durch fehlende Funktionalitäten im NiFi Toolkit verursacht wurden. Ja, es ist technisch machbar, NiFi und NiFi Registry API-Aufrufe in einen Bereitstellungsprozess zu implementieren, mit Ausnahme von einem Dutzend Eckfällen, die unterstützt werden müssen:
- Identifizierung von Objekten - Die NiFi-Registrierung bietet eine eigene Identifizierung von Objekten, so dass sie nicht von NiFi UUIDs oder Prozessornamen abhängig ist. Dennoch verursacht die ID-Generierung bei Migrationen einige Probleme.
- Abhängigkeiten von Prozessgruppen - Wenn eine versionierte Prozessgruppe eine andere versionierte Prozessgruppe verwendet, dann enthält sie einen Verweis auf diese Prozessgruppe. Dadurch entsteht eine Beziehung zwischen den Prozessgruppen in der NiFi-Registrierung. Wenn Sie also etwas in unseren Ablauf importieren möchten, müssen Sie dies in der richtigen Reihenfolge tun, damit keine Gruppe vor ihren Abhängigkeiten importiert wird.
- UUID-Zuordnung - Wenn die Prozessgruppe importiert wird, wird ein neuer Bezeichner erzeugt. Dies führt zu einem Problem, wenn eine Prozessgruppe von einer anderen abhängt, denn wenn die Abhängigkeit importiert wird, erhält sie eine neue UUID, so dass die Gruppe, die sie verwendet, den Verweis aktualisiert haben muss.
- Registry URL in Referenzen - Der Pfad zu einer Abhängigkeit in NiFi Registry enthält die URL der Registry als eine der Eigenschaften. Wenn Sie in eine andere Umgebung wechseln, müssen Sie den Wert auf die URL der Registry aktualisieren, die Sie verwenden werden.
- Sichtbarkeit der Registry- Dieses Problem konnte beim Testen auftreten, z.B. bei Docker ist die für den Benutzer sichtbare URL eine andere als die, unter der NiFi die NiFi Registry sieht, was zu schwer zu verfolgenden Fehlern führt.
- Geltungsbereiche - NiFi Registry speichert alles über Ihren Ablauf, aber es muss sich in der versionierten Prozessgruppe befinden. Das kann ein Problem für Variablen und Steuerungsdienste sein, die oft einen globalen Geltungsbereich haben.
- Migration von Controller-Diensten - NiFi Registry speichert keine Controller-Dienste von außerhalb der Prozessgruppe. Wir müssen einen zusätzlichen Mechanismus zum Importieren und Exportieren dieser Dienste schaffen.
- Mapping von Controller-Diensten - Wenn ein Prozessor auf einen Controller-Dienst außerhalb seiner Prozessgruppe verweist, behält NiFi Registry den Verweis bei, behält aber den Controller-Dienst nicht bei. Das Ergebnis ist, dass der Prozessor nach dem Import eine ungültige Referenz hat. Wir müssen einen Mechanismus schaffen, um diese Referenzen nach dem Importieren des Ablaufs zuzuordnen.
- Abhängigkeiten von Controller-Diensten - Einige Controller-Dienste werden nicht nur von Prozessoren, sondern auch von anderen Controller-Diensten verwendet. Während der Migration erhalten alle Komponenten neue UUIDs, so dass es notwendig ist, alle Referenzen zu aktualisieren.
- Status des Flusses kontrollieren - Komponenten in NiFi haben einen Status, der vom Status der Prozessoren und der Anzahl der in der Warteschlange stehenden Flussdateien abhängt. Um eine Änderung zu ermöglichen, müssen wir den Prozessor anhalten oder die Warteschlange leeren. Das kann schwierig sein, ohne die Web-UI zu verwenden.
- Mechanismus für das geordnete Beenden - Um Konflikte bei der Bereitstellung der neuen Version zu vermeiden, sollten Sie sicherstellen, dass sich keine Flowfiles in den Flow-Warteschlangen befinden. Dazu reicht es nicht aus, einfach den Status aller Komponenten auf gestoppt zu ändern. Sie müssen einen Mechanismus implementieren, der darauf wartet, dass alle Flowfiles verarbeitet werden, und dann alles stoppt. Die einzelnen Schritte hängen von der Struktur des Ablaufs ab.
Bitte beachten Sie, dass ein scheinbar kleines Skriptprojekt zu einer komplexen Implementierung werden kann.
Zusammenfassung
Was uns gefallen hat: NiFi Registry ist ein großartiges Tool für die Entwicklung und mit NiFi Toolkit eine großartige Hilfe bei Migrationen zwischen Umgebungen.
Was wir gehasst haben: Die Technologie ist noch nicht ausgereift und erfordert viel zusätzliche Arbeit, um den eigentlichen Migrationsprozess zu automatisieren und zuverlässig zu gestalten.
Dies war ein wirklich mühsamer Weg und es ist erwähnenswert, was wir zu erreichen versuchten. Wir haben also versucht, ein System (NiFi) einzusetzen, mit dem man umfangreiche Datenpipelines erstellen kann, ohne eine einzige Zeile Code zu schreiben. Am Ende mussten wir eine Menge Code schreiben, um diese Pipelines bereitstellen zu können.
Verfasst von
Tomasz Nazarewicz
Unsere Ideen
Weitere Blogs
Contact