Le Big Data est aujourd’hui bien ancré dans le paysage des systèmes d’information. Avec eux vient un vocabulaire riche qu’il est parfois dur de maîtriser, en particulier pour les non érudits. Mathieu nous propose de faire le point sur certains des éléments de langage importants pour les administrateurs Big Data … et les autres !!!
Hadoop, HDFS, Yarn, Namenode, MapReduce, Datalake, HDP, Cloudera, Spark que veulent ils dirent ? à quoi font-ils référence ?
Vous avez entendu ou lu un de ces termes récemment lors d’une mission ou dans un appel d’offres lié au Big Data ?
Vous aimeriez une brève description d’un composant précis ?
Vous aimeriez comprendre le rôle d’un serveur dans une infrastructure Big Data ?
L’éco-système Big Data
Depuis maintenant plus de 10 ans, l’univers du Big Data a conquis une multitude d’organismes, d’entreprises et de systèmes d’information.
Cet univers s’est construit autour d’une philosophie (celle du traitement de la donnée) mais également à travers de multiples applications, frameworks et nouveaux concepts.
Ces éditeurs proposent aux entreprises des distributions (ou plate-formes ou encore stack) clés-en-main construites autour d’un framework open-source appelé Hadoop, spécialisé dans le traitement et la donnée distribuée.
A ces distributions sont rajoutés des outils tierces (open-source ou non) afin de compléter l’offre de service (streaming, restitution, Business Intelligence…) et pouvoir créer un système d’information complet.
Quelques précisions
Dans un premier temps, il est important de préciser que ce lexique est très orienté HDP (une des plate-formes de l’éditeur Hortonworks) et mettra peut-être en évidence seulement des outils propres à cette distribution.
En outre, le but de ce lexique est de résumer et parfois vulgariser certaines notions. Je suis à votre disposition si besoin d’informations plus exhaustives.
Enfin, ce lexique est vivant et toute suggestion de modification est la bienvenue.
Le lexique n’a pas de notion d’ordre, les termes décrits sont rangés aléatoirement
Lexique
Big Data
Concept illustrant le traitement de données massives qui dépasse les outils de gestion de données classiques.
Le concept est souvent rattaché aux “3V” mentionnés dans un rapport de Gartner portant sur la croissance des données : Volume / Variété / Vélocité.
Hadoop
Framework libre et open-source écrit en Java.
Hadoop naquit dans le cadre du projet Nutch dont le but était de construire un moteur de recherche open-source. Les développeurs (dont un des principaux intervenants était Doug Cutting, souvent cité comme le créateur d’Hadoop) rencontraient des problèmes dans la gestion de calculs distribués sur plusieurs serveurs. Suite à plusieurs articles publiés par Google en 2003 et 2004, les développeurs mirent au point HDFS et MapReduce qui constituèrent ensuite, en 2006, le framework Hadoop.
Hortonworks
Société créée en 2011 et basée en Californie. Son activité principale est liée au développement et soutien d’Hadoop. Elle propose plusieurs plateformes (ou distributions) se basant sur ce framework.
Hortonworks Data Platform (HDP)
Principale plate-forme proposée par l’éditeur Hortonworks. Cette plate-forme est basée sur le framework Hadoop et embarque une multitude de composants dédiés au traitement de la donnée.
Hortonworks DataFlow (HDF)
Autre plate-forme proposée par Hortonworks et dédiée au traitement de la donnée en temps réel. Se base sur des composants de streaming et également sur Nifi pour proposer aux opérateurs une méthode graphique de construction de flux.
Cloudera
Autre entreprise , fondée en 2008, dont l’activité est également liée au développement d’Hadoop. En 2018, Hortonworks et Cloudera annoncent la fusion de leurs activités.
Mapr
Autre acteur du marché Big Data proposant également une distribution homonyme construite autour du framework Hadoop.
MapReduce
Modèle de programmation créé par Google et optimisé pour le traitement de données volumineuses. Ce patron utilise le principe de Map -> Shuffle -> Reduce afin de traiter de manière parallèle et distribuée des jeux de données importants.
Un traitement MapReduce appelé sur un cluster Hadoop sera divisé en X jobs (X tâches Map + X tâches Reduce). Les tâches seront ordonnancées ensuite par le Ressource Manager (Yarn en l’occurrence) qui distribuera celles-ci sur les noeuds du cluster.
MapReduce a depuis été supplanté par le moteur de calculs Spark.
Datalake
Appelé également lac de données en français. Considéré conceptuellement comme un repository de données non structurées se prêtant aux analyses de données prédictives, au Machine Learning et autres traitements modernes de la donnée. Le framework Hadoop va utiliser le composant HDFS pour la création d’un lac de données et le stockage de fichiers volumineux.
Hadoop Distributed File System (HDFS)
Constitue avec Yarn la base du socle Hadoop et assure la distribution de la donnée sur les noeuds d’un cluster Hadoop. HDFS est un système de fichiers se reposant sur l’agrégation de X disques afin de fournir un seul et même système de fichiers. Ce système peut être vu comme une sur-couche se basant sur un système de fichiers classique (ext4, zfs…) et utilisant sa propre unité (bloc HDFS) pour le stockage de fichiers. L’architecture HDFS standard est composée d’un serveur Namenode et de plusieurs serveurs Datanode.
Namenode
Composant principal d’un socle HDFS, considéré comme un Master. Ce serveur contient l’intégralité de l’arbre des fichiers présents sur HDFS. Il contient également l’intégralité des metadata de ces fichiers. Le serveur Namenode est considéré comme vital dans une architecture HDFS et est souvent répliqué en 2 serveurs (Active / Standby) afin de se prémunir de toute interruption de service en cas de panne matérielle.
Datanode
Considéré comme un Worker dans une architecture HDFS. Il a pour rôle de fournir les blocs de fichiers aux Namenode ou aux clients directement. Il indique également aux Namenode la localisation des blocs de fichiers qu’il contient.
Bloc (HDFS)
Ce concept de bloc propre à HDFS est différent de la notion de bloc au niveau du système de fichiers hébergeant la distribution Hadoop. Par défaut, la taille d’un bloc HDFS est de 128Mo (valeur optimale par rapport au ratio temps de parcours du disque / temps de transfert de la donnée). L’utilisation d’un bloc propre à HDFS a plusieurs avantages : pouvoir stocker des fichiers dépassant la taille d’un disque, dissocier la donnée brute et la partie metadata (optimale pour le traitement de la donnée) ou encore faciliter la réplication des données et assurer donc une protection maximum contre la panne matérielle.
Spark
Moteur de calcul, considéré comme une évolution du modèle MapReduce du fait de son gain en performances. A la différence de MapReduce qui va écrire des fichiers sur disque à chacune de ses étapes (Map / Shuffle / Reduce), Spark va réaliser ses tâches d’analyse de la donnée en mémoire et en temps réel. Spark a été initialement développé en Scala.
Yet Another Resource Negociator (YARN)
Constitue avec HDFS la base du socle Hadoop et assure la distribution des traitements sur les noeuds d’un cluster Hadoop. Historiquement, MapReduce dans sa première version utilisait un moteur interne (jobtracker & tasktracker) pour gérer la partie distribuée de son traitement. Dans sa version 2, cette gestion de la distribution du traitement a été déportée vers un composant nommé Yarn.
A l’identique d’HDFS qui utilise une architecture de type Master -> Worker, Yarn va utiliser sa propre architecture pour assurer de façon optimale la distribution des traitements : ResourceManager & NodeManager.
ResourceManager
Composant Master d’une architecture Yarn.
Le composant ResourceManager est en contact direct avec le client souhaitant lancer un traitement distribué sur le Cluster Hadoop. Le client va demander l’exécution d’un process ApplicationMaster et le ResourceManager aura pour tâche de trouver un NodeManager disponible pour en lancer un. Ce process exécutera ensuite soit un traitement unitaire sur le NodeManager sur lequel il se situe soit demandera l’allocation de containers supplémentaires aux autres NodeManager disponibles.
NodeManager
Composant Worker d’une architecture Yarn. Le NodeManager est en lien avec le ResourceManager et peut être appelé par ce dernier pour allouer et lancer des containers selon des contraintes définies par le client (processeur, mémoire vive).
Aller plus loin :
Découvrez notre Glossaire Big Data , à télécharger gratuitement.
Vos commentaires
Mise en bouche très intéressante, hâte de lire la partie 2 qui rentrera un peu plus dans le détail.