Apache Nifi

Von: Thomas Bayer
Datum: 31. August 2020
Aktualisiert: 17. Februar 2021

Mit Apache Nifi kann der Datenfluss zwischen Anwendungen modelliert und realisiert werden. Seinen Ursprung hat Nifi bei der National Security Agency , daher ist es nicht verwunderlich, dass sich das Open Source Werkzeug für große Datenmengen und eine schnelle Verarbeitung eignet. Das feingranulare Berechtigungskonzept und die Möglichkeit Verarbeitungsschritte nachzuvollziehen helfen bei der Erfüllung von Compliance-Richtlinien.

Ein wesentliches Merkmal von Nifi ist der graphische Editor, mit welchem Integrationen während ihres Betriebes nicht nur überwacht, sondern auch verändert und erweitert werden können. Hinter der Oberfläche verbirgt sich eine Infrastruktur, die Nifi weitere wünschenswerte Eigenschaften wie Performanz, Robustheit und Skalierbarkeit verleihen.

Apache Nifi kann leichtgewichtig lokal auf einem Rechner, oder ausfallsicher als Cluster in der Cloud betrieben werden.

Dieser Artikel stellt Nifi und seine wichtigsten Konzepte vor und hilft bei der Auswahl eines geeigneten Werkzeugs für die Integration.

2 Geschichte

Auf der Suche nach dem idealen Werkzeug für die Systemintegration hat die NSA die folgenden Anforderungen aufgestellt:

• Der Nachrichtenfluss sollte auf einen Blick ersichtlich sein
• Anpassungen und Änderungen sollten im Betrieb durchgeführt werden können, ohne Verzögerung durch Entwicklungs- und Anpassungsprozesse.
• Es soll nachvollziehbar sein, wohin Daten geflossen sind
• Feingranulare Berechtigungen sollten zur Konformität beitragen
• Es sollte sowohl für große als auch für viele kleine Nachrichten geeignet sein

Schnell wurde den Beteiligten klar, dass die gestellten Anforderungen von keinem Open Source oder kommerziellen Produkt am Markt erfüllt werden konnten. Daraufhin hat die NSA beschlossen, unter ihrer Regie ein Werkzeug entwickeln lassen.

Ursprünglich wurde NiagaraFalls durch die Firma Onyara im Auftrag der NSA entwickelt. Später wurde das Startup von Hortonworks aufgekauft, die wiederrum vom Cloudera gekauft wurden.

2014 wurde NiagaraFalls unter Open Source gestellt, an die Apache Organisation übergeben und in Nifi umbenannt.

3 Flow based Programming

Apache Nifi verwendet das Programmier-Modell Flow-based Programming, um Robustheit und Flexibilität zu bieten.

Beim Flow-based Programming übernimmt ein Netzwerk von Prozessoren die Verarbeitung der Daten. Ein Prozessor ist eine Blackbox, dessen Inneres dem Rest des Systems verborgen bleibt. Die Prozessoren kommunizieren untereinander über strukturierte Nachrichten, die FlowFile genannt werden. Jeder Prozessor benötigt nur das Wissen über die zu empfangenen und zu sendenden Nachrichten. Puffer-Speicher, zwischen den Prozessoren sorgen für eine lose Kopplung sowie für Robustheit und Skalierbarkeit. Wird die Verarbeitungskette unterbrochen, könnnen Nachrichten in einer Warteschlange zwischengespeichert werden, bis das Problem behoben ist.

Abbildung : Flow aus Prozessoren und Queues

4 Graphische Benutzeroberfläche

Bisher konnte mich keine graphische Benutzeroberfläche für die Erstellung von Integrationen überzeugen. Ganz anders bei Apache Nifi, ich kann nicht aufhören Integrationen auszubauen und zu verbessern.

