Excerpt for Initiation à l'écosystème Hadoop by , available in its entirety at Smashwords













Maîtrisez l’utilisation des technologies Hadoop



Initiation à l’écosystème Hadoop













JUVENAL CHOKOGOUE

http://www.data-transitionnumerique.com/extrait-ecosystme-hadoop/











Table de matières


















Mentions légales


Cet ebook est une propriété exclusive de Juvénal CHOKOGOUE. Il a fait l’objet d’un dépôt légal. Toute personne a le droit de le télécharger et de l’utiliser uniquement sous les conditions listées ci-dessous :

  • Vous avez le droit de copier ou d’intégrer partiellement le texte de l’ebook dans vos propres travaux à condition de mentionner le nom de l’auteur, Juvénal CHOKOGOUE ;

  • L’intégration de tout le texte de l’ebook nécessite une permission écrite de l’auteur ;

  • le contenu de l’ebook ne doit sous aucune manière que ce soit être modifié. Il doit rester fidèle à sa version d’origine tel que téléchargé ;

  • Les références aux marques, aux entreprises et aux universités citées dans cet ebook n’ont en aucune façon que ce soit un but publicitaire, elles sont utilisées exclusivement à des fins académiques et restent entièrement la propriété de leurs détenteurs ;

  • Les marques citées dans cet ebook, les logos d’entreprises, sont des marques déposées des entreprises en France, aux états Unis ou partout dans le monde ;

  • Les conseils, les tableaux comparatifs, les benchmark de solutions et les prises de position présents dans l’ebook représentent le point de vue personnel de l’auteur à la date de publication. Aucun favoritisme n’a été fait lors des benchmarks et des comparaisons. Etant donné la vitesse avec laquelle évolue le monde de la technologie et du Big Data, beaucoup de ces conseils et tableaux peuvent devenir obsolètes après la publication de cet ebook. Ainsi, bien que l’auteur ait pris tous les soins nécessaires pour vous initier aux technologies de l’écosystème Hadoop, il ne peut être tenu pour responsable des résultats négatifs qu’auraient causé l’application de ces conseils après la date de publication de l’ebook ;

  • En raison des changements rapides du marché, le contenu des sites Web fournis peut être modifié ou changé, ou le site Web lui-même peut être indisponible. Donc, après la date de publication de cet ebook, l’auteur ne peux vous donner aucune garantie quant à la disponibilité des sites Internet fournis ;

  • Il y’a de l'anglicisme dans cet ebook. C'est un choix personnel de l'auteur, qui veut par-là conserver la fiabilité de la teneur sémantique des mots du jargon ;

  • Toute personne qui exécutera un acte non-autorisé à l’égard de cet ebook (recopie de tout l’ebook sans permission écrite de l’auteur, recopie partielle de l’ebook sans mentionner l’auteur, utilisation commerciale) s’expose à des poursuites judiciaires conformément aux dispositions du Copyright en vigueur en France, dans l’Union Européenne et dans le monde.



Copyright 2018 © Juvénal CHOKOGOUE





















































































http://www.data-transitionnumerique.com/extrait-ecosystme-hadoop/



EBOOK EN BONUS - ELASTICSEARCH

La donnée est le carburant de l’économie Numérique. Elle a toujours été le support de toute prise de décision efficace. Cependant, en Interne, beaucoup d’entreprises souffrent encore de l’incapacité qu’ont leurs employés à retrouver du contenu dans leurs fichiers. Il peut s’agir de la simple recherche d’hôtel le plus confortable d’une zone, de la recherche d’itinéraire de transport le plus proche d’un magasin, du nombre de clients qui ont acheté une catégorie de produits, ou de la liste des employés les plus productifs. Avec la quantité phénoménale des données qui prévaut actuellement, il est de plus en plus difficile d’utiliser le SQL pour la recherche de contenu. L’indexation de contenu est la technique principale utilisée actuellement pour rechercher de façon efficace du contenu. L’indexation de contenu permet de réaliser les recherches en se basant d’une part sur un index et d’autre part sur un score de similarité qui attribue un niveau d’importance à chaque fichier.

En complément de cet ebook, nous vous offrons un guide de 30 pages  qui vous permet d’apprendre à aller au-delà du SQL pour la recherche de contenu en utilisant ElasticSearch. Pour le recevoir directement dans votre boîte mail, cliquez sur le lien suivant : http://www.data-transitionnumerique.com/extrait-ecosystme-hadoop/





Introduction

Le 21ème siècle a été témoin d’une explosion sans précédent du volume de données. D’après le constat des experts, des institutions publiques et privés, 90 % des données récoltées depuis le début de l’humanité ont été générées durant les 2 dernières années. Le marché qualifie aujourd’hui de « Big Data » cette explosion de données.

En réalité, le Big Data  est le reflet d’un changement plus profond : le passage d’une ère industrielle caractérisée par l’électricité vers une ère Numérique caractérisée par la donnée. Ce changement a entraîné de profondes modifications dans la société contemporaine : modèles économiques à coût marginal décroissant, commoditisation de la connaissance, décentralisation du pouvoir de création de l’information, suppression des barrières à l’entrée, ubérisation de la société, Internet des Objets, blockchains. Bref, aucun aspect de la société et de nos vies n‘y échappe.

Bien qu’effrayant à vue d’œil, ce changement est en réalité les prémices de grandes opportunités. En chine, il y’a un proverbe qui résume très bien cela : « lorsque les vents du changement souffle, certains construisent des moulins, tandis que d’autres construisent des abris ». Le changement contient toujours des opportunités qui lui sont inhérentes et ce que le proverbe essaye de dire c’est que les opportunités se perçoivent, elles ne se voient pas à l’œil nu.

La manière de penser nécessaire pour « voir » les opportunités d’un changement est ce que l’on appelle un paradigme (terme emprunté à Thomas Kuhn).

Dans cet ebook, nous allons vous initier à l’utilisation des technologies qui permettent d’identifier les opportunités cachées du Big Data en BtoB (c’est-à-dire pour l’entreprise), au-delà du tapage médiatique et de la publicité des éditeurs logiciels. Plus concrètement, à la fin de la lecture de cet ebook :

  • vous saurez pourquoi il est nécessaire de vous équiper d’un écosystème de technologies pour identifier les opportunités du Big Data ;

  • Vous serez initié(e)s à l’utilisation d’Hadoop ;

  • Vous serez initié(e)s à l’utilisation du SQL sur Hadoop ;

  • Vous serez initié(e)s à l’utilisation de Spark via Scala ;

  • Vous connaîtrez la portée fonctionnelle et stratégique des technologies de l’écosystème Hadoop ;

De plus, l’ebook est accompagné en bonus d’un guide de 30 pages qui vous permettra d’aller au-delà de l’initiation et de vous spécialiser sur une technologie précise de la recherche de contenu : ElasticSearch.

Puisse cet ebook contribuer à vous mettre sur le chemin des opportunités du monde abondant créé par la donnée ! Merci pour votre confiance et bonne lecture !


Juvénal CHOKOGOUE

1 – Introduction à l’écosystème Hadoop

1.1 – De l’approche centralisée à l’approche décentralisée

Avant l’explosion du volume de données, l’approche de gestion des données consistait à centraliser le stockage et le traitement des données sur un serveur central dans une architecture client/serveur. Ces données étaient gérées dans le serveur par un SGBDR. Le serveur central, ici, est une machine très puissante, conçue sur mesure par des sociétés spécialistes de l’infrastructure informatique comme EMC, Dell ou encore HP. La figure suivante illustre cette approche.

Figure 1 : approche traditionnelle de gestion des données

Google fait partie des entreprises qui a très tôt ressenti les faiblesses de cette approche. En 2002, son directeur général (CEO) de l’époque Eric Schmidt, a envoyé une onde de choc dans toute l’industrie IT en annonçant que Google n’avait aucune intention d’acheter le nouveau serveur HP doté du tout dernier microprocesseur Itanium développé par Intel. Dans la vision de Google, avec la baisse des coûts d’ordinateurs engendré par le doublement du nombre de transistors sur les microprocesseurs tous les 18 mois (confère la loi de Moore), le futur du traitement informatique reposerait sur la constitution de Data Centers composés de plusieurs machines commodes (les clusters). Par ce point de vue, Google a introduit un nouveau paradigme technologique qui progressivement est en train de remplacer l’architecture client/serveur classique.

