Introduction à Hadoop et son écosytème

Vous souhaitez utiliser Hadoop et son écosystème dans votre projet Big Data ?  Vous êtes au bon endroit  ! 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.  Pour réussir à exploiter les « Big Data », l’idée n’est plus de centraliser le stockage et le traitement des données sur un serveur, mais de distribuer leur stockage et de paralléliser leur traitement sur plusieurs ordinateurs. Cela est possible aujourd’hui grâce à Hadoop. Hadoop est resté pendant longtemps entre les mains de l’open source. Mais aujourd’hui, il est en passe de devenir le standard de facto de traitement de données dans les entreprises, un peu comme Microsoft Excel est progressivement devenu le logiciel par défaut d’analyse de données. Malgré cette position, nombreuses sont encore les entreprises qui ne comprennent pas comment utiliser Hadoop pour leurs projets Big Data. Dans cette chronique, nous allons vous indiquer comment utiliser hadoop et son écosystème technologique dans un projet Big Data.

1 – Hadoop et le Big Data : une histoire d’amour

Vous devez comprendre qu’avant Hadoop, l’approche stratégique utilisée par les entreprises pour gérer leurs données consistait à centraliser le stockage et le traitement des données sur un serveur central dans une architecture client/serveur. Ces données sont gérées dans le serveur par un SGBDR (type Oracle, SQL Server, BD 2, etc).  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, HP ou encore Lenovo. La croissance des données de l’entreprise était gérée par upsizing du serveur, c’est-à-dire par augmentation de la capacité physique de ses composants. Par exemple, l’augmentation de la mémoire, de 124 Go à 256 Go, l’augmentation de la fréquence du processeur, de quadri-core 3 Ghz à Quadri-core 5 GHz, ou l’augmentation de la capacité de stockage du disque dur de 500 Go à 2 To.  La figure suivante illustre cette stratégie.

architecture-client-serveur-hadoop
Figure : approche traditionnelle de gestion des données. Le stockage et le traitement des données sont centralisées dans un serveur.

Malheureusement, bien que de nombreuses entreprises gèrent encore leurs données selon cette stratégie, celle-ci pose plusieurs problèmes dans le contexte actuel :

  • l’échelle de croissance des données aujourd’hui surpasse la capacité raisonnable des technologies traditionnelles, ou même la configuration matérielle typique supportant les accès à ces données. La centralisation du stockage et du traitement des données sur un serveur central crée une pression importante sur l’architecture informatique de l’entreprise, ce qui par effet domino augmente le temps de réponse des requêtes aux clients (la latence). Cette augmentation de latence est préjudiciable dans le cadre de nombreux secteurs d’activités, notamment l’e-commerce, la banque de de détail, l’industrie, etc.
  • L’upsizing qui est utilisé pour rendre le serveur central capable de s’adapter à l’augmentation du volume de données (on parle de scalabilité) est limité à la capacité maximale des composants informatiques. Même si elle ne demande aucune modification sur l’architecture informatique, l’upsizing ne permet pas de dépasser les capacités inhérentes du matériel informatique. Par exemple, vous ne pouvez actuellement pas trouver sur le marché une barrette RAM de 500 Go. Pour atteindre cette capacité, il vous faut ajouter 8 barrettes de 64 Go, ce que la carte mère des serveurs ne prévoit pas toujours, en raison d’un nombre limité de slots. Ce raisonnement est valable pour l’upsizing du disque dur et du micro-processeur. L’upsizing augmente la scalabilité du système jusqu’à un certain seuil à partir duquel la performance du système reste la même.

Google fait partie des premières entreprises qui ont très tôt ressenti ces faiblesses. En 2002, son directeur général de l’époque Eric Schmidt, a envoyé une onde de choc dans toute l’industrie de l’IT en annonçant que Google n’avait aucune intention d’acheter le nouveau serveur d’HP doté du tout dernier microprocesseur Itanium développé par Intel. Dans la vision de Google, avec la baisse des coûts d’ordinateurs tels que prédits par 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 une nouvelle stratégie technologique qui va progressivement remplacer l’architecture client/serveur classique.  En 2002, cette vision technologique paraissait ridicule, mais aujourd’hui, elle fait sens. En effet, l’approche proposée par Google consiste à distribuer le stockage des données et à paralléliser leur traitement sur plusieurs PC commodes organisées en cluster (on parle de nœuds). La figure 2 illustre cette nouvelle stratégie. Hadoop est l’implémentation logicielle la plus mature qui permet de mettre en œuvre cette approche.

