HADOOP, MAPREDUCE…
RETOUR SUR CES TECHNOLOGIES QUI ONT CHANGÉ LE VISAGE DE L’ANALYTIQUE

Hadoop, MapReduce, Yarn, Spark…

si ces noms n’évoquent rien au néophyte, ils rassemblent à leur seule évocation tous les fantasmes d’une décennie sur le traitement  généralisé des Big Data. Leur histoire est parfois amplifiée ou romancée (l’éléphant Hadoop et la fameuse peluche du fils de Doug Cutting…) pour apporter un peu de légèreté à la complexité de leur mode de fonctionnement. Mais, dix ans, après, l’écosystème Hadoop est toujours la norme et continue de fasciner.

 

Petite revue de tech.

UNE SI COURTE HISTOIRE…

La fondation Apache commence à travailler sur Lucene, outil d’indexation de textes supposé créer une bibliothèque open source à échelle mondiale.

Le besoin de créer un nouveau moteur de recherche de grande échelle se fait sentir pour collecter des données de divers contenus pdf, html, word, etc… : c’est le projet Nutch de la fondation Apache.

Jeffrey Dean et Sanjay Ghemawat, employés chez Google, créent l’algorithme MapReduce pour paralléliser les traitements de grands volumes de données sur plusieurs serveurs. MapReduce fonctionne alors sur Google File System.

Doug Cutting, qui a mené les projets Lucene et Nutch et travaille désormais chez Yahoo, combine un système de fichier distribué qu’il a créé (DFS) avec MapReduce et nomme ce framework Hadoop.

Yahoo décide de rendre le code d’Hadoop public et le lègue à la fondation Apache

Création des modules complémentaires : HBase, Hive, Pig, Zookeeper

La version 2 d’Hadoop est disponible, intégrant des fonctionnalités temps réel et un traitement in-memory grâce à la couche Yarn qui réduit l’utilisation de MapReduce au strict nécessaire

LA SILICON VALLEY EN POINTE SUR LA CREATION DU BIG DATA

QUELQUES BRIQUES DE L’ECOSYSTEME HADOOP

Extrait de « Maîtrisez l’utilisation des technologies Hadoop » par Juvénal Chokogoué

Extrait de « Maîtrisez l’utilisation des technologies Hadoop » par Juvénal Chokogoué

YARN

Principale évolution constatée de l’écosystème Hadoop, YARN (Yet Another Resource Negotiator) permet à Hadoop d’utiliser d’autres modes de calcul que MapReduce et ainsi de viser le temps réel en dépassant le modèle de traitement en batch. Sa fonction : optimiser l’utilisation des ressources du cluster et les partager entre plusieurs modes de calcul. Ce changement fondamental dans le paradigme Hadoop a permis l’ouverture des plateformes vers le temps réel, le streaming et le in-memory.

 

SPARK

C’est un moteur de calcul in-memory parallélisé particulièrement efficace pour le traitement des tâches répétitives (notamment à l’œuvre dans les travaux de machine learning). Il permettrait d’accélérer les traitements Hadoop standards jusqu’à cent fois. Parmi ses modules applicatifs, Spark Streaming, qui permet d’utiliser des données produites au fil de l’eau, serait l’un des plus en vogue…

 

TEZ

Tez vise avant tout à optimiser MapReduce pour limiter la latence générée par l’utilisation de langages d’exécution comme HiveQL ou Pig Latin. Il est capable pour chaque requête d’obtenir le chemin le plus court d’exécution et de stocker les données en mémoire, là où MapReduce fonctionne sur disque. Cependant, contrairement à Spark, il n’est pas utilisable sur les tâches de machine learning.

 

HBASE

SGBD NoSQL en colonne. Littéralement : système de gestion de bases de données complexes (ne relevant pas du SQL), orienté en colonnes pour le requêtage. C’est l’un des premiers outils à avoir vu le jour pour entreposer les données diverses sans forcément recourir à des outils d’indexation en amont… particulièrement pratique pour les gros volumes ! La fonction première d’HBase est de stocker des données et de permettre un accès facilité et temps réel à celles-ci via l’écosystème Hadoop.

 

ZOOKEEPER

Outil de coordination plébiscité par les développeurs, Zookeeper supervise les échanges entre les nœuds d’un cluster, permettant ainsi aux données et aux modules (HBase, Storm, etc.) de se synchroniser lors d’exécutions de calculs parallèles. Il est particulièrement efficace pour enlever aux développeurs le souci d’une panne… leur permettant ainsi de se concentrer sur le codage de leurs applications métiers.

 

HIVE

Hive est l’un des tout premiers outils qui ait cherché à faciliter l’expérience de l’utilisateur en développant un langage proche du SQL (syntaxe HiveQL) pour effectuer des requêtes de calcul MapReduce.

 

PIG

Dans le même esprit que Hive, les créateurs de Pig ont développé un langage, Pig Latin, permettant un accès simplifié aux requêtes pour tous types d’utilisateurs (développeurs comme non-développeurs). Son champ d’action reste cependant plus important que Hive sur la complexité des requêtes (mais son utilisation requiert un travail de formation et d’apprentissage).

 

STORM