En 2002, cette vision technologique de Google paraissait ridicule, mais aujourd’hui, elle fait sens. En effet, l’échelle de croissance des données surpasse aujourd’hui la capacité raisonnable des technologies traditionnelles (SGBDR), ou même la configuration matérielle typique supportant les accès à ces données. L’approche proposée par Google consiste à distribuer le stockage des données et à paralléliser leur traitement sur les nœuds d’un cluster.

Figure 2 : Nouveau paradigme de gestion des données

En résumé, l’approche conceptuelle au problème de traitement de données dans l’économie numérique est la suivante : les traitements/calculs sont divisés en tâches et leur exécution est parallélisée dans un cluster d’ordinateurs complètement tolérant aux pannes. Dès lors, l’approche de centralisation qui a prévalu jusqu’ici est tout simplement inenvisageable. La tolérance aux pannes est fournie par un tout nouveau type de Système de Fichiers appelé "Système de Fichier Distribué" (DFS), et le découpage et parallélisme de ces tâches se font à l'aide d'un nouveau type modèle de calcul appelé modèle de calcul distribué. Une application générique de gestion de ressources permet d’aller au-delà d’un modèle de calcul et d’en exécuter plusieurs à la fois sur le cluster . Ces trois éléments sont la fondation de toutes les approches technologiques qui ont été développées dans l’ère du Numérique. Hadoop est l’implémentation logicielle la plus mature qui permet de mettre en œuvre cette approche. Il est aujourd’hui ’implémentation la plus populaire et la plus mature du marché est en passe de devenir le standard de Facto dans l’ère Numérique. Nous pouvons même dire sans prendre de risque que Hadoop va devenir la plateforme de traitement de données par défaut des utilisateurs, un peu comme Excel est progressivement devenu le logiciel par défaut d’analyse de données. Problème : A la différence d’Excel, Hadoop n’a pas été à la base conçu pour être utilisé par les « Analystes métier », mais par les développeurs. Or, on connaît le constat de Bob de Metcalfe selon lequel « la valeur d’un standard est proportionnel au carré du nombre de systèmes qui l’utilise ». En termes plus simples, ce constat peut se contextualiser sous la forme suivante : « la valeur d’une technologie est proportionnelle au carré du nombre de personnes qui l’utilise ». En d’autres termes, l’adoption à grande échelle et le succès de d’une technologie (et donc d’Hadoop) ne dépendent pas des développeurs, mais des utilisateurs métiers ! La fondation Apache, dépositaire d’Hadoop a bien compris cela, c’est pourquoi depuis qu’elle a repris Hadoop en 2009, elle s’évertue à rapprocher le plus que possible celui-ci aux utilisateurs métiers. Le marché étant fortement concurrentiel, la réponse des éditeurs logiciels ne s’est pas fait attendre. Ainsi sur le marché 2 catégories d’acteurs ont pris à cœur cet objectif : le monde de l’open source, centralisé autour de la fondation Apache, et le monde des éditeurs logiciels. Les deux offrent un ensemble d’outils autour d’Hadoop qu’il est aujourd’hui raisonnable de qualifier d’Ecosystème Hadoop. Etant donné que cet ebook est exclusivement réservé à l’apprentissage des outils de l’écosystème technologique d’Hadoop, il est indispensable que nous revenions sur les fondations d’Hadoop avant d’expliquer la taxonomie des outils qui constituent son écosystème.

1.2 – Généralités sur Hadoop

En 2014, 90 % de toutes les données jamais générées par l'homme l'ont été au cours des deux dernières années ; Cisco renchérit ce constat lorsqu’il prédit que le trafic IP global annuel serait de 1,3 zetta octet en 2016. Cet accroissement dans le trafic réseau est attribué à l’accroissement du nombre des smartphones, tablettes et autres appareils connectés à Internet, à la croissance des communautés d’utilisateurs Internet, à la croissance de la bande passante, à la rapidité offerte par les opérateurs de télécommunication, et à la disponibilité et à la connectivité du Wi-Fi. Ne parlerons même pas de la variété d’actifs de données créées !

L’échelle de cette croissance de données surpasse la capacité raisonnable des technologies traditionnelles, précisément les systèmes de gestion de bases de données relationnelles (SGBDR), ou même la configuration matérielle typique supportant les accès à ces données. Plus encore, les données canalisées vers le réseau Internet créent de la pression pour la capture cohérente et rapide de ces données. Google fait partie des entreprises qui ont très tôt ressenti le besoin de gérer efficacement les gros volumes de données liés aux requêtes faites par les utilisateurs. Rappelons que le moteur de recherche de Google doit restituer en temps quasi réel le résultat de 3 millions de recherches effectuées par minute. Pour répondre à cette exigence, Google doit indexer toutes les pages web qui constituent Internet et rechercher à l’intérieur de chacune de ces pages les mots qui sont demandés par l’utilisateur. Le nombre de sites Internet dans le monde aujourd’hui est estimé à plus de 1 milliard avec une croissante de 5,1 % (estimation faite par Netcraft), sachant qu’au-delà de 5 secondes d’attente, l’utilisateur considère que la requête a échoué et passe à autre chose. Résoudre ce problème ne peut se faire ni avec les approches de centralisation des données dans un seul serveur comme on l'a fait dans le passé, et ni avec les approches centralisées de traitement in-memory. Il est dès lors indispensable de penser à d’autres approches, et c'est là où Hadoop entre en scène.

Pour répondre à ces challenges, l’idée de Google est de développer une approche conceptuelle qui consiste à distribuer le stockage des données d’une part et à paralléliser le traitement de ces données sur plusieurs nœuds d'une grappe de calcul (un cluster d’ordinateurs) d’autre part. L’emploi d’une grappe de calcul n’est pas anodin. En effet, tout en étant l’infrastructure qui sert de support au traitement massivement parallèle, son utilisation permet de profiter des rendements d’échelle engendrés par la baisse des coûts des ordinateurs. Ainsi, la croissance des données est gérée en augmentant simplement les nœuds dans le cluster. Cette approche conceptuelle a été adoptée par le marché et est à la base de toutes les technologies Big Data actuellement.

  • Au niveau du traitement : Google décide de découper le problème d’indexation des pages web en sous-tâches ou sous-problèmes qui seront distribués dans le cluster pour exécution. Pour ce faire, Google décide de construire un index inversé par mot clé contenu dans chaque page web. Pour faire simple, un index inversé correspond à la page d’index d’un livre ; il est constitué des mots-clés, avec pour chaque mot clé ses différentes localisations dans tout le document. Ainsi, chaque fois que vous recherchez un mot, vous pouvez vous servir de l’index pour identifier la ou les pages où le mot que vous cherchez se situe, cela vous évite de fouiller tout le document page par page pour retrouver le mot. Aujourd’hui, la recherche Internet fonctionne selon ce principe. Le moteur de recherche constitue une base d’index inversés pour chaque mot. Cependant, construire un index inversé n’est pas aussi simple que ça en a l’air. Pour que vous ayez une image claire du problème, prenons l’exemple d’une page web contenant 5 000 mots. Le moteur de recherche doit indexer les 5 000 mots. Indexer 1 000 pages web contenant chacune 5 000 mots demande la construction d’un index inversé de 5 000 000 mots (1 000 × 5 000). Pour construire l’index inversé, Google passe par un raisonnement en trois phases consécutives : la première phase, appelée par Google la phase Map, consiste à assigner à chaque nœud du cluster la tâche d’attribuer à chaque mot de la page web un indice correspondant à la page dans laquelle il est. Cet indice peut être le titre de la page, le numéro de la page, bref n’importe quel élément qui permet d’identifier la page de façon unique parmi toutes les pages qui constituent tout le site web. Cette tâche s’exécute parallèlement (en même temps) dans tout le cluster. La deuxième étape, appelée par Google le Shuffle, consiste pour chaque nœud à trier par ordre alphabétique les mots auxquels il a affecté un index. Cette étape est intermédiaire et permet de faciliter le travail effectué par la troisième phase. La troisième et dernière phase, appelée par Google le Reduce, consiste pour chaque mot dans l’ensemble des nœuds du cluster, à regrouper l’ensemble de ces indices. Ainsi, on obtient l’index inversé.

    • Au niveau du stockage : Google décide de ne pas centraliser le stockage de toutes les pages Internet vers un seul serveur pour la construction des index inversés. De toute façon, cette approche n’est pas envisageable vu que le volume de données généré aujourd’hui dépasse largement la capacité des serveurs traditionnels. Comme la tâche de construction des index est partagée entre les nœuds du cluster, les fichiers contenant les mots (les pages web) doivent être divisés et chaque morceau de fichier doit être stocké de façon redondante sur le disque dur des nœuds du cluster de sorte que si un nœud tombe en panne tout au long du traitement, cette panne n’affecte pas les autres tâches. Techniquement, le stockage de fichiers sur un disque dur se fait à l’aide de ce que l’on appelle un système de fichiers (File System). Le système de fichiers est unique par ordinateur, ce qui pose problème dans un cluster où l’ensemble des nœuds doit être vu comme un seul ordinateur. Pour résoudre ce problème et gérer la redondance des données sur plusieurs disques durs, Google met sur pied un nouveau type de Système de Fichiers appelé "système de fichiers distribués" (Distributed File System - DFS), qui est installé sur le cluster. La figure suivante résume le travail de construction d’index inversé par le raisonnement en trois phases de Google.