Entwicklung und Betrieb werden bei Apache Nifi mit einer Web-basierten Benutzeroberfläche durchgeführt. Im Gegensatz zu anderen Produkten können Integrationen, die gerade produktiv im Einsatz sind, verändert werden. Ein Stoppen der Route ist dazu nicht notwendig. Die konsequente Umsetzung des Flow-based Programming mit Puffern zwischen den Prozessoren macht es möglich, einfach eine Komponente zu stoppen, zu verändern und wieder in Betrieb zu nehmen. Die Validierung des Flows sorgt dafür, dass der Fehlerfall immer berücksichtigt wird, um keine Nachrichten zu verlieren. Tritt nach einer Modifikation ein Fehler auf, so laufen die Nachrichten in eine Warteschlange und werden nach der Korrektur nachverarbeitet. Das Durchlaufen mehrerer Stages wie Entwicklung und Test entfällt.

Der Screenshot unten zeigt die ansprechende und funktionale Oberfläche im Web-Browser.

Abbildung : Graphischer Flow-Editor im Browser

Zur Entwicklung von Integration-Flows werden Bausteine auf eine Leinwand gezogen, mit anderen Bausteinen verbunden. Anschließend werden die Bausteine über Formulare konfiguriert.

Eine Landkarte mit Ausschnitt erleichtert die Navigation selbst in großen Integrationen. Des Weiteren gibt es die Möglichkeit Flows in Baumform über mehrere Ebenen zu gliedern.

Abbildung : Landkarte mit Ausschnitt

5 Backpressure

Backpressure sorgt dafür, dass keine Ressource über deren Kapazität beansprucht wird. Bevor eine Platte oder eine Datenbank vollläuft, wird die Verarbeitung der Nachrichten gezielt gedrosselt.

Wie Backpressure funktioniert zeigt der folgende Screenshot an einem Beispiel. Die Prozessoren sind lose über Queues miteinander verbunden. In der Queue oben im Bild ist zu erkennen, dass noch 282 Nachrichten auf die Verarbeitung warten. Die Queue unten ist mit 10.000 Nachrichten voll, wie am roten Balken zu erkennen ist. Wahrscheinlich kommt ein Prozessor weiter unten im Flow nicht mit der Verarbeitung nach. Nifi bremst daraufhin vorgelagerte Prozessoren ab, um eine Überlastung des Systems zu verhindern.

Die Kapazität jeder Queue lässt sich über die maximale Anzahl an Nachtrichten sowie über die Größe festlegen.

Abbildung :

Ist das Problem, welches einem Nachrichtenstau verursacht hat, behoben oder der nachgelagerte Prozessor holt auf, dann fließen die Nachrichten wieder wie gewohnt durch den Flow.

6 Architektur

Alle Apache Nifi Komponenten wie z.B. Scheduler und Repositories laufen in einer einzigen Java VM.

6.1 Repositories

Für die Queues ist kein separater Message Broker notwendig. Nifi verwendet für das Zwischenspeichern der Nachrichten seine Repositories. Eine physikalische Übertragung der Daten ist beim Übergang von einer Queue zur nächsten nicht notwendig. Es genügt das Ändern eines Zeigers. Alle Standard-Repositories legen ihre Daten im Dateisystem ab.

Die Implementierungen der Repositories sind austauschbar. Beispielsweise werden Repositories mitgeliefert, die Daten verschlüsselt auf der Platte ablegen.

6.2 FlowFile Repository

Metadaten wie z.B. die Attribute einer Nachricht, sowie ein Zeiger auf den Inhalt der Nachricht werden im FlowFile Repository abgelegt. Der Zeiger verweist auf einen Eintrag im Content-Repository.

6.3 Content Repository

Die Daten eines FlowFiles werden im Content Repository abgelegt. Wird ein FlowFile von einem Prozessor zum nächsten weitergeleitet, so verbleiben die Daten unangetastet im Content Repository. Da die Daten bei einem Übergang nicht gelesen und transportiert werden müssen, können FlowFiles effizient durch einen Flow fließen. Nachdem ein FlowFile verarbeitet wurde, kann der Inhalt archiviert werden.

Wird der Speicher knapp, so entfernt das Content Repository Inhalte, die bereits verarbeitet wurden. Die ältesten Nachrichten werden dabei zuerst gelöscht.

Für Änderungen an den Daten verwendet Nifi eine Copy on Write Strategie. Anstatt Daten zu ändern, wird einfach eine neue Kopie erzeugt. Dies trägt zu einer besseren Performanz bei und ermöglicht es nachträglich die Änderungen jedes Verarbeitungsschrittes nachzuvollziehen.

