Blog

NiFi Ingestion Blog Serie. Teil VI - Ich habe nur eine Regel und die lautet ... - Empfehlungen zur Verwendung von Apache NiFi

Tomasz Nazarewicz

Aktualisiert Oktober 21, 2025
7 Minuten

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, und diese 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 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 versuchen wir, uns zurückzulehnen, an all die Details zu denken, die in den vorangegangenen Artikeln vorgestellt wurden, und einige allgemeine Regeln und Lehren zu ziehen, die für andere Dateningenieure nützlich sein könnten.

Machen Sie sich die Komplexität zunutze

Die Visualisierung von Flüssen ist eine der großartigsten Funktionen von NiFi. Wenn Sie einen Fluss erstellen, ist er im Grunde selbsterklärend. Wenn wir weiterhin die Vorteile dieser Funktion nutzen möchten, müssen wir die Struktur des Flusses ziemlich klar halten. Die Regeln sind meist analog zu denen, die beim Schreiben von Code verwendet werden. Es ist erwähnenswert, dass das, was als klare Struktur angesehen wird, subjektiv ist, so dass die Vorschläge hier eher Faustregeln sind als ein starres Gerüst, aber nichtsdestotrotz sind sie hier:

  • Wenn Ihr Ablauf nicht auf eine sichtbare Leinwand passt oder Sie herauszoomen müssen, um die Namen der Prozessoren zu sehen, ist es wahrscheinlich an der Zeit, einige Teile des Ablaufs in Prozessgruppen einzuteilen.
  • Wenn Ihr Ablauf zu tief wird, so dass Sie mehr als vier Verschachtelungen haben, ist es vielleicht an der Zeit, über eine Umstrukturierung des Ablaufs nachzudenken oder die Logik in Skripten/angepassten Prozessoren unterzubringen.
  • Vermeiden Sie nach Möglichkeit die Änderung von Attributen, die im Ablauf häufig verwendet werden. Ein einmal festgelegtes Attribut wird oft an vielen Stellen verwendet und wenn Sie es an einer Stelle ändern, ist die Wahrscheinlichkeit groß, dass die Logik in einigen späteren Schritten unterbrochen wird.
  • Halten Sie so viel wie möglich explizit. Vor allem beim Schreiben von Skripten ist es sehr verlockend, nur die implizit angegebenen Attribute zu bearbeiten. Wenn Sie jedoch feststellen müssen, wo sich bestimmte Attribute ändern, ist es in der Regel besser, dies in den Prozessoreigenschaften anzugeben, als im Skriptkörper danach suchen zu müssen. Bei benutzerdefinierten Prozessoren sollten Sie versuchen, eine gute Dokumentation zu führen.
  • Manchmal kann Ihr Datenfluss einfach zu viel Logik enthalten. In diesem Fall könnten Sie darüber nachdenken, ihn in mehrere Flows aufzuteilen und diese mit einem externen Dienst wie Kafka zu verbinden. Eine Verringerung der Größe macht den Ablauf lesbarer und hält die Teile einigermaßen getrennt, so dass Sie nur bestimmte Teile debuggen müssen. Es ist wie beim Essen von Spaghetti, die nur eine einzige Nudel haben. Je kürzer die Nudel ist, desto sauberer ist der Fluss.

Wählen Sie das richtige Werkzeug

Um Fallstricke bei der Entwicklung zu vermeiden, ist es wichtig, sich daran zu erinnern, dass NiFi zwar für eine Vielzahl von Problemen großartig ist, aber für manche eben nicht.... Die Entwicklung einiger Funktionen in NiFi ist einfach nicht machbar, wenn sie in anderen Tools verfügbar sind. Es ist also ein großer Fehler (der leider häufiger vorkommt, als er sollte), die Größe Ihres technologischen Stacks mit der Komplexität der Lösung gleichzusetzen. Die Integration mit anderen Verarbeitungsmaschinen, Datenbanken, Microservices usw. ist eine Grundvoraussetzung für das Design von Nifi. Selbst wenn also der Großteil der Verarbeitung in Nifi stattfindet, sollten Sie sich immer fragen, ob dies das richtige Tool für diese Aufgabe ist.

