Hadoop, Storm, Samza, Spark et Flink: Comparaison des cadres de données volumineuses

La fonctionnalité de traitement de Hadoop provient du moteur MapReduce. La technique de traitement de MapReduce suit la carte, mélange, réduit l’algorithme à l’aide de paires clé-valeur. La procédure de base implique:

Étant donné que cette méthodologie s’appuie fortement sur le stockage permanent, la lecture et l’écriture plusieurs fois par tâche, elle a tendance à être assez lente. D’autre part, l’espace disque étant généralement l’une des ressources de serveur les plus abondantes, cela signifie que MapReduce peut gérer d’énormes jeux de données. Cela signifie également que MapReduce de Hadoop peut généralement fonctionner sur du matériel moins coûteux que certaines solutions de remplacement, car il ne tente pas de tout stocker en mémoire. MapReduce a un potentiel d’évolutivité incroyable et a été utilisé en production sur des dizaines de milliers de nœuds.

En tant que cible de développement, MapReduce est connu pour sa courbe d’apprentissage plutôt abrupte. D’autres ajouts à l’écosystème Hadoop peuvent en réduire l’impact à divers degrés, mais cela peut néanmoins contribuer à la mise en œuvre rapide d’une idée sur un cluster Hadoop.

Hadoop possède un écosystème étendu, le cluster Hadoop lui-même étant fréquemment utilisé comme bloc de construction pour d’autres logiciels. De nombreux autres frameworks et moteurs de traitement ont des intégrations Hadoop pour utiliser HDFS et le gestionnaire de ressources YARN.

Apache Hadoop et son moteur de traitement MapReduce offrent un modèle de traitement par lots éprouvé qui convient le mieux pour la gestion de très grands ensembles de données où le temps n’est pas un facteur important. Le faible coût des composants nécessaires au bon fonctionnement d’un cluster Hadoop rend ce traitement peu coûteux et efficace dans de nombreux cas d’utilisation. La compatibilité et l’intégration avec d’autres frameworks et moteurs signifient que Hadoop peut souvent servir de base à de multiples charges de travail de traitement utilisant différentes technologies.

Le traitement du flux Storm fonctionne en orchestrant les DAG (Directed Acyclic Graphs) dans un cadre appelé * topologies *. Ces topologies décrivent les différentes transformations ou étapes à suivre pour chaque donnée entrante lors de son entrée dans le système.

Les topologies sont composées de:

Storm a pour principe de définir de petites opérations discrètes à l’aide des composants ci-dessus, puis de les composer en une topologie. Par défaut, Storm offre au moins une fois des garanties de traitement, ce qui signifie qu’il peut garantir que chaque message est traité au moins une fois, mais il peut y avoir des doublons dans certains scénarios d’échec. Storm ne garantit pas que les messages seront traités dans l’ordre.

Une abstraction appelée * Trident * est également disponible pour obtenir un traitement avec une seule et unique condition. Pour être explicite, Storm without Trident est souvent appelé * Core Storm *. Trident modifie considérablement la dynamique de traitement de Storm, augmentant la latence, ajoutant un état au traitement et mettant en œuvre un modèle de micro-traitement au lieu d’un système de diffusion en continu élément par article.

Les utilisateurs de Storm recommandent généralement d’utiliser Core Storm chaque fois que possible pour éviter ces pénalités. Dans cet esprit, la garantie de Trident de traiter les éléments une seule fois est utile dans les cas où le système ne peut pas gérer intelligemment les messages en double. Trident est également le seul choix possible dans Storm lorsque vous devez conserver l’état entre les éléments, par exemple lorsque vous comptez le nombre d’utilisateurs qui cliquent sur un lien en une heure. Trident donne à Storm la flexibilité, même si elle ne joue pas avec les atouts naturels du framework.

Les topologies Trident sont composées de:

Storm est probablement la meilleure solution actuellement disponible pour le traitement en temps quasi réel. Il est capable de gérer des données avec une latence extrêmement faible pour les charges de travail devant être traitées avec un délai minimal. Storm est souvent un bon choix lorsque le temps de traitement affecte directement l’expérience utilisateur, par exemple lorsque les retours du traitement sont directement renvoyés à la page d’un visiteur sur un site Web.

Storm avec Trident vous offre la possibilité d’utiliser des micro-lots au lieu du traitement en flux pur. Bien que cela donne aux utilisateurs une plus grande souplesse pour adapter l’outil à l’usage auquel il est destiné, cela tend également à annuler certains des principaux avantages du logiciel par rapport à d’autres solutions. Cela étant dit, le choix du style de traitement du flux reste utile.