Plusieurs éditeurs logiciels ont tenté d’offrir des solutions qui implémentent la stratégie de distribution du stockage et de parallélisme de données, mais sans succès ! Les rares éditeurs qui ont réussi offrent des solutions qui coûtent une fortune ! (cela indique le niveau d’investissement important que nécessite le développement de telles solutions).  Hors mis les solutions particulières de SGBD Massivement parallèles de type Teradata, ou Hana,  Hadoop est actuellement la seule plateforme mature qui implémente avec succès la stratégie de distribution du stockage et de parallélisme de données. A la différence des solutions commerciales dont l’évolution dépend des investissements financiers de l’éditeur, Hadoop capitalise sur le vaste pool de ressources que représentent les communautés Open source (Apache, GitHub, Hacker News, Stack Overflow, etc…).

architecture-distribuée-hadoop
Figure : architecture distribuée – cluster computing. Le stockage des données est distribuée dans les noeuds d’un cluster et leur traitement y est parallélisé.

Ainsi, pour aborder des projets Big Data, d’un point de vue strictement architectural, la stratégie de distribution du stockage de données et de parallélisme de leur traitement sur un cluster est une bien meilleure stratégie que la stratégie d’architecture client/serveur classique. De plus, avec la baisse des coûts du matériel informatique, les coûts d’acquisition et d’évolution d’un cluster peuvent potentiellement revenir moins chers à terme que ceux d’un serveur central. Pour plus de détails sur Hadoop, vous pouvez consulter les articles de notre rubrique “Tutoriel Big Data

2- Composants de base d’un cluster Hadoop

Avec le temps, un véritable écosystème technologique s’est développé autour d’Hadoop pour supporter la multiplicité de cas d’usage de valorisation de données et la multiplicité sectorielle d’industrie. Hadoop est quitté d’un logiciel « one-size-fits-all », c’est-à-dire comme un logiciel qui va fournir toutes les fonctionnalités de tous les uses cases possibles du Big Data, à un véritable « framework », c’est-à-dire une plateforme de gestion de données sur laquelle peuvent être bâties des solutions spécifiques à des problématiques Big Data. Ainsi, lorsque vous lancer un projet en Big Data, gardez à l’esprit que l’acquisition d’Hadoop n’est que la première étape. Il faut déterminer (si elles existent) les solutions spécifiques qui peuvent vous aider à utiliser en levier la puissance d’Hadoop pour votre cas d’usage. Pour faire une analogie simple, le développement d’un cas d’usage avec Hadoop est similaire à l’assemblage de plusieurs puzzles LEGO. Il faut savoir combiner l’ensemble des outils de l’écosystème de manière à ce que cet ensemble réponde au besoin de la problématique de votre projet. A ce jour, l’écosystème Hadoop est composé d’une centaines de technologies que nous avons choisi de regrouper en 14 catégories selon leur segment de problématique. Nous y reviendrons plus bas. Mais ces technologies ont pour socle 3 composants de base :

  • Le système de fichier distribué, par exemple le HDFS d’Hadoop, qui gère le stockage distribué des données et fournit la tolérance aux pannes nécessaire lors de l’exploitation d’un cluster.
  • le modèle de calcul, comme MapReduce, qui est la façon dont les données sont parallélisés dans les noeuds du cluster
  • le gestionnaire de ressources, comme YARN, qui permet de faire tourner plusieurs moteurs de calcul dans le cluster et d’exploiter son potentiel à son maximum.

Le Système de fichier distribué, les modèles de calcul parallèle et l’application de gestion de ressources sont les 3 éléments qui sont à la base de toutes les technologies du Big Data.

Introduction à l’écosystème Hadoop