Figure 3 : paradigme en trois phases de Google

C’est par cette approche conceptuelle que Google arrive à gérer son problème d’indexation de pages web et à tirer avantage des données générées dans le numérique. Le découpage des traitements en plusieurs tâches et la parallélisation de ces tâches sur un grand nombre de nœuds se font à l'aide du modèle en trois étapes présentées précédemment que Google a baptisé MapReduce ; la distribution, le stockage et la redondance des fichiers sur le cluster se font à l’aide du système de fichiers distribués mis au point par Google et baptisé Google File System (GFS). Ces deux éléments à l’origine étaient utilisés en interne chez Google. Plus tard, un ingénieur de l’entreprise, Doug Cutting, va implémenter en Java le MapReduce et le GFS, et donner le nom d’une des peluches de son fils à cette implémentation : Hadoop. Le HDFS (Hadoop Distributed File System) est son système de fichiers distribués, l’équivalent du GFS. Depuis 2009, le projet Hadoop a été repris par la fondation Apache et est officiellement devenu un framework open source. Hadoop et le HDFS forment aujourd'hui la nouvelle infrastructure technologique de l'ère Numérique.

Comme vous l’avez vu précédemment, le MapReduce est une approche conceptuelle, elle a besoin d’être implémentée pour être utilisée. Hadoop répond à cette demande : Hadoop est l'implémentation la plus populaire et la plus mature du MapReduce sur le marché. En réalité, Hadoop est un ensemble de classes1 écrites en Java pour la programmation des tâches MapReduce et HDFS dont les implémentations sont disponibles en plusieurs autres langages de programmation. Il y’a par exemple des implémentations MapReduce en Scala, et C#. Ces classes permettent à l'analyste d'écrire des fonctions Map et des fonctions Reduce qui vont traiter les données sans que l’analyste ait à savoir comment ces fonctions sont distribuées et parallélisées dans le cluster. Dans ce point, vous allez comprendre le fonctionnement d’Hadoop, les étapes d’exécution d’un programme MapReduce dans un cluster Hadoop et la façon dont il est parallélisé.

  • Terminologie d’Hadoop

Avant de parler de l’exécution des jobs MapReduce dans Hadoop, nous allons en présenter la terminologie. Un Job MapReduce est une unité de travail que le client veut exécuter. Il consiste en trois choses : le fichier des données à traiter (Input file), le programme MapReduce, et les informations de configuration (Méta données). Le cluster exécute le job MapReduce en divisant le programme MapReduce en 2 tâches : les tâches Map et les tâches Reduce. Dans le cluster Hadoop, il y'a deux types de processus qui contrôlent l'exécution du job : le jobtracker et un ensemble de tasktrackers. Le jobtracker c’est le processus central qui est démarré sur le Nœud de référence (le Name Node), il coordonne tous les jobs qui s'exécutent sur le cluster, gèrent les ressources du cluster et planifie les tâches à exécuter sur les tasktrackers. Les tasktrackers ce sont les processus qui traitent le programme MapReduce de l’analyste, ils sont démarrés au niveau des nœuds de données, exécutent les tâches Map ou Reduce et envoient des rapports d'avancement au jobtracker, qui garde une copie du progrès général de chaque job. Si une tâche échoue, le jobtracker peut le replanifier sur un tasktracker différent. En fait, le Jobtracker désigne le nœud de référence et le process Master qui y est démarré, tandis que le Tasktracker désigne un nœud de données et le process Worker qui y est démarré. La figure ci-après illustre le rapport entre le Jobtracker et les tasktrackers dans le cluster.

Figure 4 : cluster Hadoop, avec 5 nœuds. Le nœud de référence secondaire ne compte pas comme un nœud du cluster. Les nœuds de données sont des tasktrackers tandis que le nœud de référence est un jobtracker.

Chaque nœud possède une partie stockage et une partie traitement. La partie stockage est assurée par le nœud, tandis que la partie traitement est effectuée par le processus (Worker ou Master) qui est démarré sur le nœud. Dans la terminologie Hadoop le nom du processus est associé à la machine, on parle de Jobtracker et tasktracker.

Maintenant que nous avons réglé le problème de terminologie, regardons ensemble la façon dont le MapReduce y est exécuté.

      • Détails d’exécution d’un modèle de calcul dans Hadoop

Même si Hadoop est l’implémentation du MapReduce, depuis sa version 2 et +, il a la capacité d’exécuter plusieurs modèles de calcul sur le cluster. Cela est possible grâce à un gestionnaire de ressources tel que MESOS ou YARN. Par contre, tous les modèles de calculs sont exécutés de la même façon par Hadoop. Dans ce point, nous allons illustrer les étapes d’exécution d’un modèle de calcul sur Hadoop avec le MapReduce. Par ailleurs, soyez attentifs. Le traitement MapReduce écrit par l’utilisateur s’appelle un job MapReduce dans la terminologie du cluster Hadoop et s’exécute en 7 étapes :

  1. Au départ, l’utilisateur configure le Job MapReduce : il écrit la fonction Map, la fonction Reduce, spécifie le nombre de tâches Reduce que nous appellerons r, le format de lecture du fichier d’entrée, le format de sortie des r fichiers Reduce, éventuellement la taille des blocs du fichier d’entrée et le facteur de réplication2. Une fois que tout cela est fait et qu’il déclenche l’exécution du job, le Jobtracker démarre les r tasktrackers qui vont effectuer les r tâches Reduce que l’utilisateur a spécifiées ;

  2. Le HDFS découpe le fichier d’entrée en M blocs de taille fixe, généralement 64 Mo par bloc (sauf si l’utilisateur a spécifié une taille de bloc différente à la première étape). Ensuite, le HDFS réplique ces blocs selon le facteur de réplication définie par l’utilisateur (3 par défaut) et les distribue de façon redondante dans des nœuds différents dans le cluster. Le fait de diviser le fichier d’entrée en blocs de taille fixe permet de répartir de façon équilibrée la charge de traitement parallèle entre les nœuds du cluster, ce qui permet au traitement de s’achever à peu près au même moment dans l’ensemble des nœuds du cluster ;

  3. Par défaut, le Jobtracker déclenche M tasktrackers sur les M nœuds de données dans lesquels ont été répartis les M blocs du fichier d’entrée, pour exécuter les tâches Map, soit un tasktracker Map pour chaque bloc de fichier. Chaque tasktracker lit le contenu du bloc de ficher par rapport au format d’entrée spécifié par l’utilisateur, le transforme par le processus de hachage définie dans la fonction Map en paires de clés/valeurs. Ce processus de hachage s’effectue en mémoire locale du nœud ;

  4. Périodiquement, dans chaque nœud, les paires de clés/valeurs sont sérialisées dans un fichier sur le disque dur local du nœud. Ensuite ce fichier est partitionné en r régions (correspondant aux r tâches Reduce spécifiées par l’utilisateur) par une fonction de hachage qui va assigner à chaque région une clé qui correspond à la tâche Reduce à laquelle elle a été assignée. Les informations sur la localisation de ces régions sont transmises au Jobtracker, qui fait suivre ces informations aux r tasktrackers qui vont effectuer les tâches Reduce ;

  5. Lorsque les r tasktrackers Reduce sont notifiés des informations de localisation, ils utilisent des appels de procédures distantes (protocole RPC) pour lire depuis le disque dur des nœuds sur lesquels les tâches Map se sont exécutées, les régions des fichiers Map leur correspondant. Ensuite, ils les trient par clé. Notez au passage que le tri s’effectue en mode batch dans la mémoire du tasktracker Reduce. Si les données sont trop volumineuse, alors cette étape peut augmenter de façon significative le temps total d’exécution du job ;

  6. Les tasktrackers Reduce itèrent à travers toutes les données triées et pour chaque clé unique rencontrée, ils la passent avec sa valeur à la fonction Reduce écrite par l’utilisateur. Les résultats du traitement de la fonction Reduce sont alors sérialisés dans le fichier ri (avec i l’indice de la tâche Reduce) selon le format de sortie spécifié par l’utilisateur. Cette fois-ci, les fichiers ne sont pas sérialisés dans le disque dur du nœud tasktracker, mais dans le HDFS, ceci pour des raisons de résilience (tolérance aux pannes) ;

  7. Le job s’achève là, à ce stade, les r fichiers Reduce sont disponibles et Hadoop applique en fonction de la demande de l’utilisateur, soit un « Print Ecran », soit leur chargement dans un SGBD, soit alors leur passage comme fichiers d'entrée à un autre job MapReduce ;