Core Storm n’offre pas de garantie de commande des messages. Core Storm offre au moins une fois des garanties de traitement, ce qui signifie que le traitement de chaque message peut être garanti mais que des doublons peuvent se produire. Trident offre des garanties ponctuelles et peut effectuer des commandes entre lots, mais pas à l’intérieur.

En termes d’interopérabilité, Storm peut s’intégrer au négociateur de ressources YARN de Hadoop, facilitant ainsi le raccordement à un déploiement Hadoop existant. Plus que la plupart des infrastructures de traitement, Storm offre une prise en charge linguistique très étendue, offrant aux utilisateurs de nombreuses options pour la définition des topologies.

Pour les charges de travail de traitement de flux pur avec des exigences de latence très strictes, Storm est probablement la meilleure option mature. Il peut garantir le traitement des messages et peut être utilisé avec un grand nombre de langages de programmation. Comme Storm n’effectue pas de traitement par lots, vous devrez utiliser un logiciel supplémentaire si vous avez besoin de ces fonctionnalités. Si vous avez besoin de garanties de traitement en une seule fois, Trident peut vous le fournir. Cependant, d’autres cadres de traitement de flux pourraient également convenir mieux à ce stade.

Samza s’appuie sur la sémantique de Kafka pour définir la manière dont les flux sont gérés. Kafka utilise les concepts suivants pour traiter des données:

Comme Kafka est un journal immuable, Samza traite les flux immuables. Cela signifie que toutes les transformations créent de nouveaux flux consommés par d’autres composants sans affecter le flux initial.

La dépendance de Samza sur un système de file d’attente semblable à celui de Kafka peut sembler restrictive à première vue. Cependant, il offre au système des garanties et des fonctionnalités uniques qui ne sont pas communes aux autres systèmes de traitement de flux.

Par exemple, Kafka offre déjà un stockage répliqué de données accessibles avec un faible temps de latence. Il fournit également un modèle multi-abonné très simple et peu coûteux à chaque partition de données. Toutes les sorties, y compris les résultats intermédiaires, sont également écrites en Kafka et peuvent être consommées indépendamment par les étapes en aval.

À bien des égards, cette dépendance étroite à Kafka reflète la manière dont le moteur MapReduce fait fréquemment référence à HDFS. Bien que le référencement de HDFS entre chaque calcul entraîne de sérieux problèmes de performances lors du traitement par lots, il résout un certain nombre de problèmes lors du traitement en flux.

La forte relation de Samza avec Kafka permet aux étapes de traitement d’être liées très vaguement. Un nombre arbitraire d’abonnés peut être ajouté à la sortie de n’importe quelle étape sans coordination préalable. Cela peut être très utile pour les organisations où plusieurs équipes peuvent avoir besoin d’accéder à des données similaires. Les équipes peuvent toutes s’abonner au sujet des données entrant dans le système ou s’abonner facilement à des sujets créés par d’autres équipes ayant subi un traitement. Cela peut être fait sans alourdir davantage les infrastructures sensibles à la charge telles que les bases de données.

Écrire directement à Kafka élimine également les problèmes de * contrepression *. La contre-pression se produit lorsque les pics de charge entraînent un afflux de données à un taux supérieur à celui que les composants peuvent traiter en temps réel, ce qui entraîne des blocages de traitement et éventuellement une perte de données. Kafka est conçu pour conserver les données pendant de très longues périodes, ce qui signifie que les composants peuvent être traités à leur convenance et peuvent être redémarrés sans conséquence.

Samza est capable de stocker l’état en utilisant un système de point de contrôle tolérant aux pannes implémenté en tant que magasin clé-valeur local. Cela permet à Samza d’offrir une garantie de livraison au moins une fois, mais elle ne permet pas une récupération précise de l’état agrégé (comme des comptages) en cas de défaillance, car les données peuvent être livrées plusieurs fois.

Samza propose des abstractions de haut niveau qui sont, à bien des égards, plus faciles à utiliser que les primitives fournies par des systèmes tels que Storm. Samza ne prend actuellement en charge que les langues JVM, ce qui signifie qu’elle n’a pas la même souplesse linguistique que Storm.

Apache Samza est un bon choix pour la diffusion en continu de charges de travail où Hadoop et Kafka sont déjà disponibles ou qu’il est judicieux de mettre en œuvre. Samza lui-même convient parfaitement aux organisations composées de plusieurs équipes utilisant (sans nécessairement coordonner étroitement) les flux de données à différentes étapes du traitement. Samza simplifie grandement de nombreuses étapes du traitement de flux et offre des performances de faible latence. Cela peut ne pas convenir si les exigences de déploiement ne sont pas compatibles avec votre système actuel, si vous avez besoin d’un traitement à latence extrêmement faible ou si vous avez des besoins importants en sémantique unique.

