Présentation d'Apache NiFi

Apache NiFi est une plateforme d'automatisation des flux de données qui permet la conception visuelle, le déploiement et la gestion de pipelines de données. Son interface basée sur navigateur permet aux ingénieurs de construire des workflows complexes d'ingestion, de routage et de transformation en connectant des processeurs sur un canvas, sans écrire de code. ODP intègre NiFi déployé en configuration clusterisée et hautement disponible, gérée par Ambari.

Qu'est-ce que NiFi ?

NiFi a été développé à l'origine à la NSA et publié en open source sous licence Apache en 2014. Sa philosophie de conception s'articule autour de :

• Programmation orientée flux : les pipelines de données sont des graphes de processeurs connectés par des files d'attente. Les données circulent d'un processeur à l'autre sous forme de FlowFiles — des objets légers transportant une charge utile (octets) et un ensemble d'attributs (métadonnées clé-valeur).
• Constructeur de pipelines visuel : l'interface NiFi propose un canvas en glisser-déposer pour construire des pipelines. Les flux complexes à branches multiples, le routage conditionnel et la gestion des erreurs sont exprimés visuellement.
• Contre-pression et contrôle de flux : NiFi surveille la profondeur des files d'attente et applique automatiquement une contre-pression lorsque les processeurs en aval ne peuvent pas suivre, évitant l'épuisement de la mémoire et la perte de données sans limitation manuelle du débit.
• Suivi de provenance : NiFi enregistre un événement de provenance complet pour chaque FlowFile à chaque processeur, fournissant une piste d'audit complète de l'origine des données, des transformations subies et de la destination de livraison.

Plus de 300 processeurs

NiFi est livré avec plus de 300 processeurs intégrés couvrant pratiquement tous les patterns d'intégration :

Catégorie	Exemples de processeurs
Ingestion	GetHTTP, ListenSyslog, GetMQTT, QueryDatabaseTable, ConsumeKafka
Routage	RouteOnAttribute, RouteOnContent, DistributeLoad
Transformation	JoltTransformJSON, TransformXml, ConvertRecord, ExecuteScript
Livraison	PutHDFS, PutHiveStreaming, PublishKafka, PutS3Object, PutDatabaseRecord
Enrichissement	LookupRecord, EnrichData, GeoEnrichIP
Compression/Encodage	CompressContent, Base64EncodeContent, EncryptContent

Des processeurs personnalisés peuvent être développés en Java et déployés sous forme de fichiers NAR (NiFi Archive), étendant la plateforme à des protocoles propriétaires ou spécialisés.

Contre-pression et contrôle de flux

Le mécanisme de contre-pression de NiFi empêche les producteurs rapides de submerger les consommateurs lents. Chaque connexion entre processeurs dispose de seuils configurables :

• Seuil d'objets : nombre maximum de FlowFiles en file avant l'application de la contre-pression (par défaut : 10 000)
• Seuil de taille de données : total maximum d'octets en file (par défaut : 1 Go)

Lorsqu'une file atteint son seuil, le processeur en amont cesse de planifier de nouvelles tâches jusqu'à ce que la file redescende en dessous du seuil. Cela se propage en amont dans le graphe de flux, limitant naturellement l'ingestion à la source. Aucune limitation manuelle du débit ni minuterie d'attente n'est nécessaire.

Cluster NiFi et haute disponibilité dans ODP

ODP déploie NiFi en mode cluster pour les environnements de production. Dans un cluster NiFi :

• Tous les nœuds exécutent la même définition de flux, synchronisée via Apache ZooKeeper.
• Un nœud primaire (élu par ZooKeeper) gère les processeurs sources qui doivent s'exécuter sur exactement un nœud (par exemple, QueryDatabaseTable pour éviter les lectures en double depuis une base de données).
• Un coordinateur de cluster (également élu par ZooKeeper) gère l'appartenance des nœuds et la synchronisation du flux.
• Tous les autres processeurs s'exécutent sur chaque nœud simultanément, offrant une mise à l'échelle horizontale du débit.

Ambari gère la configuration du cluster NiFi, la surveillance de l'état des nœuds, les redémarrages progressifs et le déploiement des flux. En cas de défaillance d'un nœud NiFi, ZooKeeper déclenche une réélection du leader et les nœuds restants continuent le traitement sans intervention manuelle.