La figure suivante récapitule en visuel ces 7 étapes.

Figure 5 : étapes d'exécution d'un job MapReduce dans un cluster Hadoop. La couleur jaune traduit les traitements, la verte représente la RAM, le blanc représente les opérations d’accès à la données et les cylindres bleus les fichiers Map.



Voilà, à ce stade, vous avez les informations générales, mais indispensable sur Hadoop pour être effectivement initié(e) sur son écosystème technologique. Si vous souhaitez aller plus en profondeur sur le fonctionnement d’Hadoop, et son utilisation nous vous recommandons l’ouvrage « Hadoop – Devenez opérationnel dans le monde du Big Data » dont nous sommes l’auteur. Nous allons maintenant passer à la taxonomie de l’écosystème Hadoop.

1.3 – Taxonomie de l’écosystème Hadoop

En réalité, Hadoop est une plate-forme qui implémente des modèles de calcul parallèle comme le MapReduce et fournit un système de fichier distribué redondant, fiable et optimisé pour la gestion des fichiers volumineux (le HDFS). Comme nous l’avons dit tout à l’heure, Hadoop est en réalité un ensemble de classes écrites en Java pour la programmation des tâches MapReduce et HDFS. Ces classes permettent à l'analyste d'écrire des fonctions qui vont traiter les données sans avoir à se préoccuper de la façon dont ces fonctions sont distribuées et parallélisés dans le cluster. Pour tirer le meilleur parti d'un cluster Hadoop, la fondation Apache a inclut dans Hadoop une série de logiciels et d'outils. Cet ensemble forme aujourd'hui ce qu'il est judicieux d'appeler l'écosystème Hadoop ou Framework Hadoop. Pourquoi ? Parce que sans ces outils, il reviendrait à chaque entreprise en fonction de son besoin, de développer elle-même des outils compatibles avec Hadoop afin de déployer ses solutions sur le Cluster ; ce qui serait un "daunting task" (tâche gargantuesque) comme le disent nos amis les anglophones.

Actuellement, pas mal de développeurs sont en train de travailler sur l'écosystème Hadoop et offrent leurs travaux à la fondation Apache. Vous avez par exemple Yahoo qui a développé ZooKeeper, un service de coordination distribué, qu’il a donné à la fondation Apache, Cloudera, qui a développé le moteur de calcul SQL massivement parallèle Impala et l’a passé à la fondation Apache, ou encore LinkedIn, qui a développé un système de messagerie Publish/Subscribe distribué, Kafka, etc. C’est la contribution de tous ces acteurs qui constituent aujourd’hui l’écosystème Hadoop. L'écosystème Hadoop fournit une collection d'outils et de technologies spécialement conçus pour faciliter le développement, le déploiement et le support des solutions Big Data. La définition de cet écosystème est importante, car elle facilite l'adoption d'Hadoop et permet aux entreprises de surmonter les défis du Numérique.

L’écosystème Hadoop est constitué d’outils qui peuvent être rangés par catégories en fonction de la tâche que chacun résout. Nous avons décidé de les ranger en 14 catégories selon la problématique qu’ils résolvent et ce en fait chacune des technologies principales de quelques-unes de ces catégories que nous étudierons dans la suite de l’ebook :

  • les langages d’abstraction : ils permettent de développer des jobs MapReduce à l’aide d’un langage similaire au SQL. Dans cette catégorie, on distingue principalement Hive, Pig, et Cascading ;

  • le SQL sur Hadoop : des technologies qui permettent d’exécuter nativement du SQL sur un cluster Hadoop. A ce jour 3 projets sont en incubation à la fondation Apache bien qu’opérationnels. Il s’agit d’Impala, Phoenix, et HAWQ  ;

  • les modèles de calcul : ce sont des moteurs d’exécution d’algorithme parallèle ou des modèles de programmation des tâches distribuées sur un cluster. Actuellement, Hadoop dispose de 4 modèles de calcul (chaque modèle s’exécute à l’aide de son propre moteur) : le MapReduce, le modèle original d’Hadoop, Spark, le moteur In-Memory distribué crée par l’université de Berkeley, Mahout, Hama, et TEZ  ;

  • les outils de traitement temps réel : ce sont des outils qui permettent de faire du traitement immédiat des données générées en streaming (au fil de l’eau). 4 outils sont disponibles dans cette catégorie : Storm, Samza, S4 et Spark Streaming ;

  • les Bases de données : ce sont des systèmes de gestion de base de données distribuées (SGBDD). Ils permettent de gérer des bases de données sur un cluster. Plusieurs SGBDD open source existent mais ils ne font pas partie de la fondation Apache. Les trois seules qui font partie de la fondation Apache à notre connaissance sont HBase, Cassandra et Accumulo ;

  • les outils d’ingestion streaming : ce sont des outils qui permettent d’ingérer des données générées en streaming. La fondation Apache en dispose de deux dans cette catégorie : Kafka et Flume ;

  • les outils d’intégration des données : ce sont des outils qui permettent de déplacer les données d’un SGBDR vers le HDFS et vice-versa. Le seul outil disponible dans cette catégorie est Scoop, que nous étudierons bien évidemment ;

  • les outils de coordination de Workflow : ce sont des outils qui permettent de planifier et de chaîner l’exécution de plusieurs Jobs dans le cluster Hadoop. Oozie est le seul outil disponible dans cette catégorie. Nous l’étudierons de fond en comble ;

  • les outils de coordination de services distribués : ce sont des outils qui permettent de coordonner les échanges entre les nœuds d’un cluster, ou entre plusieurs applications ;

  • les outils d’administration de cluster : ce sont des outils qui permettent d’administrer un cluster, par exemple, gérer l’approvisionnement des ressources du cluster, les permissions des utilisateurs, suivre l’exécution des tâches dans le cluster, etc. Plusieurs outils indépendants ont été développés pour l’administration Hadoop, mais Ambari, l’outil d’administration du cluster Hadoop combine ces outils ;

  • les outils d’interface utilisateur : ce sont des outils qui permettent à l’utilisateur d’interagir avec le cluster, et les outils d’Hadoop installé sur ce cluster. Actuellement, la fondation Apache offre une interface Web appelée HUE ;

  • les outils d’indexation de contenu : ce sont des outils qui permettent de faire ce qu’on appelle communément le Full Text Search, c’est-à-dire la recherche de texte intégrale. Ils permettent d’indexer du texte par exemple des pages Web et fournissent des fonctionnalités de recherche de texte sur ces pages. Dans cette catégorie, on distingue le moteur Lucene, Solr, et Lucy. En dehors de ces 3 moteurs, un autre moteur d’indexation est également très utilisé mais ne fait pas partie de la fondation Apache : c’est ElasticSearch. ElasticSearch s’appuie sur Lucene. Le bonus que nous offrons à la suite de cet ebook porte justement sur ElasticSearch : http://www.data-transitionnumerique.com/extrait-ecosystme-hadoop/ ;

  • les systèmes de fichier distribués : ce sont des couches abstraites, installées sur le cluster pour gérer le stockage des données distribué. Hadoop est fourni avec son système de fichier distribué initial, le HDFS, que nous ne verrons pas dans cet ebook, car cela exigerais qu’on rentre dans les détails du fonctionnement de Hadoop, ce qui est hors des objectifs assignés à cet ebook. Si vous souhaitez apprendre le HDFS, nous vous suggérons de vous procurer notre ouvrage « Hadoop – Devenez opérationnel dans le monde du Big Data » dans lequel un chapitre entier est dédié à l’étude des systèmes de fichiers distribués et du HDFS ;

  • et les gestionnaires de ressources : ce sont des outils qui permettent de mieux exploiter les ressources d’un cluster. Par cela, ils donnent la possibilité de pouvoir exécuter plusieurs modèles de calcul sur un cluster. Souvenez-vous que Hadoop est originellement l’implémentation du MapReduce, en d’autres termes, il n’est limité qu’à l’exécution du MapReduce. Le gestionnaire de ressources permet de lever cette limite. Actuellement, la fondation Apache fournit deux gestionnaires de ressources : YARN, et MESOS ;

