HADOOP
III.1- Introduction :
Hadoop est un environnement d’exécution distribué, performant et scalable, dont la vocation est de traiter des volumes de données considérables. Parce que ce système est de portée générale, il a suscité le développement d’un vaste écosystème constitué d’autres projets spécialisés dans un domaine particulier parmi lesquels on compte les entrepôts de données (data warehouse), le décisionnel (business intelligence), le suivi applicatif (monitoring) ou la persistance de données.
Dans ce chapitre, je définirais les principales fonctions de chaque sous-projet d’Hadoop ainsi que leurs logiques de travail.
Figure III.1 : L’écosystème d’Hadoop.
III.2- Pourquoi Hadoop ?
Ce qui fait la spécificité de Hadoop est qu’il est conçu pour traiter un énorme volume de données en un temps record. A titre d’exemple, les labs de Yahoo! ont trié l’équivalent de 500 GB de données en 59 secondes sur un cluster de 1400 nœuds (Avril 2009).
Sa vocation première est donc d’implémenter des traitements batchs performants, particulièrement lorsqu’ils impliquent un volume de données très important. En dehors de Yahoo!, citons les cas d’utilisation de deux sociétés prestigieuses :
ð La plateforme musicale Last.fm met en œuvre Hadoop pour générer les statistiques hebdomadaires (Tops artistes et Top titres) ou mesurer les tendances musicales.
ð Facebook l’utilise pour la production de rapports à usage interne, comme la performance des campagnes publicitaires opérées par la plateforme sociale, ou des statistiques diverses (croissance du nombre des utilisateurs, consultation des pages, temps moyen de consultation du site, etc.) [BIC]
III.3- Architecture Et Fonctionnement :
III.3.1- MapReduce :
MapReduce est un paradigme de programmation distribuée introduit par Google (à l’occasion de la publication d’une note) pour traiter de très gros volumes de données. [BIC]
Il consiste à découper le traitement en 2 phases :
ð Map : est une étape d’ingestion et de transformation des données sous la forme de paires clé/valeur.
ð Reduce : est une étape de fusion des enregistrements par clé pour former le résultat final.
Ainsi, et c’est un principe qui est au cœur de Hadoop, les données à traiter en entrée sont découpées en “petites” unités (64Mo par défaut), chacune étant traitée en parallèle par une fonction Map. Le résultat des traitements unitaires est trié par clé pour former des unités de données passées à une fonction Reduce. C’est parce-que les programmes MapReduce sont intrinsèquement prévu pour être exécutés en parallèle qu’il est possible de répartir le traitement. [TCB] [HDG]
Figure III.3 : Le processus Map/Reduce.
Un cas d’utilisation :
Pour illustrer l’algorithme MapReduce, considérons un jeu de données constitué des 3 phrases suivantes :
Le but de l’illustration est d’appliquer le modèle MapReduce afin de sortir le nombre d’occurrences des mots constituant le texte. L’ensemble du processus est schématisé ci-dessous :
Figure III.4 : Un cas d’utilisation Map/Reduce.
JobTracker et TaskTrackers :
Deux types de composants permettent de contrôler le processus d’exécution d’un job: un JobTracker et plusieurs TaskTrackers.
ð Le JobTracker : coordonne l’exécution des jobs sur l’ensemble du cluster. Il communique avec les TaskTrackers en leur attribuant des tâches d’exécution (map ou reduce).
Par ailleurs, il permet d’avoir une vision globale sur la progression ou l’état du traitement distribué via une console d’administration web.
Le JobTracker est un démon cohabitant avec le NameNode. Il n’y a donc qu’une instance par cluster. [BIC] [DYC]
ð TaskTrackers : exécutent les tâches (map ou reduce) au sein d’une nouvelle JVM (Java Virtual Machine) instanciée par le TaskTracker. Ainsi, un crash de la machine virtuelle n’impactera pas le TaskTracker.
Par ailleurs, ils notifient périodiquement le JobTracker du niveau de progression d’une tâche ou bien le notifient en cas d’erreur afin que celui-ci puissent reprogrammer et assigner une nouvelle tâche.
Un TaskTracker est un démon cohabitant avec un DataNode. Il y a donc autant d’instances que de nœuds esclaves. [BIC] [DYC]
La communication entre les nœuds (NameNode/DataNode, JobTracker/TaskTracker) s’effectue par RPC.
III.3.2- HDFS :
Quand un ensemble de données devient trop grand pour la capacité de stockage d'une seule machine physique, il devient nécessaire de le partitionner dans un certain nombre de machines séparées. Les systèmes de fichiers qui gèrent le stockage dans un réseau de machines sont appelés systèmes de fichiers distribués (DFS). Cependant, le fait de se baser sur une architecture répartie, nous expose à tous les problèmes de la programmation en réseau, rendant ainsi les systèmes de fichiers distribués plus complexe que les systèmes de fichiers d’un disque ordinaire. Par exemple l’un des plus grands défis qu’un système de fichiers distribués fait fasse est la tolérance qu’un lien casse sans perte de données. [HTDG] [DYC] [PRH]
Hadoop propose un système de fichiers distribué appelé HDFS (Hadoop Distributed Filesystem).
Figure III.5: l’architecture du HDFS.
ð Blocs : un disque a une longueur de bloc, qui représente la quantité minimum qui peut être lue ou écrite. Le système de fichier dans un disque simple traite la donnée en blocs, qui est un multiple intégral de la longueur d’un bloc du disque. Un bloc dans un système de fichier d’un disque simple est de quelques octets (512 octets). C’est généralement transparent aux utilisateurs.
HDFS a aussi le concept de blocs, les fichiers sont partitionnés sur plusieurs blocs et sont stockés en tant qu’unités indépendantes. Mais contrairement au système classique, les blocs dans le HDFS, sont beaucoup plus grands (par défaut 64Mo) et les fichiers, plus petits qu’un bloc HDFS, n’occupent pas tout le bloc.
Un cluster HDFS est basé sur le model Maitre-Esclave et, donc, a deux type de nœuds, NameNode (qui n’est d’autre que le Maitre) et certain nombre de DataNodes (qui représentent les esclaves). [HDG]
ð NameNode : est la véritable pierre angulaire du système de fichier. Il gère l’espace de nommage et l’arborescence du système de fichiers, les métadonnées (noms, permissions, etc.) des fichiers et répertoires. Il centralise la localisation des blocs de données répartis sur le système. Sans Namenode, tous les fichiers peuvent être considérés comme perdus car il n’y aurait alors aucun moyen de reconstituer les fichiers à partir des blocs.
Il n’y a qu’une instance de NameNode par cluster HDFS. L’historique des modifications dans le système de fichier est géré par une instance secondaire cohabitant en backup.
ð DataNodes : stockent et restituent les blocs de données. Par ailleurs, ils communiquent périodiquement au NameNode la liste des blocs qu’ils hébergent. L’écriture d’un bloc sur un DataNode peut être propagée en cascade par copie sur d’autres DataNodes.
Le processus de lecture d’un fichier sur HDFS commence par l’interrogation du NameNode afin de localiser les blocs sous-jacents. Pour chaque bloc, le NameNode renvoie l’adresse du DataNode le plus proche possédant une copie du bloc. L’unité de distance n’est autre que la bande passante disponible. Ainsi, plus la bande passante est importante entre un client et un DataNode, plus ce dernier est considéré comme proche.
Figure III.6 : Typologie d’un cluster Hadoop.
III.3.3- PIG :
Pig est un environnement de programmation fournissant aux développeurs un langage de haut niveau (Pig Latin) pour exprimer des traitements de données. Une fois un programme écrit, il peut être compilé et être exécuté sur un cluster Hadoop. Un de ses points forts est que sa structure est très facilement parallélisable, tout en laissant cet aspect de la programmation complètement transparent pour le développeur. Il simplifie aussi la vie du développeur en lui permettant de définir en un seul programme ce qui correspond à plusieurs itérations map-reduce.
La propriété remarquable des programmes de Pig, c'est que leur structure se prête à la parallélisation de fond, qui leur permet de traiter des ensembles de données très volumineux.
À l'heure actuelle, la couche d'infrastructure de Pig se compose d'un compilateur qui produit des séquences de programmes de Map-Reduce, pour laquelle les implémentations parallèles de grande envergure existent déjà. [HDG] [IMG]
III.3.4- HBase :
L’année 2009 a été marquée par la montée en puissance du mouvement NoSQL (Not Only SQL), une tendance réactionnaire, au sens premier du terme, visant à promouvoir des solutions de persistance agiles et non relationnelles répondant avant tout à l’exigence de scalabilité. A juste titre, les bases de données relationnelles sont considérées comme des points de contention majeurs des architectures web dont la vocation est d’être scalable.
HBase s’inscrivant dans cette mouvance et dont le design s’inspire de « BigTable » (la base de données distribuée de Google). Elle est capable de gérer des jeux de données extrêmement importants, de l’ordre de plusieurs TB. Son modèle d’accès est celui d’une table associative (Hashtable) fonctionnant par couples clé/valeur.
S’exécutant au dessus de Hadoop, les opérations de recherche, tri ou requête sont convertis en jobs Map/Reduce dont les jeux de données en entrée sont constitués par les enregistrements de la base.
HBase est une base de données distribuée orientée colonne. Elle permet une lecture / écriture en temps réel sur un ensemble de données très volumineux.
Bien qu'il existe d'innombrables stratégies mises en œuvre pour stockage et extraction de données dans les bases de données, la plus part ne peuvent pas être déployées sur une grande échelle et ne sont pas pensées, a la base, pour la distribution. [HDG] [DYC] [HBE]
Principe de stockage:
Les bases de données orientées colonnes sont organisées en familles de colonnes (column family). Ce type de regroupement se rapproche du concept de table dans une base de données relationnelle.
Bien qu'elles soient organisées en tables, leur disposition est totalement différente. Ainsi alors que les colonnes d'une base de données relationnelle sont statiques et présentes pour chaque ligne, celles d'une base de données orientée colonnes sont dynamiques et présentes uniquement pour les lignes concernées. En d'autres termes, il est possible d'ajouter des colonnes à une ligne à tout moment et le coût de stockage d'un nul est 0.
En fait, les bases de données orientées colonnes sont pensées pour accueillir un grand nombre de colonnes (jusqu'à plusieurs millions) pour chaque ligne. Dès lors on comprend qu'il ne s'agit plus simplement d'y stocker les champs d'une entité, mais également des relations one-to-many.
Les requêtes possibles sont simples. Il est possible de faire des requêtes par clé, ou ensemble de clés et d'y adjoindre un prédicat sur un intervalle de colonnes. Voici quelques exemples de requêtes possibles :
ð Toutes les colonnes de la ligne dont la clé est 12
ð Toutes les colonnes dont le nom est compris entre "aaa" et "abb" pour la ligne dont la clé est 156
ð La colonne "aaa" pour les lignes 26 à 31
On dispose donc d'un système de requêtes minimaliste qui a permis de grandement simplifier le design de ces bases de données, au profit de la performance.
HBase offre une extension à ce modèle en proposant des super-colonnes qui se comportent comme des conteneurs de colonnes. Ceci ajoute donc une dimension supplémentaire au modèle permettant par exemple le stockage de listes de listes:
Figure III.9 : Organisation des tables dans une BDD orientée colonnes avec super -colonnes.
Il est alors possible de faire des requêtes qui portent sur un nom ou sur un intervalle de noms de super-colonnes permettant ainsi d'obtenir en retour une liste de super-colonnes et tout leur contenu.
HBase offre la possibilité d'ajouter un index secondaire sur des colonnes ; ceci permet alors d'utiliser la valeur d'une colonne indexée dans les requêtes.
Le fait que les colonnes soient stockées de manière triée sur le disque est un choix important puisque cela permet d'obtenir un intervalle de colonnes (ou de super-colonnes) avec un nombre réduit d'accès aléatoires sur le disque. Il nécessite par contre de reconstruire l'ensemble de la table de données sur le disque au fur et à mesure des modifications, ce qui est mis en œuvre de manière efficace dans HBase. [DYC] [HDG] [BXF] [BSC] [HBE]
III.3.5- Zookeeper :
Zookeeper est un service de coordination des processus des applications réparties. Historiquement, les processus distribués étaient coordonnés par le biais des messages de groupe, un partage de registre ou un service de verrouillage.
Zookeeper incorpore des éléments de tous les serveurs du cluster, mais les intègre dans un service de réplication centralisé. L’interface exposée par Zookeeper intègre l'aspect wait-free de messagerie de groupe, partage de registres avec un mécanisme de concurrence similaire au service de verrouillage, afin d'offrir une simple et puissante coordination.
Zookeeper a comme principale fonction simplifier l'accès a la donnée en offrant un répertoire de classification des données existante sur le cluster. Dans un aspect totalement virtuel, Zookeeper ordonne (virtuellement) les données et les classifie dans des registres et enregistre leurs états et aussi l'état d'avancement des clients sur chaque donnée. De ce fait, même si un client, pour une raison ou une autre, se trouve dans l'obligation de changer de serveur (mais reste dans le même service) pourrait continuer son travail, sans pour cela refaire toutes les transactions et requêtes déjà effectuées sur un premier serveur. [HDG] [HAO] [ZKS]
Figure III.12 : Organisation de Zookeeper des Données.
III.3.6- Hive :
Hive est une infrastructure d'entrepôt de données qui fournit des outils pour permettre facilement d’avoir un résumé des données, l'interrogation adhoc et l'analyse de grands ensembles de données stockées dans des fichiers Hadoop. Il fournit un langage de requête simple appelé la ruche QL qui est basé sur SQL et qui permet aux utilisateurs familiers avec SQL d’interroger la base de donnés. Également, ce langage permet aux programmeurs traditionnels de Map/Reduce d'être en mesure de connecter leurs travaux avec la base de données. [HDG] [HAO]
III.3.7- Chukwa :
Chukwa est collectionneur d’informations qui fonctionne en stockant des données dans le système HDFS, et il utilise MapReduce pour produire des rapports. (Outil de Monitoring).
Chukwa vise à fournir une plate-forme puissante et flexible pour la collecte de données distribuées et traitement rapide des données.
Afin de maintenir cette flexibilité, Chukwa est structuré comme un pipeline de collecte et de la transformation, avec des interfaces claires et étroites entre les niveaux. Cela facilitera l'innovation future sans casser le code existant.
Chukwa a quatre composantes principales:
ð Agents : Qui s’exécutent sur chaque machine et émet des données.
ð Collectors : Qui reçoit les données de des agents et les écrit sur un support stable.
ð MapReduce Jobs : Pour l’analyse et l’archivage des données.
ð HIIC (the Hadoop Infrastructure Care Center) : une interface de style portail Web pour l'affichage des données. [HDG] [HAO] [DYC]
III.3.8- Sqoop :
Sqoop (“SQL-to-Hadoop”) est un outil conçu pour importer des données des bases de données relationnelles au cluster Hadoop.
Sqoop est un simple outil de ligne de commande avec les fonctionnalités suivantes:
ð Importer des tables ou des bases de données entières aux fichiers dans le HDFS.
ð Générer des classes Java pour permettre l’interaction avec les données importées.
ð Offrir la possibilité d'importer des bases de données SQL directement dans l’entrepôt de données Hive.
ð Création de job MapReduce pour lire les données importées. [ACC]
III.3.9- Avro :
Avro est un système de sérialisation des données.
Avro offre :
ð Une structure de données riche.
ð Un compact et rapide format binaire de données.
ð Un fichier conteneur pour les données persistantes.
ð Appel de procédures a distance (RPC).
ð Intégration simple avec les langages dynamiques. La génération de code n'est pas nécessaire pour lire ou écrire des fichiers de données, ni à utiliser ou à mettre en œuvre des protocoles RPC. La génération de code est comme une option d'optimisation, la mise en œuvre ne vaut que pour les langages typiquement statiques. [HAO]
III.4- Conclusion:
Ce chapitre représente une synthèse de ce que c’est qu’Hadoop, son principe, fonctionnalités et aspects ainsi que ceux des diverses technologies qu’il comporte.
Cela nous permettra d’optimiser au mieux notre mise en œuvre, à savoir : paramétrage, configurations et l’architecture la plus adéquate.
Tweeter
1 commentaires:
Merci pour cette synthèse de l'écosystème Hadoop qui permet d'en avoir une découverte rapide.
Enregistrer un commentaire