Hadoop est en passe de devenir le standard de Facto de traitement de données, un peu comme Excel est progressivement devenu le logiciel par défaut d’analyse de données. A la différence d’Excel, Hadoop n’a pas été conçu pour être utilisé par les « Analystes métier», mais par les développeurs. Or, l’adoption à grande échelle et le succès d’un standard ne dépendent pas des développeurs, mais des analystes métier. Pour cette raison, les problématiques de la Big Data ont été segmentées d’un point de vue fonctionnel et pour chaque segment, des technologies qui s’appuient sur Hadoop ont été développées pour répondre à ses challenges. L’ensemble de ces outils forment ce qui s’appelle l’écosystème Hadoop. L’écosystème Hadoop enrichit Hadoop et le rend capable de résoudre une grande variété de problématiques métiers. A ce jour, l’écosystème Hadoop est composé d’une centaines de technologies que nous avons choisis de regrouper en 14 catégories selon leur segment de problématique : : les langages d’abstraction, le SQL sur Hadoop (Hive, Pig), les modèles de calcul (MapReduce, Tez), les outils de traitement temps réel (Storm, Spark Streaming), les Bases de données (HBase, Cassandra), les outils d’ingestion streaming (Kafka, Flume), les outils d’intégration des données, (Sqoop, Talend), les outils de coordination de Workflow (Oozie, Control M for Hadoop), les outils de coordination de services distribués (Zookeeper), les outils d’administration de cluster (Ranger, Sentry), les outils d’interface utilisateur (Hue, Jupyter), les outils d’indexation de contenu (ElasticSearch, Splunk), les systèmes de fichier distribués (HDFS), et les gestionnaires de ressources (YARN et MESOS). Dans cette partie, nous allons passer en revue la fonction de chacun des outils qui constituent cet écosystème de technologies Big Data. Après, si vous souhaitez aller plus loin, nous vous recommandons de télécharger notre guide “Initiation à l’écosystème Hadoop” qui juste situé à votre droite. La carte heuristique suivante présente de façon globale l’écosystème Hadoop.

carte-heuristique-ecosysteme-hadoop
carte heuristique de l’écosystème Hadoop

La configuration de base de l’écosystème Hadoop contient les technologies suivantes : Spark, Hive, PIG, HBase, Sqoop, Storm, ZooKeeper, Oozie et Kafka.

Spark

Avant d’expliquer ce que c’est que Spark, rappelons que pour qu’un algorithme  puisse s’exécuter sur plusieurs nœuds d’un cluster Hadoop, il faut qu’il soit parallélisable. Ainsi, on dit d’un algorithme qu’il est “scalable” s’il est parallélisable (et peut donc profiter de la scalabilité d’un cluster). Hadoop est une implémentation du modèle de calcul MapReduce. Le problème avec le MapReduce est qu’il  est bâti sur un modèle de Graphe Acyclique Direct. En d’autres termes, 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). Le modèle acyclique direct n’est pas adapté à certaines applications, notamment celles qui réutilisent les données à travers de multiples opérations, telles que la plupart des algorithmes d’apprentissage statistique, itératifs pour la plupart, et les requêtes interactives d’analyse de données. Spark est une réponse à ces limites, c’est un moteur de calcul qui effectue des traitements distribués en mémoire sur un cluster. Autrement dit, c’est un moteur de calcul in-memory distribué. Comparativement au MapReduce qui fonctionne en mode batch, le modèle de calcul de Spark fonctionne en mode interactif, c’est à dire, monte les données en mémoire avant de les  traiter et est  de ce fait très adapté au  traitement de Machine Learning.

Hive

Hive est une infrastructure informatique similaire au Data Warehouse  qui fournit des services de requêtes et d’agrégation de très gros volumes de données stockées sur un système de fichier distribué de type HDFS. 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. Lorsque vous écrivez une requête en HiveQL, cette requête est transformée en job MapReduce et soumis au JobTracker pour exécution par Hive. Pour plus de détails sur Hive, consultez le tutoriel suivant : https://www.data-transitionnumerique.com/le-sql-dans-hadoop-hive-pig/

Pig

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 ;

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. Pour plus de détails sur Pig, consultez le tutoriel suivant : https://www.data-transitionnumerique.com/le-sql-dans-hadoop-hive-pig/

HBase

Avant de parler de HBase, nous allons rappeler 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. Ceux-ci 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. Cliquez sur le lien suivant pour un tutoriel complet sur HBase : https://www.data-transitionnumerique.com/tutoriel-hbase/