Intégration Kerberos

Dans ODP, NiFi opère entièrement dans le périmètre de sécurité Kerberos :

• Les nœuds NiFi s'authentifient auprès de HDFS, Hive, HBase, Kafka et ZooKeeper en utilisant des keytabs Kerberos provisionnés par Ambari.
• L'interface NiFi est protégée par une authentification client basée sur certificat (TLS bidirectionnel) en fonctionnement sans Knox, ou par Knox SSO lorsqu'elle est accédée via la passerelle Knox.
• Le renouvellement des keytabs Kerberos est géré automatiquement par le système de gestion du cycle de vie des identifiants intégré à NiFi.

Intégration Ranger

Autorisation

Le plugin Ranger pour NiFi applique le contrôle d'accès sur les ressources NiFi. Les politiques peuvent restreindre :

• Quels utilisateurs ou groupes peuvent accéder à l'interface NiFi
• Quels utilisateurs peuvent modifier des groupes de processeurs ou des processeurs spécifiques
• Quels utilisateurs peuvent consulter les données de provenance (qui peuvent contenir des détails sensibles sur la charge utile)

Audit Ranger pour NiFi

À partir d'ODP 1.3.2.0, le plugin Ranger pour NiFi inclut la journalisation d'audit : chaque accès à une ressource NiFi (accès à un groupe de processeurs, modifications de configuration d'un processeur, requêtes de provenance) est enregistré dans la piste d'audit Ranger. Cela fournit une auditabilité de niveau conformité pour les pipelines NiFi, répondant à des questions telles que :

• Qui a modifié un pipeline traitant des données de paiement ?
• Quels utilisateurs ont accédé aux enregistrements de provenance pour les flux transportant des données PII ?

Les événements d'audit sont écrits dans la même infrastructure d'audit Ranger (HDFS ou Solr) utilisée par tous les autres services ODP, permettant des rapports d'audit unifiés.

Cas d'usage

Ingestion de données IoT et de capteurs

Les processeurs ListenSyslog, GetMQTT et ListenUDP de NiFi peuvent recevoir des données de capteurs à haute fréquence provenant d'appareils IoT. NiFi normalise, filtre et route les données — envoyant les alertes prioritaires vers Kafka pour un traitement en temps réel et les enregistrements bruts vers HDFS pour l'archivage — le tout dans un seul flux visuel.

Ingestion via API et web scraping

Les processeurs InvokeHTTP et GetHTTP prennent en charge l'ingestion d'API REST avec une authentification configurable (OAuth 2.0, Basic, clé API), une limitation du débit et une logique de réessai. Les réponses en JSON ou XML sont analysées et routées selon les valeurs de contenu ou d'attribut.

Change Data Capture depuis les bases de données

Le processeur QueryDatabaseTable suit la valeur maximale d'une colonne à incrément croissant (par exemple, un horodatage ou un identifiant de séquence) entre les exécutions, récupérant efficacement uniquement les lignes nouvelles ou modifiées dans les bases de données relationnelles. Combiné avec PutHDFS ou PutHiveStreaming, cela construit une réplique quasi-temps réel d'une table relationnelle dans l'écosystème Hadoop.

Routage et transformation

NiFi gère le routage complexe multi-destination : un flux entrant unique peut être divisé, enrichi avec des données de référence, transformé en différents formats (JSON vers ORC, XML vers Parquet) et livré simultanément à HDFS, un topic Kafka et une API REST — avec un suivi complet de la provenance et une livraison garantie.

Livraison vers HDFS, Kafka et Hive

Cibles de livraison principales dans ODP :

• HDFS : PutHDFS écrit les FlowFiles dans HDFS en utilisant WebHDFS authentifié par Kerberos ou le client HDFS natif, avec des structures de répertoires configurables basées sur les attributs des FlowFiles (par exemple, partitionnement par date).
• Kafka : PublishKafka livre les FlowFiles sous forme d'enregistrements Kafka, avec extraction de clé configurable, sélection de partition et livraison en exactement-once via les transactions Kafka.
• Hive : PutHiveStreaming utilise l'API Hive Streaming pour écrire directement dans des tables Hive ACID, permettant une ingestion à faible latence dans des tables Hive interrogeables sans fichiers intermédiaires.