6.4 Provenance Repository

Den Verlauf, den die Nachrichten durch die Flows nehmen, wird im Provenance Repository abgelegt, damit später die Änderungen falls gewünscht nachvollzogen werden können. Mehr dazu findest du im Abschnitt über Provenance.

7 Entwicklung von Integrationen

7.1 Transformation

Nifi bringt selbst keinen Mapper mit, um Daten von einem Format in ein anderes zu transformieren. Die Plattform bietet aber mehrere Möglichkeiten Daten in ein anderes Format zu transformieren:

• Jolt
• Über die eigene RecordPath Sprache
• Mit der eigenen Execution Language
• Über ein Groovy Skript
• JSONPath

8 Installation

Apache Nifi benötigt eine virtuelle Java Maschine und kann auf Linux, Windows und MacOS betrieben werden. Nach dem Download kann der Server sofort gestartet werden. Je nach Anforderung kann Nifi auf einem Raspberry Pi bis hin zum Cluster gegebenenfalls in der Cloud betrieben werden.

9 Konnektoren

Spezielle Prozessoren dienen als Konnektoren zur Außenwelt. Beispiels weise kann der JMSConsume Prozessor Nachrichten empfangen, die er dann als FlowFile in einen Flow einspeist. Oder der PutSQL Prozessor kann Daten in einer SQL Datenbank ablegen.

12 Provenance

Ein Alleinstellungsmerkmal von Apache Nifi ist die Möglichkeit, die Verarbeitung der Nachrichten nachträglich lückenlos nachzuvollziehen. Der Screenshot unten zeigt eine Tabelle mit Verarbeitungsschritten. Für jeden Schritt wird protokolliert, wann und wie lange die Ausführung gedauert hat. Man kann sich anzeigen lassen, wie der Inhalt der Nachricht vor Ausführung und nach der Ausführung ausgesehen hat. Es ist auch möglich eine Nachricht von einem beliebigen Verarbeitungsschritt an erneut einzuspielen.

Abbildung :

Das Lineage Diagramm zeigt die Abstammung eines FlowFiles. Im folgenden Graph ist zu erkennen, welche Schritte nacheinander erfolgt sind.

Abbildung :

Die Daten über einen Verarbeitungsschritt können länger archiviert werden, als die Daten selbst, so dass der Speicher für die Provenance optimal genutzt werden kann.

13 Ist Nifi ein Enterprise Service Bus?

Der Begriff ESB steht mittlerweile für Integrationsprodukte aus den letzten zwei Jahrzehnten die durch folgende Eigenschaften gekennzeichnet sind:

• Zentrale Integration
• Kannonisches Datenmodell, meist XML
• Eigenes nicht Cloud-fähiges Deploymentmodell
• Große Herstellerabhängigkeit
• Beschränkte DevOps Möglichkeiten. Einbindung ins CI/CD oft nicht möglich.
• Automatisierte Tests sind oft nicht möglich
• Schwergewichtiges Produkt
• Eigene Konsolen für Monitoring und Logging
• Eingeschränkte Möglichkeit der Versionierung über ein SCM wie z.B. git

Ein typisches Gegenbeispiel zum zentralen ESB ist das leichtgewichtige Integrationsframework Apache Camel. Wie sieht es aber mit Apache Nifi aus? Ist Apache Nifi ein klassischer Enterprise Service Bus?

Die meisten der obigen Punkte gelten auch für Apache Nifi. Bei Nifi laufen die Integrationen auf einem zentralen Server. Das Deployment einzelner Flows ist nicht vorgesehen. Nifi stellt ein in sich abgeschlossenes System dar, das alles von der Entwicklung über den Betrieb bis zum Monitoring in einem Produkt vereint. CI/CD Einbindung und das automatisierte Testen sind vielleicht nur mit Tricks möglich. Wenigstens lässt sich die zentrale XML Datei, die die Beschreibung der Flows enthält in einem Source Code Verwaltungssystem ablegen. Apache Nifi ist daher ein klassischer Enterprise Service Bus.

