Différence entre Apache NiFi et StreamSets
Je prévois de faire un projet de classe et je passais en revue quelques technologies où je pouvais automatiser ou définir le flux de données entre systèmes et découvrir qu’il en existait quelques-unes, à savoir Apache NiFi et StreamSets (à ma connaissance). Ce que je ne pouvais pas comprendre, c'est la différence entre eux et les cas d'utilisation où ils peuvent être utilisés. Je suis nouveau dans ce domaine et si quelqu'un pouvait m'expliquer un peu, ce serait très apprécié. Merci
Suraj,
Excellente question.
Ma réponse est en tant que membre du comité de gestion de projet open source Apache NiFi et en tant que passionné du domaine de la gestion de flux de données.
Je suis impliqué dans le projet NiFi depuis le début de celui-ci en 2006. Mes connaissances sur Streamsets étant relativement limitées, je les laisse parler comme elles l'ont fait.
L’essentiel pour comprendre est que NiFi a été conçu pour faire une chose vraiment très importante, la gestion des flux de données. Son design est basé sur un concept appelé Flow Based Programming (Programmation basée sur le flux) que vous voudrez peut-être lire et référencer pour votre projet ' https://en.wikipedia.org/wiki/Flow-based_programming '
Il existe déjà de nombreux systèmes produisant des données telles que des capteurs et autres. Il existe de nombreux systèmes qui se concentrent sur le traitement de données, comme Apache Storm, Spark, Flink, etc. Enfin, de nombreux systèmes stockent des données telles que HDFS, des bases de données relationnelles, etc. NiFi se concentre uniquement sur la tâche de connecter ces systèmes et de fournir l'expérience utilisateur et les fonctions essentielles nécessaires pour bien le faire.
Quelles sont certaines de ces fonctions clés et des choix de conception faits pour rendre cela efficace:
1) Commande et contrôle interactifs
Le travail de quelqu'un qui tente de connecter des systèmes consiste à pouvoir interagir rapidement et efficacement avec les flux de données constants qu'ils voient. L’interface utilisateur de NiFi vous permet de faire cela au fur et à mesure que les données circulent, vous pouvez ajouter des fonctionnalités pour les exploiter, créer des copies de données pour essayer de nouvelles approches, ajuster les paramètres actuels, voir les statistiques récentes et historiques, une documentation en ligne utile, etc. Presque tous les autres systèmes, par comparaison, ont un modèle orienté conception et déploiement, ce qui signifie que vous effectuez une série de modifications, puis que vous les déployez. Ce modèle est correct et peut être intuitif, mais pour le travail de gestion de flux de données, cela signifie que vous n'obtenez pas le changement interactif par retour d'informations si essentiel pour créer rapidement de nouveaux flux ou pour corriger ou améliorer de manière sûre et efficace les flux de données existants.
2) Provenance des données
La capacité unique de NiFi est sa capacité à générer des détails de traçabilité fins et puissants pour l’origine de vos données, ce qui leur est fait, où elles sont envoyées et à quel moment dans le flux. Cela est essentiel pour une gestion efficace des flux de données pour un certain nombre de raisons, mais pour les débutants de l'exploration et le travail sur un projet, le plus important, c'est la flexibilité de débogage impressionnante. Vous pouvez configurer vos flux et laisser les choses se dérouler, puis utiliser la provenance pour prouver qu’il a fait exactement ce que vous vouliez. Si quelque chose ne s'est pas passé comme prévu, vous pouvez corriger le flux et rejouer l'objet, puis recommencez. Très utile.
3) Référentiels de données spécialement conçus
L’expérience clé en main de NiFi offre des performances très puissantes même sur des environnements matériels ou virtuels très modestes. Cela est dû à la conception du fichier de flux et du référentiel de contenu qui nous confère la haute performance mais la sémantique transactionnelle que nous souhaitons car les données se frayent un chemin dans le flux. Le référentiel de fichier flowfile est une simple implémentation de journal à écriture anticipée et le référentiel de contenu fournit un magasin de contenu versionné immuable. Cela signifie que nous pouvons "copier" des données en ajoutant seulement un nouveau pointeur (sans copier réellement des octets) ou en transformant des données simplement en lisant l'original et en écrivant une nouvelle version. Encore une fois très efficace. Ajoutez à cela les éléments de provenance que j'ai mentionnés il y a un instant et cela fournit simplement une plate-forme vraiment puissante. Une autre chose vraiment importante à comprendre ici est que dans le secteur de la connexion de systèmes, il n’est pas toujours possible de dicter des choses telles que la taille des données impliquées. L'API NiFi a été conçue pour tenir compte de ce fait. Elle permet donc aux processeurs de recevoir, transformer et envoyer des données sans avoir à charger tous les objets en mémoire. Ces référentiels signifient également que dans la plupart des flux, la majorité des processeurs ne touchent même pas le contenu. Cependant, l'interface utilisateur de NiFi vous permet de voir avec précision le nombre d'octets lus ou écrits réellement. Vous obtenez ainsi des informations très utiles pour établir et observer vos flux. Cette conception signifie également que NiFi peut prendre en charge naturellement la contre-pression et la libération de pression. Il s’agit là de fonctionnalités vraiment essentielles pour un système de gestion de flux de données.
Les membres de la société Streamsets ont déjà mentionné que NiFi est orienté fichier. Je ne sais pas trop quelle est la différence entre un fichier, un enregistrement, un tuple, un objet ou un message en termes génériques, mais la réalité est que, lorsque des données se trouvent dans le flux, il s’agit là d’une chose à gérer. livré'. C'est ce que fait NiFi. Qu'il s'agisse de petites choses très rapides ou de grandes choses, qu'elles proviennent d'un flux audio en direct provenant d'Internet ou d'un fichier stocké sur votre disque dur, cela n'a pas d'importance. Une fois qu'il est dans le flux, il est temps de le gérer et de le livrer. C'est ce que fait NiFi.
La société Streamsets a également mentionné que NiFi est sans schème. Il est exact que NiFi ne force pas la conversion des données de ce qu’elles sont à l’origine en un format spécial NiFi, pas plus que nous n’avons à les reconvertir en un autre format pour une livraison ultérieure. Ce serait assez malheureux si nous faisions cela, car cela signifie que même les cas les plus triviaux auraient des implications problématiques en termes de performances et heureusement, NiFi n'a pas ce problème. Si nous avions suivi cette voie, cela signifierait qu'il serait difficile de gérer divers ensembles de données tels que les médias (images, vidéo, audio, etc.), mais nous sommes sur la bonne voie et NiFi est utilisé pour des choses de ce genre tout le temps.
Enfin, au fur et à mesure que vous poursuivez votre projet et que vous trouvez certaines choses que vous aimeriez voir améliorées ou que vous aimeriez apporter du code, nous aimerions beaucoup votre aide. De https://nifi.Apache.org , vous pouvez trouver rapidement des informations sur la manière de classer des tickets, de soumettre des correctifs, d'envoyer la liste de diffusion par courrier électronique, etc.
Voici quelques projets NiFi récents amusants à régler: https://www.linkedin.com/Pulse/nifi-ocr-using-Apache-read-childrens-books-jeremy-dyer - https://Twitter.com/KayLerch/status/721455415456882689
Bonne chance pour le projet de classe! Si vous avez des questions, la liste de diffusion [email protected] sera ravie de vous aider.
Merci Joe
Apache NiFi et StreamSets Data Collector sont des outils Open Source sous licence Apache.
Hortonworks propose une variante du commerce appelée Hortonworks DataFlow (HDF).
Bien que les deux présentent de nombreuses similitudes, comme une interface utilisateur Web, elles sont toutes deux utilisées pour l’intégration de données, mais il existe quelques différences essentielles. Ils sont également tous deux constitués de processeurs reliés entre eux pour effectuer des transformations, une sérialisation, etc.
Les processeurs NiFi sont orientés fichiers et sans schéma. Cela signifie qu'un élément de données est représenté par un fichier FlowFile (il peut s'agir d'un fichier réel sur le disque ou de quelques objets de données acquis ailleurs). Chaque processeur est responsable de la compréhension du contenu des données afin de les exploiter. Ainsi, si un processeur comprend le format A et qu'un autre ne comprend que le format B, vous devrez peut-être effectuer une conversion de format de données entre ces deux processeurs.
NiFi peut être exécuté de manière autonome ou en tant que cluster en utilisant son propre système de clustering intégré.
StreamSets Data Collector (SDC) adopte toutefois une approche basée sur l'enregistrement. Cela signifie que, lorsque les données entrent dans votre pipeline, elles sont analysées dans un format commun, de sorte que la responsabilité de la compréhension du format de données ne soit plus attribuée à chaque processeur individuel et que tout processeur puisse être connecté. à tout autre processeur.
Le SDC fonctionne également de manière autonome et en mode cluster, mais il fonctionne à la place sur Spark sur YARN/Mesos à la place, exploitant ainsi les ressources de cluster existantes que vous pourriez avoir.
NiFi existe depuis environ 10 ans (mais moins de 2 ans dans la communauté open source).
StreamSets a été publié par la communauté open source un peu plus tard en 2015. Il est agnostique vis-à-vis des fournisseurs et, dans la mesure où Hadoop s'en va, Hortonworks, Cloudera et MapR sont tous pris en charge.
Divulgation complète: Je suis un ingénieur qui travaille sur StreamSets.
Ils sont très similaires pour les scénarios d'acquisition de données. Apache NIFI (HDP) est plus mature et StreamSets est plus léger. Les deux sont faciles à utiliser, les deux ont une forte capacité. Et StreamSets pourrait facilement Ils ont des entreprises derrière, Hortonworks et Cloudera.
Évidemment, il y a plus de contributeurs travaillant sur NIFI que StreamSets. Bien entendu, NIFI a davantage de déploiements d'entreprise en production.
Deux des différenciateurs clés entre les deux IMHO sont.
Apache NiFi est un projet Apache de niveau supérieur, ce qui signifie qu'il a suivi le processus d'incubation décrit ici, http://incubator.Apache.org/policy/process.html , et peut accepter les contributions de développeurs autour le monde qui suit le processus standard Apache qui assure la qualité logicielle. StreamSets, est Apache LICENSED, ce qui signifie que tout le monde peut réutiliser le code, etc. Mais le projet n'est pas géré comme un projet Apache. En fait, pour pouvoir contribuer à Streamsets, il vous est demandé de signer un contrat. https://streamsets.com/contributing/ . Comparez cela au guide du contributeur Apache NiFi, qui n’a pas été écrit par un avocat. https://cwiki.Apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-HowtocontributetoApacheNiFi
StreamSets "s'exécute à la place de Spark sur YARN/Mesos, en exploitant les ressources de cluster existantes dont vous disposez". Ce qui impose un peu de restriction si vous souhaitez déployer vos flux de données plus loin vers Apache MiniFi, un sous-projet de NiFi peut être exécuté sur un seul Raspberry Pi, alors que je suis assez confiant que StreamSets ne le peut pas, YARN ou Mesos nécessitant plus de ressources qu'un Raspberry Pi.
Divulgation: Je suis un employé de Hortonworks