Contrairement à MapReduce, Spark traite toutes les données en mémoire, n’interagissant qu’avec la couche de stockage pour charger initialement les données en mémoire et, à la fin, pour conserver les résultats finaux. Tous les résultats intermédiaires sont gérés en mémoire.

Bien que le traitement en mémoire contribue considérablement à la rapidité, Spark accélère également les tâches liées aux disques grâce à une optimisation globale pouvant être obtenue en analysant à l’avance l’ensemble complet des tâches. Pour ce faire, il crée des graphiques acycliques dirigés, ou * DAG *, qui représentent toutes les opérations à effectuer, les données à exploiter ainsi que les relations entre elles, ce qui permet au processeur de coordonner plus efficacement le travail.

Pour mettre en œuvre le calcul par lots en mémoire, Spark utilise un modèle appelé Jeu de données distribuées résilient, ou * RDD *, pour gérer les données. Ce sont des structures immuables existant dans la mémoire qui représentent des collections de données. Les opérations sur les RDD produisent de nouveaux RDD. Chaque RDD peut retracer sa lignée par le biais de ses RDD parents et finalement vers les données sur le disque. Les RDD sont essentiellement un moyen pour Spark de conserver la tolérance de panne sans avoir à écrire sur le disque après chaque opération.

Les capacités de traitement de flux sont fournies par Spark Streaming. Spark lui-même est conçu pour des charges de travail axées sur les lots. Pour faire face à la disparité entre la conception du moteur et les caractéristiques des charges de travail en streaming, Spark met en œuvre un concept appelé micro-batchs *. Cette stratégie est conçue pour traiter les flux de données comme une série de très petits lots pouvant être gérés à l’aide de la sémantique native du moteur de traitement par lots.

Spark Streaming fonctionne en tamponnant le flux par incréments de moins d’une seconde. Ceux-ci sont envoyés en tant que petits ensembles de données fixes pour le traitement par lots. En pratique, cela fonctionne assez bien, mais cela conduit à un profil de performance différent de celui des infrastructures de traitement de flux véritables.

La raison évidente d’utiliser Spark sur Hadoop MapReduce est la vitesse. Spark peut traiter les mêmes ensembles de données beaucoup plus rapidement en raison de sa stratégie de calcul en mémoire et de sa planification avancée des DAG.

Un autre avantage majeur de Spark est sa polyvalence. Il peut être déployé en tant que cluster autonome ou intégré à un cluster Hadoop existant. Il peut effectuer un traitement par lots et par flux, vous permettant d’exploiter un seul cluster pour gérer plusieurs styles de traitement.

Au-delà des capacités du moteur lui-même, Spark dispose également d’un écosystème de bibliothèques pouvant être utilisées pour l’apprentissage automatique, les requêtes interactives, etc. Il est presque universellement reconnu que les tâches Spark sont plus faciles à écrire que MapReduce, ce qui peut avoir des conséquences importantes pour la productivité.

L’adaptation de la méthodologie de traitement par lots au traitement de flux implique la mise en mémoire tampon des données au moment de leur entrée dans le système. La mémoire tampon lui permet de gérer un volume élevé de données entrantes, ce qui augmente le débit global, mais attendre de vider la mémoire tampon entraîne également une augmentation significative de la latence. Cela signifie que Spark Streaming peut ne pas être approprié pour le traitement où une faible latence est impérative.

Étant donné que la RAM coûte généralement plus cher que l’espace disque, l’exécution de Spark est plus onéreuse que celle de systèmes basés sur disque. Cependant, la vitesse de traitement accrue signifie que les tâches peuvent être exécutées beaucoup plus rapidement, ce qui peut compenser complètement les coûts lorsque vous travaillez dans un environnement où vous payez les ressources à l’heure.

Une autre conséquence de la conception en mémoire de Spark est que la rareté des ressources peut être un problème lors du déploiement sur des clusters partagés. Par rapport à MapReduce de Hadoop, Spark utilise beaucoup plus de ressources, ce qui peut interférer avec d’autres tâches susceptibles de tenter d’utiliser le cluster à ce moment-là. En substance, Spark pourrait être un voisin moins prévenant que d’autres composants pouvant fonctionner sur la pile Hadoop.

Spark est une excellente option pour ceux qui ont diverses charges de traitement. Le traitement par lots Spark offre d’incroyables avantages en termes de vitesse et de consommation de mémoire. Spark Streaming est une bonne solution de traitement de flux pour les charges de travail qui valorisent le débit sur la latence.

Le modèle de traitement de flux de Flink traite les données entrantes élément par élément comme un véritable flux. Flink fournit son API DataStream pour travailler avec des flux de données non liés. Les composants de base avec lesquels Flink fonctionne sont:

Les tâches de traitement de flux prennent des instantanés à des points définis pendant leur calcul pour les utiliser en cas de problèmes. Pour stocker l’état, Flink peut fonctionner avec un certain nombre d’arrière-plans d’états en fonction de niveaux de complexité et de persistance variables.

De plus, le traitement de flux de Flink est capable de comprendre le concept de «temps d’événement», c’est-à-dire l’heure à laquelle l’événement s’est réellement produit, et peut également gérer des sessions. Cela signifie qu’il peut garantir l’ordre et le regroupement de certaines manières intéressantes.

Le modèle de traitement par lots de Flink n’est à bien des égards qu’une extension du modèle de traitement des flux. Au lieu de lire à partir d’un flux continu, il lit un ensemble de données limité à partir d’un stockage persistant en tant que flux. Flink utilise exactement le même temps d’exécution pour ces deux modèles de traitement.

Flink offre certaines optimisations pour les charges de travail par lots. Par exemple, étant donné que les opérations par lots sont sauvegardées par un stockage persistant, Flink supprime les instantanés des charges par lots. Les données sont toujours récupérables, mais le traitement normal se termine plus rapidement.

Une autre optimisation consiste à scinder les tâches par lots afin que les étapes et les composants ne soient impliqués qu’en cas de besoin. Cela aide Flink à bien jouer avec les autres utilisateurs du cluster. Une analyse préventive des tâches permet à Flink d’optimiser également en visualisant l’ensemble des opérations, la taille de l’ensemble de données et les exigences des étapes à venir.

Flink est actuellement une option unique dans le monde du framework de traitement. Bien que Spark effectue un traitement par lots et par flux, sa diffusion en continu ne convient pas à de nombreux cas d’utilisation en raison de son architecture micro-batch. L’approche «Flood first» de Flink offre une faible latence, un débit élevé et un traitement réel entrée par entrée.

Flink gère beaucoup de choses par lui-même. De manière quelque peu non conventionnelle, il gère sa propre mémoire au lieu de s’appuyer sur les mécanismes de récupération de place Java natifs pour des raisons de performances. Contrairement à Spark, Flink ne nécessite pas d’optimisation manuelle ni d’ajustement lorsque les caractéristiques des données qu’il traite changent. Il gère également le partitionnement et la mise en cache des données.

Flink analyse son travail et optimise ses tâches de plusieurs manières. Une partie de cette analyse est similaire à celle effectuée par les planificateurs de requêtes SQL dans les bases de données relationnelles, en définissant le moyen le plus efficace d’implémenter une tâche donnée. Il est capable de mettre en parallèle des étapes pouvant être complétées en parallèle, tout en rassemblant des données pour des tâches bloquantes. Pour les tâches itératives, Flink tente d’effectuer un calcul sur les nœuds où les données sont stockées pour des raisons de performances. Il peut également effectuer une «itération delta» ou une itération uniquement sur les parties de données modifiées.

En termes d’outillage utilisateur, Flink offre une vue de planification Web permettant de gérer facilement les tâches et d’afficher le système. Les utilisateurs peuvent également afficher le plan d’optimisation des tâches soumises pour voir comment il sera réellement implémenté sur le cluster. Pour les tâches d’analyse, Flink propose des bibliothèques de requêtes, de traitement de graphes et d’apprentissage automatique de type SQL, ainsi que des calculs en mémoire.

Flink fonctionne bien avec d’autres composants. Il est écrit comme étant un bon voisin s’il est utilisé dans une pile Hadoop, n’utilisant que les ressources nécessaires à un moment donné. Il s’intègre facilement à YARN, HDFS et Kafka. Flink peut exécuter des tâches écrites pour d’autres infrastructures de traitement telles que Hadoop et Storm avec des packages de compatibilité.

L’un des plus gros inconvénients de Flink à l’heure actuelle est qu’il s’agit d’un projet encore très jeune. Les déploiements à grande échelle dans la nature ne sont toujours pas aussi courants que d’autres cadres de traitement et il n’ya pas eu beaucoup de recherche sur les limites de Flink en matière d’échelle. Avec le cycle de développement rapide et des fonctionnalités telles que les packages de compatibilité, les déploiements de Flink peuvent commencer à se multiplier à mesure que les entreprises ont la possibilité de les expérimenter.

Flink offre à la fois un traitement de flux à faible latence et une prise en charge des tâches par lots traditionnelles. Flink est probablement mieux adapté aux organisations qui ont de grandes exigences en matière de traitement de flux et certaines tâches orientées lot. Sa compatibilité avec les programmes natifs de Storm et Hadoop et sa capacité à s’exécuter sur un cluster géré par YARN peuvent être facilement évalués. Son développement rapide mérite d’être surveillé.