Une distribution Hadoop, qui est une version commerciale d’Hadoop, est composée d’au moins un outil de chacune de ces catégories. Ainsi, la maîtrise de ces outils vous donne la maîtrise complète d’Hadoop et vous permet d’embrasser les problématiques de traitement de données du Numérique avec sérénité. L’un des but de cet ebook est de vous aider à développer des compétences sur certains des outils les plus proéminents de ces 14 catégories. Au sorti de l’ebook, vous aurez développé des compétences opérationnelles sur Hive, Pig, Spark, entre autre. La figure suivante illustre la composition d’un écosystème Hadoop.


Figure 6 : aperçu de la cartographie de l'écosystème Hadoop

Attention ! Gardez à l’esprit que les outils de l’écosystème Hadoop varient beaucoup, car comme l’écosystème est en majorité composé des contributions des entreprises et des développeurs indépendants, elle change très vite. Certains outils sont ajoutés, d’autres sont modifiés et d’autres sont simplement supprimés. Tous les outils que nous avons cités ici ne tiennent pas en compte les projets en cours d’incubation. Les projets encours d’incubation sont des contributions logicielles qui n’ont pas encore été testés et validés par la fondation Apache. Considérez donc cet écosystème comme un guide illustratif et non-exhaustif.

















Vous pouvez utiliser la carte heuristique de la figure 7 pour avoir une image mentale claire du rôle et de la place de chaque outil dans l’écosystème. Cette approche de découpage permet de regrouper les outils selon la problématique métier et vous fournit une vision complète à la fois de l’approche conceptuelle de résolution de cette problématique et de la façon dont cette approche conceptuelle est implémentée par chaque outil. Ainsi, en plus de la connaissance technique de chaque outil, vous aurez une vision plus large de la problématique et pourrez exercer des activités de conseil autour de l’écosystème Hadoop.

































































Figure 7 : carte heuristique de l'écosystème Hadoop



Maintenant passons au vif du sujet de l’ebook. La configuration de base de l'écosystème Hadoop contient les technologies suivantes : Hive, PIG, Spark, HBase, Sqoop, Storm, ZooKeeper et Oozie. C’est dans ces technologies que nous allons vous initier dans le cadre de cet ebook.

2 – Hive

Il y’a des bonnes raisons de croire que le MapReduce va devenir le mode normal de traitement des données dans l’ère numérique et donc que Hadoop va devenir l’outil par défaut du traitement de données. Le problème comme nous avons pu le voir précédemment, est que le MapReduce est un langage de trop bas niveau, c'est-à-dire trop proche de la machine, il implique que le développeur sache interagir avec le cluster, ce qui peut être très difficile pour un développeur nouveau dans le monde du traitement parallèle, ou pour des utilisateurs métiers. L'un des moyens de simplifier le développement MapReduce, et Hadoop en général consiste à fournir ce qu'on appelle un langage d'abstraction. Un langage d'abstraction est un langage à syntaxe relativement proche du langage humain qui permet d'exprimer des problèmes métiers sous forme de requêtes simples. L'abstraction vient du fait que lorsque l'utilisateur exprime son besoin sous forme d'une requête, cette requête est transformée plus bas en instructions machines. Ainsi, le langage d'abstraction n'est en réalité qu'une couche qui masque la complexité d'expression des problèmes directement en langage de bas niveau comme le ferait un développeur. Plus le niveau d'abstraction offert par le langage est élevé, et plus on est éloigné de la machine, et plus simple il est pour les utilisateurs. Plus il est élevé, plus il tend à être descriptif et se rapprocher de l’utilisateur. Hive fait partie avec Pig des langages d’abstraction offerts par la fondation Apache pour écrire des requêtes MapReduce. Il a été conçu pour un public non-développeur et permet d'exprimer des jobs MapReduce dans un style de programmation similaire à celui du SQL, familier aux utilisateurs. Par la suite, il transforme les requêtes écrites en Jobs MapReduce qui sont soumis au cluster pour exécution. Globalement, Hive offre un langage de plus haut niveau d'abstraction que Pig. La proximité de Hive au SQL fait que si vous le maîtrisez, vous êtes opérationnels de suite sur l’exploitation d’un cluster. C’est pourquoi après la lecture de cette partie, vous serez opérationnels dans l’utilisation d’un cluster Hadoop.

2.1 – Ecriture des requêtes Hive

Hive fournit un langage de requête basé sur le SQL (norme ANSI-92) appelé HiveQL (Hive Query Language), qui est utilisé pour adresser des requêtes aux données stockées sur le HDFS. Le HiveQL permet également aux utilisateurs avancés/développeurs d’intégrer des fonctions Map et Reduce directement à leurs requêtes pour couvrir une plus large palette de problèmes de gestion de données.

Nous allons maintenant vous montrer concrètement comment écrire des requêtes HiveQL. Nous n’allons pas entrer dans les détails de la programmation HiveQL, car c’est hors des objectifs de l’ebook, par contre nous allons vous donner le schéma général d’écriture des requêtes d’un problème en HiveQL et les scripts dont vous aurez besoin pour écrire dans l’immédiat des requêtes simples. Lorsque vous voulez écrire des requêtes HiveQL, voici en général l’ensemble des étapes que vous devez respecter. Nous allons illustrer ces étapes à l’aide d’un exemple. Considérons le fichier suivant :

1. la première étape dans l’écriture de la requête consiste à définir la base de données dans laquelle sera stockée la table de référence dans le catalogue, HCatalog. HCatalog possède une base « default » qui est utilisée par défaut pour le stockage des métadonnées. L’instruction suivante définit la Base de Données de catalogue :

USE default ;

Ou alors, vous pouvez de créer une nouvelle base de données en utilisant l’instruction CREATE DATABASE. Par exemple : CREATE DATABASE clients ;

2. la deuxième étape consiste à créer une table intermédiaire dans la base de catalogue. Cette table va pointer vers les données de tous les fichiers sources que vous voulez traiter. Pour ce faire, vous utiliserez une instruction CREATE TABLE.