HBase est un SGBD distribué, orienté-colonne qui fournit l’accès en temps réel aussi bien en lecture qu’en écriture aux données stockées sur le HDFS. Là où le HDFS fournit un accès séquentiel au données en batch, non-approprié pour des problématiques d’accès rapide à la donnée comme le Streaming, HBase couvre ces lacunes et offre un accès rapide aux données stockées sur le HDFS.

 Il a été conçu à partir du SGBD de Google “Big Table” et est capable de stocker de très grosses volumétries de données (milliard de lignes/colonnes). Il dépend de ZooKeeper, un service de coordination distribuée pour le développement d’applications.

Sqoop

Sqoop ou SQL-to-Hadoop est un outil qui permet de transférer les données d’une base de données relationnelle au HDFS d’Hadoop et vice-verça. Il est intégré à l’écosystème Hadoop et est ce que nous appelons le planificateur d’ingestion des données dans Hadoop. Vous pouvez utiliser Sqoop pour importer des données des SGBDR tels que MySQL, Oracle, ou SQL Server au HDFS, transformer les données dans Hadoop via le MapReduce ou un autre modèle de calcul, et les exporter en retour dans le SGBDR. Nous l’appelons planificateur d’ingestion des données parce que tout comme Oozie (plus bas), il automatise ce processus d’import/export et en planifie le moment d’exécution. Tout ce que vous avez à faire en tant qu’utilisateur c’est d’écrire les requêtes SQL qui vont être utilisées pour effectuer le mouvement d’import/export. Par ailleurs, Sqoop, utilise le MapReduce pour importer et exporter les données, ce qui efficace et tolérant aux pannes.  La figure suivante illustre particulièrement bien les fonctions de Sqoop. Vous pouvez lire le tutoriel suivant pour voir comment Sqoop se positionne devant des ETL comme Talend : https://www.data-transitionnumerique.com/sqoop-vs-talend/

apache-sqoop-hdoop
Figure : Sqoop tourne autour de 2 activités répartis sur ses deux utilitaires, l’utilitaire d’import et l’utilitaire d’export.

Storm

Pour comprendre Storm, il faut comprendre la notion d’architectures lambda (λ) et pour comprendre l’intérêt des architectures lambda, il faut comprendre le concept d’objets connectés. Les objets connectés ou Internet des objets (IoT – Internet of Things en anglais) représente l’extension d’Internet à nos vies quotidiennes. Elle génère des données en streaming et dans la plupart de ses problématiques, nécessite que les données soient traitées en temps réel. Les modèles que vous connaissez tels que les modèles de calcul Batch  ne sont pas adaptés aux problématiques temps réel que soulève l’IoT.  Même les modèles de calcul interactif ne sont pas adaptés pour faire du traitement continu en temps réel. A la différence des données opérationnelles produites par les systèmes opérationnels d’une entreprise comme la finance, le marketing, qui même lorsqu’elles sont produites en streaming peuvent être historisées pour un traitement ultérieur, les données produites en streaming dans le cadre des phénomènes comme l’IoT ou Internet se périment (ou ne sont plus valides) dans les instants qui suivent leur création et exigent donc un traitement immédiat. En dehors des objets connectés, les problématiques métier comme la lutte contre la fraude, l’analyse des données de réseau sociaux, la géolocalisation, exigent des temps de réponse très faibles, quasiment de l’ordre de moins d’une seconde.Pour résoudre cette problématique dans un contexte Big Data, des architectures dites λ ont été mises sur pieds. Ces architectures ajoutent au MapReduce 2 couches de traitements supplémentaires pour la réduction des temps de latence. Storm est une implémentation logicielle de l’architecture λ. Il permet de développer sous Hadoop des applications qui traitent les données en temps réel (ou presque).

ZooKeeper

La synchronisation ou coordination de la communication entre les nœuds lors de l’exécution  des tâches parallèles est l’un des problèmes les plus difficiles dans le développement d’application distribuée. Pour résoudre ce problème, Hadoop a introduit dans son écosystème des outils ditsdecoordination de service, en l’occurrence ZooKeeper. ZooKeeper prend en charge la complexité inhérente de la synchronisation de l’exécution des tâches distribuées dans le cluster et permet aux autres outils de l’écosystème Hadoop de ne pas avoir à gérer ce problème eux-mêmes. Il permet également aux utilisateurs de pouvoir développer des applications distribuées sans être des experts de la programmation distribuée. Sans entrer dans les détails complexes de la coordination des données entre les nœuds d’un cluster Hadoop, ZooKeeper fournit un service de configuration distribué, un service de distribution et un registre de nommage pour les applications distribuées. ZooKeeper est le moyen utilisé par Hadoop pour coordonner les jobs distribués.