Wenn Sie die Stream-Verarbeitung mit Windowing oder etwas Logik durchführen möchten, sollten Sie andere Technologien wie Apache Flink in Betracht ziehen. Wenn Sie eine Stapelverarbeitung auf einem Hadoop-Cluster benötigen, denken Sie an die Ausführung von Hive-Abfragen aus NiFi. Wenn die Verarbeitung nicht mit SQL definiert werden kann, sollten Sie einen separaten Spark-Job dafür schreiben. Wenn Sie hingegen Dateien auf HDFS verwalten oder Hive-Abfragen erstellen und ausführen müssen, ist NiFi eine wirklich gute Wahl.

  • Wenn Sie sich für NiFi entscheiden, bedeutet das nicht, dass Sie keinen Code schreiben müssen, aber die Menge an Code, die geschrieben werden muss, kann erheblich reduziert werden.

Behalten Sie den Finger am Puls

Die Entwicklung in NiFi basiert auf der Verwendung von Out-of-the-Box-Prozessoren, was die Entwickler stärker als bei der klassischen Entwicklung von den verfügbaren Lösungen abhängig macht. Natürlich können wir unsere eigenen Lösungen erstellen, indem wir die Funktionalität mit einem Flow, einem Skript oder einem anderen benutzerdefinierten Ansatz implementieren, aber das ist in der Regel problematisch in Bezug auf die Wartung. Daher ist es unerlässlich, mit den Funktionen, die in neuen Versionen von NiFi hinzugefügt werden, auf dem Laufenden zu bleiben. Dies ist uns passiert, als wir einen Wiederholungsmechanismus für die Kommunikation mit Diensten von Drittanbietern wie Hive, HDFS usw. benötigten. Es gab keine verfügbare Lösung, also implementierten wir eine Retry-Prozessgruppe, die das tat, was wir brauchten. Das einzige Problem dabei war, dass die Prozessgruppe elf Prozessoren enthielt und an mehreren Stellen im Ablauf platziert war, was zu etwa 250 zusätzlichen Prozessoren führte. Glücklicherweise wurde ein paar Monate später der RetryFlowFile Prozessor veröffentlicht und wir aktualisierten Nifi auf eine neuere Version und nutzten den verfügbaren Prozessor.

Die Lehren daraus sind klar:

  • Wenn Sie ein allgemeines Problem lösen, wird es früher oder später auch jemand anderes lösen.
  • Halten Sie sich mit dem NiFi Change Log auf dem Laufenden, um zu sehen, was mit den neuesten Versionen kommt.

CI und CD brauchen Zeit

Unserer Erfahrung nach sind die kontinuierliche Integration und die kontinuierliche Bereitstellung von NiFi-Projekten viel zeitaufwändiger als andere Verarbeitungstechnologien. Je nachdem, wie sensibel die Daten sind und wie kritisch der Prozess ist, gibt es ein paar Möglichkeiten, damit umzugehen.

  • Entwickeln Sie direkt auf einem einzigen Haupt-NiFi-Cluster. Haftungsausschluss: Die Entwicklung in der Produktion ist im Allgemeinen eine sehr schlechte Idee. Aber in manchen Fällen ist es möglich. Sie haben eine Registry, die Versionierung ist einfach.
  • Haben Sie eine einzige NiFi-Registratur und mehrere NiFi-Cluster. Wenn Sie es sich leisten können, dass Elemente in der Produktion von einer Entwicklungsumgebung aus geändert werden können, können Sie damit viele Probleme lösen, indem Sie den Fluss verschieben.
  • Wenn Sie keine der oben genannten Möglichkeiten haben... dann viel Glück, denn es liegt eine Menge Arbeit vor Ihnen. NiFi bietet keine fertige Unterstützung für die Migration ganzer Datenströme zwischen Umgebungen. Es ist zwar machbar, aber wirklich schwierig, wenn Sie einen automatisierten Prozess wünschen.

Fazit

Dies ist der 6. Beitrag in unserer Serie und der letzte. Wir haben in einigen Kommentaren gelesen, dass NiFi in einigen früheren Beiträgen als schlecht bezeichnet wurde - dem können wir nicht zustimmen. Wir sind die Ingenieure, die einige Zeit mit NiFi verbracht haben, also schreiben wir über die Dinge, mit denen wir Probleme hatten und die wir gelöst haben. Die Technologie ist noch nicht ganz ausgereift, sie entwickelt sich noch weiter. Für viele Szenarien ist die Entwicklung von NiFi blitzschnell und ist definitiv, ohne den Schatten eines Zweifels, die Technologie, die wir empfehlen.

Verfasst von

Tomasz Nazarewicz

Contact

Let’s discuss how we can support your journey.