Apache Nifi verfolgt einen zentralen Einsatz und unterstützt nicht die Verteilung von einzelnen Integrationen als selbstständige Microservices. Würde man versuchen Nifi auf Microservices umzustellen, würde man gerade die Vorteile verlieren, die für Nifi sprechen. Nifi verdankt seine Eigenschaften wie z.B. Performanz und Transparenz der Tatsache, dass alle Komponenten wie Flows und Infrastruktur wie Content Repository in einer virtuellen Maschine ablaufen. Die bei Microservices übliche Kommunikation über Prozessräume mit der verbundenen Notwendigkeit zur Serialisierung und dem Kopieren von Nachrichten entfällt bei Nifi. Nifi erzielt durch die Vermeidung von Serialisierung und Kopieren seine hohe Performanz.

Leider muss man in der IT Kompromisse machen. Entweder Integration als Microservices mit Einschränkungen in Bezug auf Performanz, Nachvollziehbarkeit, … dafür mit der Möglichkeit neue Versionen einer einzelnen Integration über Continuous Deployment auszurollen. Oder auf der anderen Seite, ein in sich geschlossenes System, ein Monolith für die Integration, der aber viele Features für den Betrieb bietet, die sich mit Microservices nicht so leicht umsetzen lassen.

14 Betrieb

Der Betrieb von Integrationen wird von Nifi sehr gut unterstützt. Der Großteil des Betriebes kann von der Benutzeroberfläche aus durchgeführt werden.

Alle Queues sind mit einem Klick einsehbar. Nachrichten können gelöscht, oder neu eingespielt werden. Komponenten lassen sich im Betrieb anhalten, umbauen und neustarten, ohne dass der gesamte Flow gestoppt werden muss. Zwischen jeder Komponente gibt es einen Puffer, der für die notwendige lose Kopplung sorgt.

In der neusten Version ist eine Anbindung von Prometheus möglich.

15 Performanz

Wie bereits weiter oben aufgeführt, erzielt Nifi seine Performance dadurch, dass der zur Entkopplung notwendige Broker in Nifi integriert ist und in derselben Java ausgeführt wird. Der Transport von einer Nachricht von einem Baustein zum nächsten, ist nur die Änderung eines Feldes der Metadaten. Es ist kein Kopieren, keine Serialisierung und kein Übertragen von Daten notwendig.

Durchsatz und Latenz als Bandbreite und Verzögerungszeit stehen im Konflikt. Wird die Bandbreite erhöht, so hat dies negative Ausauswirkung auf die Latenz, die dann ebenfalls größer wird. Bei Nifi kann für jeden Prozessor festgelegt werden, wie der Kompromiss aussieht. Es ist stufenlos möglich die Latenz oder den Durchsatz zu optimieren.

16 Sicherheit

Sicherheit ist eine der Stärken von Nifi. Mit Nifi sollte es möglich sein, fast alle Anforderungen an Authentifizierung, Autorisierung oder Auditing umzusetzen.

Zertifikate für die Knoten eines Nifi-Clusters kann das TLS-Tookit ausstellen. Das Werkzeug kann in der Kommandozeile oder als Server genutzt werden. Beim Aufsetzen eines Clusters mit TLS Unterstützung ist die Erstellung der Zertifikate eine willkommene Hilfe. Über ein intermediate Certificate kann Nifi in eine bestehende PKI-Infrastruktur eines Konzerns eingebunden werden.

OpenId Connect, Client Zertifikate oder Benutzername und Passwort kann für eine Authentifikation am Server verwendet werden. Externe Benutzerverwaltungen können über LDAP, Kerberos und OpenId Connect angebunden werden.

Sicherheit und Konformität werden bei Nifi großgeschrieben, es ist daher nicht verwunderlich, dass das feingranulare Berechtigungskonzept keine Wünsche offenlässt. Für Bediener kann der Zugriff soweit eingeschränkt werden, dass diese nur bestimmte Aufgaben wie z.B. das Anstoßen einer erneuten Verarbeitung durchführen können, ein Blick auf die Daten aber nicht möglich ist.

