Lexique Big Data

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).