Von Janis Ax auf Dienstag, 13. Dezember 2022
Kategorie: Data Management

Alles neu? Veränderungen von NiFi 1.12 zu 1.18 (HDF zu CDP-Migration)

Nutzen Sie Apache NiFi noch in Ihrer Hortonworks Dataflow (HDF) Umgebung? Dann ist es höchste Zeit, eine Migration zur neueren Cloudera Dataplatform (CDP) in Betracht zu ziehen. In diesem Blogartikel werde ich die wichtigsten Änderungen zwischen der letzten Apache NiFi-Version auf einer HDF-Umgebung (1.12) und der aktuellen Apache NiFi-Version (1.18) aufzeigen. Wir werden sehen, dass es zum Glück keine „Breaking Changes“ gibt. Daher sind keine Inkompatibilitäten zwischen den NiFi-Versionen zu erwarten und einer erfolgreichen Migration Ihrer Dataflows steht nichts im Weg. Ein Upgrade ist aber dennoch zu empfehlen, denn zahlreiche Neuerungen und Verbesserungen sorgen dafür, dass eine Migration nicht nur aus Support-Sicht sinnvoll ist, sondern vor allem die Entwickler unterstützt. 

Ein neuer Anstrich

Vor allem Anfänger fanden die UI und die UX von Apache NiFi teilweise wenig ansprechend und nicht sehr intuitiv. Hier hat sich inzwischen einiges getan, sodass nicht nur Einsteiger, sondern auch erfahrene Power-User von den Änderungen profitieren.

Folgende Änderungen haben ihren Weg in die NiFi-UI gefunden:

Tuning unter der Haube

​Aber nicht nur UI und UX wurden verbessert, auch die darunterliegende Architektur wurde angepasst.

Parameter

In dem Blogartikel „Variablen? Parameter? Was denn nun? Wie ein Dataflow in Apache NiFi parametrisiert wird" haben wir bereits erläutert, wieso Sie statt Variablen lieber Parameter nutzen sollten. Seit Version 1.15 kann ein ParameterContext jetzt Parameter von anderen (auch von mehreren) ParameterContexten vererbt bekommen. Dazu gibt es seit Version 1.18 inzwischen mit Parameter-Providern neue Controller Settings. Damit ist es möglich, Parameter von externen Quellen, wie z. B. Kubernetes Secrets, Umgebungsvariablen oder aber einem Hashicorp Vault zu lesen und in NiFi zu verwenden. Der NiFi-Entwickler Bryan Bende hat dazu einen lesenswerten Blogartikel geschrieben, den Sie hier finden.

Dies ermöglicht einen neuen Umgang mit Parametern. Veraltete Passwörter sowie aufwändiges Verwalten von sensitiven Informationen gehören der Vergangenheit an.

Clustermanagement

Weiterhin hat sich die interne Clusterverwaltung geändert. Sie wurde an moderne Cloud-Infrastrukturen angepasst.

Eines der größten Probleme bei älteren NiFi-Clustern war die Tatsache, dass diese nicht wirklich hochverfügbar waren. Wenn ein Knoten ausfiel, haben die anderen zwar weiter FlowFiles verarbeitet und soweit möglich auch neue erzeugt, aber die UI war für die Dataflow-Entwickler zu diesem Zeitpunkt nicht nutzbar.

Das hat sich nun verändert. Wenn ein Knoten das Cluster verlässt, können weiterhin ganz normal Änderungen am Dataflow vorgenommen werden. Die flow.xml.gz-Datei, also der Dataflow, wird automatisch synchronisiert.

Retry-Mechanismus

Völlig neu und eine große Erleichterung in der Flow-Entwicklung ist der Retry-Mechanismus. Während früher ein extra Prozessor – Retry-FlowFile – genutzt werden musste oder eigene Lösungen implementiert wurden, um ein FlowFile im Fehlerfall erneut zu prozessieren, hat sich dieser Prozess deutlich verbessert.

Mittlerweile sind alle verfügbaren Verbindungen in einem separaten Tab "Relationships" angeordnet. In diesem Tab kann nun eine Retry-Option gewählt werden. Damit kann definiert werden, ob ein Flow File direkt intern wiederholt und wie oft dies probiert werden soll.

Eigene Lösungen bzw. Workarounds sind daher nicht mehr nötig und Retry-Einstellungen lassen sich leicht für jeden Prozessor definieren.

Eingehende Verbindungen

In alten NiFi-Umgebungen, die als Cluster aufgebaut waren, konnte es passieren, dass Flow Files permanent in einer Queue lagen und nicht bearbeitet wurden. Das ist immer dann aufgetreten, wenn ein Prozessor nur auf dem Primay Node gescheduled wurde, aber eingehende Verbindungen hatte, die auf allen Knoten liegen konnten. Der Prozessor wurde dann beispielsweise auf Knoten 2 gescheduled, aber Flow Files, die auf Knoten 1 oder 3 lagen, wurden niemals bearbeitet.

Dies kann nun nicht mehr auftreten. Alle Prozessoren, die eingehende Verbindungen haben, müssen inzwischen auf allen Knoten ausgeführt werden!

Migration zu CDP?

Die NiFi Community ist stets sehr drauf bedacht, keine gravierenden Veränderungen (Breaking Changes) zuzulassen. So auch in diesem Fall. Trotz der vielen Veränderungen und Verbesserungen sind keine Probleme zu erwarten, wenn Sie ihre NiFi Flows von NiFi 1.12 (HDF) auf neuere Versionen, wie NiFi 1.18 (CDP) migrieren.

Änderungen, die gravierender wirken, wie z.B. die Tatsache, dass ein Prozessor nun nicht mehr als Primay Node gescheduled werden kann, wenn er eingehende Verbindungen hat, sorgen ebenfalls für keine größeren Probleme.

NiFi kennzeichnet die Prozessoren dann als invalide und dies muss manuell behoben werden.

Und nun?

Sie kennen nun die Highlights der Neuerungen von NiFi 1.12 zu NiFi 1.18! Natürlich hat sich noch vieles Weitere getan. Viele Fehler wurden ausgebessert und die aktuelle Version bringt wieder neue Prozessoren und Funktionen mit.

Haben Sie weitere Fragen zur Migration oder Konfiguration von NiFi in CDP oder HDP. Vielleicht hilft Ihnen unser kostenloses NiFi Webinar oder das mehrtägige Apache NiFi Seminar. Zusätzlich sind wir dieses Jahr im Dezember bei den IT-Tagen präsent und stellen dort NiFi vor! Selbstverständlich können Sie sich auch mit Ihren Fragen direkt an uns wenden.

Seminarempfehlungen

Kommentare hinterlassen