Eine Besonderheit von Nifi sind sensitive Properties z.B. für die Konfiguration von Passwörtern. Sensitive Properties können nur mit den entsprechenden Rechten eingesehen werden. Ein Entwickler kann sensitive Properties kopieren, aber nur in Properties, die ebenfalls geschützt sind. Eine Arbeit mit sensitiven Daten ist so möglich, ohne diese einsehen zu können.

Potentiell gefährliche Bauteile werden mit einem roten Wappen in der Oberfläche gekennzeichnet. In der Abbildung unten ist ein Baustein zu sehen, der ein Skript ausführt. Da dieses Skript mit den Rechten der Nifi Instanz ausgeführt wird, wird der Hinweis angezeigt.

Abbildung : Warnung mit Schild-Symbol vor gefährlichen Komponenten.

Abbildung: Warnung mit Schild-Symbol vor gefährlichen Komponenten.

17 Robustheit

Zur Robustheit trägt die Umsetzung des FlowFile-Konzeptes mit den Queues zwischen den Komponenten bei. Für die Persistierung verwendet Nifi ein Write-Ahead-Log, welches Datenverlust bei Systemabstützen verhindern soll.

18 Clustering

Nifi kann als masterless-Cluster betrieben werden. Die Last der Verarbeitung wird auf alle Knoten des Clusters aufgeteilt und die Verfügbarkeit erhöht. Über die Benutzeroberfläche können clusterweit neue Flows angelegt oder bestehende modifiziert werden. Die Änderungen werden automatisch an alle teilnehmenden Knoten übertragen. Auf allen Knoten werden die gleichen Flows angeboten. Eine Nachricht wird jeweils von einem Knoten verarbeitet, so dass die Last im Cluster geteilt wird.

Verwaltet werden kann ein Cluster über die Benutzeroberfläche oder über die Kommandozeile. Zur Koordination im Cluster wird der Apache Zookeeper verwendet.

19 Management API

Über ein API kann auf Nifi Installationen und Cluster zugegriffen werden.

Mit dem API kann auf jeden Bestandteil eines Flows zugegriffen werden. Beispielsweise können über das API die folgenden Aufgaben durchgeführt werden:

• Abfrage des Zustandes
• Abfrage der Benachrichtigungen (Bulletins)
• Historie der letzten Verarbeitungsschritte
• Leeren von Queues
• …

Das Listing zeigt den Abruf von Daten aus einer Queue zwischen zwei Prozessoren:

curl -X POST  http://localhost:8080/nifi-api/flowfile-queues/ed7b-013-1000-932a-3f4ffa88/listing-requests
{
  "listingRequest": {
    "id": "ed109135-0173-1000-3c3b-403473d0cf12",
    "uri": "http://localhost:8080/nifi-api/flowfile-queues/ed0b137b-0173-1000-932a-3f4ffae92b88/listing-requests/ed109135-0173-1000-3c3b-403473d0cf12",
    "submissionTime": "08/14/2020 15:02:32.757 CEST",
    "lastUpdated": "15:02:32 CEST",
    "percentCompleted": 0,
    "finished": false,
    "maxResults": 100,
    "state": "Waiting for other queue requests to complete",
    "queueSize": {
      "byteCount": 658,
      "objectCount": 12
    },
    "sourceRunning": true,
    "destinationRunning": false
  }
}

Die Benutzeroberfläche von Nifi steuert über das API selbst die Nifi Knoten. Das heißt, alles was man über die Benutzeroberfläche tun kann, lässt sich auch über das API durchführen und damit automatisieren.

20 Nifi, die Cloud und Integration-Microservices

Nifi Knoten können lokal, im Container oder in der Cloud betrieben werden. Was nicht ohne weiteres geht, ist der Betrieb von einzelnen Flows in isolierten Containern. Theoretisch könnte man jeden Flow in einen eigenen Container samt komplettem Nifi packen. Damit würde man jedoch viele Vorteile wie z.B. die zentrale Verfolgbarkeit einbüßen. Die Architektur von Nifi passt nicht zu den Microservices.

21 Vor- und Nachteile

Dieser Abschnitt zählt die Vorteile und Nachteile von Apache Nifi auf.

21.1 Vorteile

Die Liste der Vorteile bei Nifi ist lang:

• Ansprechende und funktionelle Oberfläche
• Großer Funktionsumfang
• Durchdachte Lösung
• Liberale Open Source Lizens (ASF )
• Viele Security-Funktionen und Fokus auf einen sicheren Betrieb
• Nifi macht es leicht, Vorschriften zur gesetzeskonformen Verarbeitung von Daten umzusetzen.
• Gute Unterstützung der Enterprise Integration Patterns
• Für den Betrieb sind keine speziellen Kenntnisse wie Java notwendig.
• Hohe Performanz
• Beliebige Skalierbarkeit
• Zahlreiche Konnektoren
• Queues bieten Priorisierung
• Backpressure verhindert die Überlastung von Kapazitäten
• Enthält bereits einen „Message Broker" für Queuing, Entkopplung und Robustheit
• Es gibt Werkzeuge für Backup, Zertifikatsausstellung, Clusterverwaltung, …
• Erweiterbarkeit
• Ausführliche, gut gegliederte und anschauliche Dokumentation
• Große Installationsbasis und Community

21.2 Nachteile

Apache Nifi hat nur wenige Nachteile, die sich um die Möglichkeit drehen, Container als Runtime für einzelne Flows zu verwenden. Der Trend ist die Ausführung von Integration Flows direkt auf einer Container Infrastruktur. Ob die Ausführung von Integration Flows und Infrastruktur in jeweils einzelnen isolierten Containern sinnvoll ist, ist eine andere Frage. Nifi nutzt die Nähe von Flow und Repository innerhalb einer virtuellen Java Maschine, um die gewünschten Eigenschaften zu erzielen. Den ersten Nachteil unten sollte man daher mehr als Besonderheit anstatt als Nachteil sehen.

• Nutzt eigene Runtime. Container z.B. Docker und Kubernetes können nicht ohne weiteres als Runtime für einzelne Flows verwendet werden.
• Unklare Zukunftsaussichten (Unpopulärer zentraler Ansatz)

22 Fazit

Apache Nifi ist ein Beispiel dafür, wie ein guter Enterprise Service Bus sein sollte. Nifi ermöglicht die zentrale Verbindung von Anwendungen. Mit der zentralen Architektur werden zahlreiche Vorteile wie Performanz, Robustheit, Sicherheit und eine zentrale Verwaltung und Kontrolle realisiert.

Der zentrale Ansatz ist gleichzeitig auch der größte Nachteil von Nifi. Momentan ist die dezentrale Integration verteilt auf viele Microservices in separaten Containern angesagt. Wer für die Integration die Microservices Architektur verwenden möchte, sollte das nochmals überdenken oder ein anderes Werkzeug wie z.B. Apache Camel oder Spring Integration verwenden. Selbstverständlich kann Nifi zusammen mit Microservices eingesetzt werden. Bei der Werkzeugauswahl ist dies die große Entscheidung: Dezentrale oder zentrale Integration. Wer sich für die zentrale Integration entscheidet, der hat mit Apache Nifi definitiv einen Kandidaten für die Hotlist bei der Produktauswahl.

Ein Alleinstellungsmerkmal von Nifi ist die Möglichkeit Integrationen während des laufenden Betriebes zu erweitern oder zu verändern. Änderungen sind oft in Minuten durchgeführt und helfen so Aufwände und Zeit zu sparen.

Für das Umsetzen einer Integrationslösung, die konform zu irgendwelchen Richtlinien sein muss, ist Nifi ideal. Datenschutz, Dokumentation und Nachverfolgbarkeit lassen keine Wünsche offen.

Trotz des graphischen Editors, der eine Einarbeitung erleichtert, sollte der Einsteiger sich Zeit nehmen, um die Konzepte und die Architektur von Nifi zu verstehen.

Vor kommerziellen Werkzeugen muss Apache Nifi sich keinesfalls verstecken. Im Gegenteil Nifi bietet Eigenschaften, die man sonst kaum findet. Wer Wert auf Nachvollziehbarkeit, Sicherheit und Performanz legt, sollte sich Nifi näher anschauen.

23 Quellen

• Flow-based Programming, Wikipedia
• Hortonworks Acquires Onyara, Early Startup With Roots In NSA, Techcrunch