CREATE TABLE IF NOT EXISTS log_clients(

id_client STRING,

Nom_client STRING,

prenom_client STRING,

Noms_client STRING,

date_naissance DATE,

genre STRING,

produit_achete STRING,

Qantité TINYINT,

Prix_unitaire STRING

) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t',

STORED AS TEXTFILE;

Dans le cas de notre exemple, cette instruction crée une table log_clients contenant toutes les colonnes du fichier source. L’instruction ROW FORMAT DELIMITED FIELDS TERMINATED BY permet de préciser le code ANSI du séparateur de colonnes (la tabulation dans notre cas) dans le fichier source, et l’instruction STORED AS permet de spécifier le format sur lequel le fichier est sérialisé dans le HDFS (ici c’est un fichier plat classique). Par ailleurs, HiveQL fournit des mots clés comme STRING, DATE, INT, TINYINT pour la gestion des types de données simples. Des types plus complexes comme les formats JSON, les nombres binaires, les paires de clés/valeurs, les tableaux peuvent également être typés en HiveQL à l’aide des mots clés respectifs STRUCT() BINARY(), MAP(), et ARRAY().

3. la troisième étape consiste à charger les données du HDFS dans la table intermédiaire. Le chargement de données du HDFS se fait à l’aide de l’instruction LOAD DATA.

LOAD DATA INPATH '/user/projetdemo/clients’ OVERWRITE INTO TABLE log_clients ;

Le chemin '/user/projetdemo/clients’ spécifie le chemin d’accès sur le HDFS du dossier contenant le ou les fichiers dont les données seront analysées. Le mot clé OVERWRITE permet d’écraser les données éventuelles qui pourraient être déjà présentes dans la table lors du stockage des nouvelles données.

4. la quatrième étape consiste à construire la table dont vous avez besoin pour vos analyses. Cette fois, vous devez spécifier à partir de la table intermédiaire les calculs nécessaires pour obtenir les colonnes dont vous avez besoin. Supposons dans notre exemple que nous voulons les colonnes suivantes :

  • la colonne « Noms du client », obtenue par concaténation des colonnes « nom_client » et « prenom_client » ;

  • la colonne « Sexe », obtenue par l’extraction de la première lettre de la colonne « genre » ;

  • la colonne « age_client », obtenue par différentiel de date entre la colonne « date_naissance » et la date d’aujourd’hui ;

  • la colonne « vente », obtenue par multiplication des colonnes « prix » et « quantité » ;

CREATE TABLE IF NOT EXISTS Clients AS

SELECT

id_client STRING,

concat (Nom_client,' ', prenom_client) Noms_client

datediff (date_naissance, CURRENT_DATE()) Age_client,

Substr (genre, 1, 1) genre,

Qantité * Prix_unitaire Vente

FROM log_clients ;

5. la dernière étape enfin, consiste à effectuer vos analyses sur la table que vous venez de créer. Pour ce faire, vous utiliserez une instruction SELECT classique. Supposons que dans notre exemple, nous souhaitons obtenir la somme des ventes par genre des clients qui ont entre 25 et 30 ans. Nous obtiendrons la requête suivante :

SELECT sum (vente) FROM Clients WHERE cast (age_client as int) BETWEEN 25 AND 30 GROUP BY genre;

L’ensemble du programme Hive qui résout notre problème est le suivant :

USE default ;

CREATE TABLE IF NOT EXISTS log_clients(

id_client STRING,

Nom_client STRING,

prenom_client STRING,

Noms_client STRING,

date_naissance DATE,

genre STRING,

produit_achete STRING,

Qantité TINYINT,

Prix_unitaire STRING

) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t',

STORED AS TEXTFILE;

LOAD DATA INPATH '/user/projetdemo/clients’ OVERWRITE INTO TABLE log_clients ;

CREATE TABLE IF NOT EXISTS Clients AS

SELECT

id_client STRING,

concat(Nom_client,' ', prenom_client) Noms_client

datediff(date_naissance, CURRENT_DATE()) Age_client,

Substr(genre, 1, 1) genre,

Qantité * Prix_unitaire Vente

FROM log_clients ;

SELECT sum(vente) FROM Clientss WHERE cast(age_client as int) BETWEEN 25 AND 30 GROUP BY genre ;

Comme vous pouvez le voir, il est relativement simple d’exprimer ses requêtes en HiveQL. L’utilisateur métier se retrouve alors en train d’exploiter tout un cluster et de faire du MapReduce sans en faire ! Si vous n’êtes pas convaincu de cela ou si vous préférez apprendre à écrire vos requêtes en Java, alors laissez-nous vous montrer l’exemple classique du comptage des mots en MapReduce.

le comptage des mots (word Count) est très souvent utilisé comme le "Hello world" de la programmation MapReduce à cause de la simplicité de sa compréhension. Le programme Java suivant est une implémentation du comptage des mots qui est fourni dans les bibliothèques d’Hadoop lorsque vous le téléchargez. Si vous n'aimez pas le Java, pas de soucis, car nous avons mis ce code uniquement pour vous montrer la différence en termes de taille qu'il y'a entre l'écriture des scripts MapReduce en Java et l'écriture des scripts MapReduce en HiveQL.

Figure 8 : Script MapReduce du WordCount écrit en Java

Au total 63 lignes de code. Le même script écrit en HiveQL donne ceci :

CREATE TABLE docs (line STRING);

LOAD DATA LOCAL 'c:/documents/clients.csv' OVERWRITE INTO TABLE docs;

CREATE TABLE word_counts AS

SELECT

word, count(1) AS count

FROM

(

SELECT explode(split(line, '\s')) AS word

FROM docs

) w GROUP BY word ORDER BY word ;

3 – Pig

Il a été réalisé que le potentiel d'Hadoop ne pouvait pas être déployé si les opérations courantes nécessitaient toujours les développeurs Java hautement qualifié pour leur programmation. Chez Yahoo !, l'équipe d'ingénieurs Hadoop a eu l'impression qu'une solution basée sur le SQL ne pouvait pas suffisamment couvrir la complexité de la programmation de certaines tâches MapReduce. Par voie de conséquence, Yahoo ! a créé un langage qui maximise la productivité des analystes de données (un public non-développeur), tout en offrant le support nécessaire pour l'expression des opérations MapReduce complexes. Cette solution c'est Pig.

Au même titre que Hive, Pig est avant tout un langage d’abstraction qui permet d’exprimer ses requêtes selon un style de programmation fonctionnelle proche du SQL. Tout comme Hive, il transforme ces requêtes en arrière-plan en jobs MapReduce.

Formellement, Pig est un environnement d'exécution de flux interactifs de données sous Hadoop. Il est composé de 2 éléments :

  • un langage d'expression de flux de données appelé le Pig Latin ;

  • et un environnement Interactif d'exécution de ces flux de données ;

3.1 – Ecriture des requêtes en Pig

Le langage offert par Pig, le Pig Latin, est à peu près similaire au langage de Scripting tels que Perl, Python, ou Ruby. Cependant, il est plus spécifique que ces derniers et se décrit mieux sur le terme "langage de flux de données" (data flow language). Il permet d'écrire des requêtes sous forme de flux séquentiels de données source pour obtenir des données « cible » sous Hadoop à la façon d'un ETL. Ces flux sont ensuite transformés en fonctions MapReduce qui sont enfin soumises au jobtracker pour exécution. Pour faire simple, Pig c'est l'ETL d'Hadoop. Programmer en Pig Latin revient à décrire sous forme de flux indépendants mais imbriqués, la façon dont les données sont chargées, transformées, et agrégées à l’aide d’instructions Pig spécifiques appelées opérateurs. La maîtrise de ces opérateurs est la clé de la maîtrise de la programmation en Pig Latin, d’autant plus qu’ils ne sont pas nombreux relativement au Hive par exemple. L’exemple précédent en HiveQL donne ceci en Pig Latin :

log_clients = LOAD '/user/projetdemo/clients/’ USING PigStorage (‘\t’) AS (id_client: int, Nom_client : chararray, Prenom_client :chararray, date_naissance : datetime, Genre: chararray, Produit_achete : chararray, Qantite: int, Prix_unitaire: float);