C’est un système qui combine gestion en streaming et traitement en streaming pour résoudre totalement les problèmes de latence sur Hadoop. Le principal avantage de Storm est d’avoir ouvert les calculs en stream à un vaste champ d’utilisateurs métiers et à des problématiques de flux (utile pour les réseaux sociaux par exemple).

 

FLUME

L’idée de ce type d’outil est de permettre le transfert sous Hadoop de gros volumes de données de streaming. Cela permet notamment d’intégrer au fil de l’eau des données externes mais aussi internes pourvu qu’un système d’accès de type data lake ait été mis en place.

JUVENAL

CHOKOGOUÉ

 

auteur et Lead Data Engineer en

prestation à la Société Générale

Interview

1/ Va-t-on un jour dépasser Hadoop ?

Depuis l’invention d’Hadoop et le passage d’une approche centralisée à une approche distribuée, il faut bien le dire : peu de paramètres ont évolué dans l’outil. Yarn et Spark ont été les développements les plus notables, avec un objectif d’accélération des traitements, mais cela fait déjà 5 ans qu’ils ont vu le jour et les briques supplémentaires n’ont pas été particulièrement innovantes. Le socle, lui, est resté le même… et finalement ce n’est pas étonnant : une technologie révolutionnaire comme celle-ci nécessite au moins un cycle de dix ou vingt ans pour commencer à être dépassée. Hadoop a résolu les problèmes de latence et de volume, ce qui était sa raison d’être. Aujourd’hui, ce sont les challenges applicatifs qui ont pris le relais et c’est donc au niveau de l’écosystème (et non de la plateforme) Hadoop que se jouent désormais les prochaines avancées. On n’a pas besoin d’Hadoop pour faire de l’IA, mais on a besoin de Spark, Kafka ou encore Samza !

 

2/L’IA, l’IoT, la Blockchain… est-ce-que ces technologies sont susceptibles de bousculer l’écosystème Hadoop ?

Hadoop n’est pas une fin en soi et le passage aux objets connectés va probablement amener un changement de paradigme car HDFS est un traitement sur disque qui induit une latence inappropriée pour les volumes à gérer. Ce seront vraisemblablement les briques de traitement streaming (Spark Streaming, Storm, Kafka) qui assureront le travail directement dans le capteur ou sur un hardware récepteur. Mais pour l’instant, même s’il y a des travaux engagés sur ces questions, aucun éditeur ne prend le risque de packager une offre.

Quant à la Blockchain, Hadoop est tout à fait approprié pour assurer les traitements dans le framework global. Idem pour l’IA bien sûr…

 

3/… Et l’Open Source ?

L’Open Source a été au cœur du projet Big Data et on peut encore en mesurer ses bénéfices. Libérer la recherche de sa dimension commerciale, tout en favorisant un modèle communautaire, c’était la meilleure façon de booster l’innovation. Il faut continuer dans cette voie : je suis persuadé que les prochains développements viendront encore de l’Open Source…

 

4/ A-t-on réussi à mettre Hadoop au niveau des métiers ?

C’est vrai que la première préoccupation des entreprises a été de mettre Hadoop au niveau la DSI et des Data Analystes pour entrer tout de suite dans le vif du sujet. C’est aussi pour cela qu’ils ont eu tendance à plugger l’écosystème Hadoop sur des architectures existantes. Et puis, une fois passée l’euphorie, ils se sont rendu compte que c’était l’utilisateur métier qui définissait l’adoption ou non de la technologie. C’est pour cela qu’il faut absolument qu’Hadoop se transforme pour être compatible SQL : la plupart des analystes travaillent encore avec ce mode de requête, voire même sur Excel ou VBA. Et l’autre condition pour qu’Hadoop soit totalement adopté au niveau opérationnel, c’est que l’on donne accès à l’ensemble des données en un point unique qui soit… Hadoop (et non une infinité de data warehouses en silos), comme le proposent les data lake actuellement.

 

5/ Justement, vaut-il mieux privilégier une approche data lake ou une approche Cloud ?

Concrètement, s’ils veulent intégrer Hadoop dans leurs process, les DSI ont 3 stratégies qui se présentent : une intégration verticale, une intégration horizontale ou le Cloud.

L’intégration verticale, elle consiste à acheter Hadoop dans une solution en package qui comprendra tous les modules que l’on a déjà évoqués. Le problème sera alors celui de la compatibilité avec les technologies de l’entreprise car il faudra probablement du développement spécifique pour interfacer leur SI.

L’intégration horizontale, elle consiste à utiliser Hadoop seul et l’exploiter avec des technologies propriétaires. Forcément, cela offre de la flexibilité pour des entreprises qui ont déjà un gros capital technologique et des logiciel designés en interne selon des langages spécifiques… mais ce n’est pas accessible à tout le monde.

 

L’option Cloud semble alors la plus ouverte car elle permet d’utiliser Hadoop sans avoir à en supporter le coût ni la complexité. Pour les start-ups, c’est une façon de se lancer dans le Big Data et l’IA à moindre frais tout en laissant le temps à l’écosystème de mûrir. Reste à trouver une parade fiable à la question de la sécurité… un autre challenge pour les années qui viennent !

 

retour au sommaire