Het is een vogel!
Nee, het is een vliegtuig!
Nee, het is…super grover?
Nou, dat gevoel bekroop mij een beetje toen ik voor het eerst Apache NiFi zag en de documentatie doornam.
Het is een ETL-tool voor Hadoop!
Nee, het een grafische versie van Flume!
Nee, het is…Apache NiFi?
Het zoveelste incubator project van Apache. By the way. Als je je ooit afvraagt of Apache ook wel eens projecten stopt; ja dat doen ze. Projecten worden dan verplaatst naar de Attic.
Maar goed terug naar NiFi. NiFi is een Apache project dat ze hebben gedoneerd gekregen van de NSA (jawel, die van Snowden). Na er acht jaar aan gesleuteld te hebben vond de NSA blijkbaar dat de rest van de wereld ook maar eens iets mee moest gaan doen met hun Niagarafiles. Dit is overigens het tweede project dat Apache van de NSA heeft gekregen, de eerste was de NoSQL database Accumulo.
Maar vanwaar die verwarring? Nou laten we eens beginnen met een plaatje van een zelf in elkaar geknutselde flow.
Dat ziet er verdacht veel uit als een ETL-tool nietwaar? En toch is het dat zeker niet. Dus in het kader van het begrijpen van NiFi laat de gedachte dat je er ETL mee kan doen los. Echt waar, Let It Go… NiFi is gebaseerd op het idee van flow-bases-programming
Flow-Based Programming defines applications using the metaphor of a “data factory”. It views an application not as a single, sequential process, which starts at a point in time, and then does one thing at a time until it is finished, but as a network of asynchronous processes communicating by means of streams of structured data chunks, called “information packets” (IPs)
Als basis gebruikt NiFi een FlowFile (dit is overigens niet een echt bestand). Een FlowFile is een informatiepakket dat bestaat uit een header met attributen en de content, de data zelf. De data kan van alles zijn. Gestructureerd, semi- of ongestructureerd dat maakt niet. Op basis van de header kan NiFi geprogrammeerd worden om bepaalde acties uit te voeren. Denk bijvoorbeeld aan het routeren naar een ander systeem (RouteOnAttribute) of een inhoudelijke actie op de data in de FlowFile. De NiFi applicatie heeft maar een beperkt aantal componenten dat je op het canvas kan slepen.
Het belangrijkste component is de Processor. De processor kan van alles doen; data ophalen, data wegschrijven, routeren (context en content driven), zoek-vervang, loggen, dedupliceren you name it. Standaard zijn er 76 processor types aanwezig en mocht je de skills hebben dan kan je zelf een eigen processor type ontwikkelen.
Nu is een van dingen waar ik in het begin maar niet aan kon wennen is dat je maar één canvas hebt waarop je alles neerzet. Het is dus niet zo dat je een NiFi-flow kan openen, wijzigingen, opslaan en sluiten om daarna de volgende te openen. Je NiFi installatie is je NiFi-flow. Je bouwt alles dus in de ene flow. Mocht je flow heel complex worden dan kan je zogenaamde Process Groups aanmaken (voor mensen die toch nog in ETL termen denken; een maplet). Hiermee kan je enige structuur aanbrengen in je NiFi flow. Een Process Group kan overigens ook een zogenaamde Remote Process Group zijn. Dit is een andere NiFi installatie die je dan vanuit jouw NiFi aanroept.
Elke processor kan op zijn eigen manier geconfigureerd worden en gescheduled worden. Zou kan ik een GetFile processor hebben die via een CRON schedule draait en een DuplicateFlowFile die timer driven is.
De connectie tussen Processor noemt men een Connection en deze vormen een soort queue. Per connection kunnen er diverse instelling worden geconfigureerd.
NiFi komt verder met uitgebreide monitoring opties, is schaalbaar (clustering), security (authenticatie en autorisatie) ,performance-statistieken, auditing tools en last but not least data lineage.
Al met al een indrukkende hoeveelheid opties voor een 0.2 versie.
Maar nu de hamvraag; is het iets voor ons? Ik denk zeker van wel, hoewel ik nu nog niet mijn geld op de 0.2 versie zou zetten. Qua toepassingsgebied past het wat mij betreft prima in de hoek van Apache Camel en consorten.
Nu maar hopen dat het niet op de Attic belandt.