Clients = FOR EACH log_clients GENERATE id_client, concat(Nom_client,' ', prenom_client) AS Noms_client, YearsBetween(date_naissance, CURRENT_TIME()) AS Age_client, Substr(genre, 1, 1) AS Sexe_client, Qantité * Prix_unitaire AS Vente;

clients25_30 = FILTER Clients BY (Clients >= 25 AND Clients <= 30);

clients25_30_groupes = GROUP clients25_30 BY genre ;

Ventes = FOR EACH clients25_30_groupes GENERATE genre, sum(vente) ;

DUMP Ventes ;

3.2 – Rétro-ingénierie du Hive à Pig

Pour mieux vous aider à comprendre les opérateurs de Pig Latin, nous allons faire un reverse engineering du script Hive que nous avons développé précédemment. A titre informatif, le reverse engineering est une pratique informatique qui consiste à déterminer le fonctionnement d'un logiciel sans avoir accès aux spécifications techniques officielles. A partir du comportement du programme, on infère son code et on l'utilise pour créer un programme similaire. En français, on parle de rétro-ingénierie. C’est une très bonne méthode pédagogique pour apprendre le fonctionnement d’un logiciel.



La figure suivante récapitule les changements qui se sont produits du passage de HiveQL à Pig Latin, les instructions Pig Latin et leurs équivalence en HiveQL.

Nous allons conclure cette partie sur les langages d’abstractions disponibles sur Hadoop avec un petit mot sur la différence entre Hive et Pig. Tout d’abord, gardez à l’esprit que tous deux sont des langages d’abstraction, ils ont pour but d’éloigner le public non-développeur (les analystes métier) de la complexité de la programmation des tâches Map et Reduce dans un langage tel que Java. L’atteinte de ce but a pour inconvénient de prolonger le temps de latence de l’exécution des jobs MapReduce qui en résultent que ce soit aussi bien pour Hive que pour Pig. C’est à cause de cela que la fondation Apache a développé un autre langage d’abstraction, mais cette fois-ci très proche du MapReduce appelé Cascading qui offre un style de programmation très similaire à Pig Latin, mais en Java. Vous vous doutez bien que Cascading n’est presque pas utilisé par le public qu’il ciblait originellement (les analystes métier). Malgré l’avantage et inconvénient communs à Hive et Pig, il existe tout de même une différence fondamentale qui peut faire pencher la balance envers l’un ou l’autre. Le Pig Latin est un langage dans lequel l’utilisateur décrit le COMMENT des opérations à réaliser, tandis que HiveQL décrit simplement le QUOI et laisse le soin au système de faire le reste. A cause de ce mode de fonctionnement, Pig est plus complexe à programmer que HiveQL, ce qui fait que sa courbe d’apprentissage est globalement plus élevée que celle de Hive. Par contre, Pig Latin permet de couvrir une plus large palette d’opérations que le Hive. Donc, lorsque la question du choix se posera entre les deux, tenez en compte le niveau technique des utilisateurs (surtout leur niveau de programmation en SQL) et du niveau de complexité des opérations à réaliser.

Nous allons maintenant vous montrer comment aller au-delà du style SQL et écrire de véritables programmes massivement parallèles qui en plus s’exécutent très rapidement.

4 – Spark

Le MapReduce a réussi dans l'implémentation des applications de traitement de données à grande échelle sur des clusters d’ordinateurs commodes. Cependant il est bâti sur un modèle de flux acyclique direct (l’enchaînement des opérations du MapReduce s’exécutent en trois phases séquentielles directes et sans détour Map -> Shuffle -> Reduce, aucune phase n’est itérative ou cyclique) qui n'est pas adapté pour certaines applications, précisément celles qui réutilisent les données à travers de multiples opérations telles que la plupart des algorithmes d’apprentissage statistique, les travaux de Data Science, itératifs pour la plupart, et les requêtes interactives d'analyse de données. En réponse à cela, l’université de Berkeley a proposé un moteur appelé Spark, qui supporte ces applications toute en maintenant la scalabilité et la tolérance du cluster. Spark est aujourd’hui une technologie majeure dans le traitement à grande échelle de données. Dans ce point, nous allons vous expliquer de façon sommaire les concepts de Spark ensuite, nous allons vous initier au développement en Spark en utilisant Scala.

4.1 – Définition de Spark

Spark est un modèle de calcul distribué In-Memory. Il a été conçu aussi bien pour le calcul Interactif que le calcul itératif. Spark affiche des performances qui sont 10 fois plus élevés que Hadoop sur les travaux itératifs (apprentissage statistique).

L’université de Berkeley a mené une expérience dans laquelle elle compara avec Spark et avec Hadoop sur la performance d'un job de régression logistique, un algorithme itératif de classification qui essaye de trouver une droite (un hyperplan pour être plus formel) qui sépare au mieux 2 ensembles de données. Pour ce faire, un fichier de 29 Go a été utilisé sur un cluster de 20 machines Amazon Cloud EMR EC2 M1.XLARGE possédant 4 CPU chacune. Les résultats sont là : avec Hadoop, chaque itération prend 127 secondes, tandis qu'avec Spark, la première itération prend 174 secondes, mais les itérations suivantes prennent 6 secondes seulement. Une autre expérience a été menée dans laquelle Spark a été utilisé pour charger 39 Go de fichiers Wikipedia en mémoire à travers un cluster de 15 machines EC2 M1.XLARGE et y effectuer des requêtes interactives. La première fois que la requête a été traitée, elle a mis 35 secondes pour être traitée par Spark. Cependant, les requêtes suivantes ont pris entre la demi-seconde et la seconde. Ces expériences montrent que sur les travaux itératifs et les travaux interactifs, Spark est de loin meilleur à Hadoop ! Dans cette partie nous allons vous emmener à comprendre pourquoi c’est le cas et la clé de sa performance.

Figure 15 : Performance d'une régression logistique dans Spark et Hadoop (expérience de l’université de Berkeley).

Attention ! Spark n'est pas un paradigme de programmation comme le MapReduce, Spark est un moteur de calcul distribué qui supporte les applications itératives et interactives tout en conservant la scalabilité et la tolérance aux pannes d'un cluster Hadoop. Concrètement, c'est une couche logicielle installée sur un cluster, qui lui permet d'effectuer des traitements de données en mémoire tout en conservant les attributs de Scalabilité, de répartition de charge et de tolérance aux pannes qu'on retrouve dans un cluster Hadoop. C’est pourquoi on dit de Spark qu’il est un moteur de calcul In-Memory distribué. In-Memory distribué ne veut pas dire que la mémoire est partagée ou que l’architecture du cluster est de type Shared-Memory. Non, le cluster est toujours de type Shared-Nothing, mais les calculs sont exécutés dans la mémoire RAM de chaque nœud du cluster. Comment cela fait-il ?

Pour atteindre ce but, Spark introduit une abstraction appelée le RDDResilient Distributed Dataset (jeu de données distribué et résilient). Un RDD est une collection d'objets accessible en lecture-seule (c’est-à-dire non-modifiable) partitionnée et distribuée à travers les nœuds d'un cluster. Les RDD sont conservés en mémoire dans les nœuds du cluster, et réutilisés dans chaque opération parallélisée. Les RDD sont résilients, c’est-à-dire qu’en cas de panne du nœud, ils peuvent être reconstruits automatiquement. Des opérations de type MapReduce ou non peuvent être exécutées sur les RDD de façon distribué et parallèle.

Nous allons maintenant vous initier à la programmation en Spark.

4.2 – tutoriel Spark Scala

Spark peut être exploité à l'aide de l’un des trois langages de programmation suivant : Scala, Java et Python. Il serait difficile de vous conseiller exactement sur lequel de ces langages vous devez apprendre si vous souhaiter maîtriser Spark, cependant vous devez savoir que Spark a été développé en Scala. Scala est donc son langage par défaut. De plus, Scala étant un langage de programmation fonctionnelle basée sur Java, il se prête très bien au style fonctionnel de la programmation des RDD Spark. En plus, sa programmation y est très riche, simple et élégante. Python est plus simple à programmer de tous les trois en matière de syntaxe, donc vous pouvez également l’utiliser si vous ne souhaitez pas entrer dans la complexité de la programmation. Il est également important de noter qu’il existe des différences de syntaxe notables entre la programmation dans ces trois langages. Cependant, l’approche, les classes et les principes de Spark y restent les mêmes. Pour notre ebook, nous allons programmer Spark en Scala.