Oozie

Par défaut, Hadoop exécute les jobs au fur et à mesure qu’ils sont soumis par l’utilisateur sans tenir compte de la relation qu’ils peuvent avoir les uns avec les autres. Or, les problématiques pour lesquelles l’on utilise Hadoop demandent généralement la rédaction d’un ou de plusieurs jobs complexes. Lorsque les 2 jobs seront soumis au JobTracker (ou à YARN) par exemple, celui-ci va les exécuter sans faire attention au lien qui existe entre eux, ce qui risque de causer une erreur (exception) et entraîner l’arrêt du code. Comment fait-on pour gérer l’exécution de plusieurs jobs qui sont relatifs au même problème ?  Pour gérer ce type de problème, la solution la plus simple actuellement consiste à utiliser un planificateur de jobs, en l’occurrence Oozie.  Oozie est un planificateur d’exécution des jobs qui fonctionne comme un service sur un cluster Hadoop. Il est utilisé pour la planification des jobs Hadoop, et plus généralement pour la planification de l’exécution de l’ensemble des jobs qui peuvent s’exécuter sur un cluster, par exemple un script Hive, un job MapReduce, un job Hama, un job Storm, etc. Il a été conçu pour gérer l’exécution immédiate, ou différée de milliers de jobs interdépendants sur un cluster Hadoop automatiquement. Pour utiliser Oozie, il suffit de configurer 2 fichiers XML : un fichier de configuration du moteur Oozie et un fichier de configuration du workflow des jobs.

Voilà, vous avez maintenant une idée précise des technologies qui tournent autour de l’écosystème Hadoop et de l’état de l’art des technologie du Big Data. Nous espérons que vous avez compris qu’à l’ère du Big Data, la meilleure façon de valoriser ses données est d’utiliser un cluster sur lequel sera installé un système de fichiers distribué, un (ou plusieurs) modèle(s) de calcul parallèle(s), et un gestionnaire de ressources. Ensuite, vous pourrez choisir parmi la pléthore des technologies de l’écosystème Hadoop, celles qui correspondent au LEGO de votre projet. Bien évidemment, vous vous doutez bien qu’il n’est pas possible de couvrir extensivement un sujet aussi vaste que l’écosystème Hadoop d’un point de vue pragmatique.  C’est pourquoi, si vous souhaitez aller plus loin, nous vous recommandons les ressources suivantes.


Ressources complémentaires

Si vous souhaitez aller plus loin dans l’apprentissage de l’écosystème Hadoop, vous devez savoir que Apache est aujourd’hui dépositaire de toutes les technologies de l’écosystème et que de nombreuses autres technologies y sont en incubation. Rendez-vous sur les liens suivants pour plus d’informations concernant chacune de ces technologies.


Lectures recommandées

Vous travaillez sur un projet Big Data, nous vous recommandons de gagner en temps en lisant les ouvrages suivants :

Big Data et Machine Learning

Big Data et Machine Learning, 3ème édition, l’excellent livre de Dunod qui fournit un très bon panorama des technologies de l’écosystème Hadoop.

Hadoop, the definitive Guide

Hadoop, The Definitive Guide, 4ème édition, l’excellent ouvrage de Tom White des éditions Oreilly. Cet ouvrage couvre en profondeur les technologies principales de l’écosystème Hadoop. Il faut noter que Tom White travaille chez Cloudera et est lui-même très impliqué dans le développement des technologies Hadoop

maîtrisez l'utilisation des technologies Hadoop

Maîtrisez l’utilisation des technologies Hadoop“, le deuxième ouvrage du projet DTN. Il vous permet d’utiliser dans votre projet Big Data 18 technologies de l’écosystème Hadoop

Vous travaillez sur un projet Big Data en ce moment ? Vous avez des questions par rapport à l’écosystème Hadoop ? Ou une technologie Big Data en particulier ? Mentionnez-les ici bas, nous vous répondrons dans les plus brefs délais.