Que ce soit Java, Scala ou Python, la programmation en Spark consiste à effectuer des transformations sur ses RDD via ses méthodes et ses propriétés. En effet, Spark expose (met à disposition des utilisateurs) les RDD à travers l'API du langage de programmation que vous aurez choisi, dans lequel chaque jeu de données est représenté comme un objet et les transformations sont invoquées en utilisant les méthodes de ces objets. Néanmoins, les RDD sont indépendants des langages de programmation. L’écriture d’un programme en Spark commence par la définition d’une ou de plusieurs RDD à travers des transformations soit sur des fichiers de données localisées ou non sur le HDFS, soit alors sur des instances de RDD existants (persistés en mémoire ou sérialisés sur le disque dur), et finit par l’utilisation des "actions" (les méthodes des transformations), qui sont en fait des fonctions qui retournent une valeur à l'application. Un exemple d'action inclut la méthode "count()" qui retourne le nombre d'éléments dans le jeu de données, "collect()" qui retourne les éléments eux-mêmes, "for each :" qui boucle les données dans une fonction fournie par l’utilisateur ou encore "persist()" qui persiste un RDD en mémoire.

Pour utiliser Spark, vous commencer par l’instancier via un "Spark driver" (pilote Spark), qui est un peu l'équivalent d'un "Job MapReduce" en Hadoop. Ce pilote Spark se connecte aux processus Workers qui tournent au niveau des nœuds de données du cluster, ensuite vous définissez un RDD sur lequel déclencher une ou plusieurs actions. Supposons le fichier clients.csv que nous avons utilisé plus haut lors de l’étude sur Hive. Vous souhaitez effectuer quelques transformations sur les données, ensuite calculer la somme des ventes par produit pour les clients de sexe féminin et âgés de plus de 24 ans. Sans rentrer dans les détails de configuration et la programmation en scala, le programme scala Spark suivant permet d'atteindre cet objectif. Attention ! La version de Spark utilisée ici la 1.6.

Dans la première étape, vous importez les classes Spark qui contiennent les méthodes dont vous aurez besoin. Cela se fait à l’aide de l’instruction import.

import java.util.{Date, Locale}

import java.text.DateFormat._

import org.apache.spark.sql.DataFrame

import org.apache.spark._

import org.apache.spark.sql.functions._

import org.apache.spark.sql.types._

import org.apache.spark.sql.DataFrame

import org.apache.spark.sql.SQLContext

import org.apache.spark.sql.hive.HiveContext

Deuxième étape, vous créez un singleton (une classe qui possède une seule instance) qui va contenir l'ensemble du programme Spark. Dans le cadre de notre tutoriel, appelons-le SparkTuto(). C'est désormais dans ce singleton que toutes les fonctions du programme vont être écrites. Dans ce singleton, vous créez une fonction f_clients, qui va être appelée pour effectuer les calculs proprement dits.

object SparkTuto {

def f_clients : DataFrame = {

}

}

Troisième étape, vous instanciez un contexte Spark ou un pilote Spark.

val conf = new SparkConf()

val sc = new SparkContext(conf)

Quatrième étape, vous instanciez le module Spark SQL, que vous utiliserez pour vos calculs.

val sqlContext = new sqlContext(sc)

Cinquième étape, vous créez un objet Data Frame, une abstraction de la structure de nos données.

val df : Dataframe = sqlContext.read

.option("header", "true") .csv("clients.csv")

val df_client : DataFrame = df

.select(

col("id_client").cast(StringType)

,col("Nom_client").cast(StringType)

,col("Prenom_client").cast(StringType)

,col("date_naissance").cast(DateType)

,col("Genre").cast(StringType)

,col("Produit_achete").cast(StringType)

,col("Quantite").cast(IntegerType)

,col("Prix_unitaire").cast(DoubleType)

Nous allons maintenant effectuer les transformations nécessaires pour atteindre notre objectif, à savoir :

  • concaténer le nom et le prénom du client dans la même colonne

  • calculer l'âge du client

  • déterminer le sexe du client

  • calculer le chiffre d'affaire unitaire pour chaque achat.

Pour créer ces nouvelles colonnes, nous utilisons l’instruction withcolumn().

val df_client_transformed : DataFrame = df_client

.withColumn("Nom_clients", concat_ws(" ", col("Nom_client"), col("Prenom_client")))

.withColumn("Age_client", lit(datediff(current_timestamp(), col("date_naissance"))/365).cast(IntegerType))

.withColumn("sexe", substring(col("Genre"),1,1))

.withColumn("vente", lit(col("Prix_unitaire") * col("Quantite")))

Nous allons maintenant calculer la somme des ventes par produit pour les clients de sexe féminin et âgés de plus de 24 ans.

val df_client_aggr : DataFrame = df_client_transformed.

.filter(col("sexe") === "F" && col("Age_client") > 24)

.groupby(col("Produit_achete"))

.sum(col("vente"))

df_client_aggr.show()

Le programme complet donne ceci :

import java.util.{Date, Locale}

import java.text.DateFormat._

import org.apache.spark.sql.DataFrame

import org.apache.spark._

import org.apache.spark.sql.functions._

import org.apache.spark.sql.types._

import org.apache.spark.sql.DataFrame

import org.apache.spark.sql.SQLContext

import org.apache.spark.sql.hive.HiveContext


object SparkTuto {

val conf = new SparkConf()

val sc = new SparkContext(conf)

val sqlContext = new sqlContext(sc)


def f_clients : DataFrame = {

val df : Dataframe = sqlContext.read

.option("header", "true")

.csv("clients.csv")

val df_client : DataFrame = df

.select(

col("id_client").cast(StringType)

,col("Nom_client").cast(StringType)

,col("Prenom_client").cast(StringType)

,col("date_naissance").cast(DateType)

,col("Genre").cast(StringType)

,col("Produit_achete").cast(StringType)

,col("Quantite").cast(IntegerType)

,col("Prix_unitaire").cast(DoubleType)

val df_client_transformed : DataFrame = df_client

.withColumn("Nom_clients", concat_ws(" ", col("Nom_client"), col("Prenom_client")))

.withColumn("Age_client", lit(datediff(current_timestamp(), col("date_naissance"))/365).cast(IntegerType))

.withColumn("sexe", substring(col("Genre"),1,1))

.withColumn("vente", lit(col("Prix_unitaire") * col("Quantite")))

val df_client_aggr : DataFrame = df_client_transformed.

.filter(col("sexe") === "F" && col("Age_client") > 24)

.groupby(col("Produit_achete"))

.sum(col("vente"))

}

f_clients.show()


}

Voilà, avec ce code, vous avez un modèle simple pour démarrer l’écriture de vos programmes de traitement de données sous Spark. Nous allons maintenant passer à l’étude de HBase.

5 – HBase

Avant de parler de HBase, rappelons que les SGBDR, qui sont jusqu’à présent utilisés pour la gestion des données ont montré très rapidement leurs limites face d'une part la forte volumétrie des données et d'autre part face à la diversité des données. En effet, les SGBDR sont conçus pour gérer uniquement des données structurées (table de données en ligne/colonnes), de plus l'augmentation du volume des données augmente le temps de latence des requêtes. Cette latence est préjudiciable dans le cadre de nombreux métiers requérant des réponses en temps quasi-réel. Pour répondre à ces limites, de nouveaux SGBD dit "NoSQL" ont vu le jour. La particularité de ceux-ci est qu’ils n’imposent pas de structure particulière aux données, sont capables de distribuer le stockage et la gestion des données sur plusieurs nœuds et sont scalables. A titre de rappel, la scalabilité signifie que la performance du système reste stable avec l’augmentation de la charge de traitement. HBase fait partie de cette catégorie de SGBD.


Continue reading this ebook at Smashwords.
Download this book for your ebook reader.
(Pages 1-41 show above.)