HADOOP,MAP REDUCE... RETOUR SUR 10 ANS

D’INNOVATIONSTECHNOLOGIQUES

2

HADOOP,MAPREDUCE…

UNE SI COURTEHISTOIRE…

WWW.GUIDEDUBIGDATA.COM

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.

DÉBUT2000

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

2002

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

2004

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 ser-veurs. MapReduce fonctionne alors sur Google File System.

2006

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

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

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

2013 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

2 3

LA SILICON VALLEY ENPOINTE SUR LACREATION DUBIG DATA

QUELQUES BRIQUES DEL’ECOSYSTEME HADOOP

MapReduce, Google File System

Spark Hive

HDFS, Zookeeper

Kafka

Ecosystème Hadoop

Abstraction

Langage d'abstraction Hive

Pig

SQL

Phoenix

Hawq

Impala

Streaming

Ingestion streaming Kafka

Flume

Traitement streaming

Samza

Storm

Spark streaming

S4

Utilitaires

HUE

SCOOP

Oozie

Modèles de calcul

Interactif Spark

Tez

Batch

Mapreduce

Mahout

Hama

Stockage

BD distribuée HBase

Cassandra

Indexation de contenu

Lucene

ElasticSearch

Solr

Gestion

Gestion de ressources YARN

Mesos

Gestion des services ZooKeeper

Administration Ambari

Gestion de fichiers HDFS

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

3

4

HADOOP,MAPREDUCE…

WWW.GUIDEDUBIGDATA.COM

Hadoop Infrastructure

Interface Utilisateur HUE

Administration Ambari

Workflow Oozi

Coordination Zookeeper

Langage d'abstraction

Hive

Pig

Cascading

SQL

Impala

Phoenix

Hawq

Indexation de contenu

Lucene

Lucy

Solr

Intégration Sqoop

Temps réel

Storm

Samza

Spark Streaming

S4

Streaming Flume

Kafka

Gestionnaire de ressources YARN

MESOS

Modèles de calcul

MapReduce

Spark

Mahout

HAMA

Tez

Bases de données HBase

Cassandra

Système de fichier distribué HDFS

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

YARNPrincipale évolution constatée de l’écosys-tè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 clus-ter 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.

SPARKC’est un moteur de calcul in-memory paral-lélisé particulièrement efficace pour le trai-tement 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…

TEZTez vise avant tout à optimiser MapReduce pour limiter la latence générée par l’utilisa-

tion de langages d’exécution comme HiveQL ou Pig Latin. Il est capable pour chaque re-quê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.

HBASESGBD NoSQL en colonne. Littéralement : sys-tème de gestion de bases de données com-plexes (ne relevant pas du SQL), orienté en colonnes pour le requêtage. C’est l’un des premiers outils à avoir vu le jour pour entre-poser les données diverses sans forcément recourir à des outils d’indexation en amont… particulièrement pratique pour les gros vo-lumes ! 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’écosys-tème Hadoop.

ZOOKEEPEROutil de coordination plébiscité par les déve-loppeurs, Zookeeper supervise les échanges entre les nœuds d’un cluster, permettant ain-si aux données et aux modules (HBase, Storm, etc.) de se synchroniser lors d’exécutions de

calculs parallèles. Il est particulièrement ef-ficace pour enlever aux développeurs le sou-ci d’une panne… leur permettant ainsi de se concentrer sur le codage de leurs applications métiers.

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

PIGDans 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’ac-tion reste cependant plus important que Hive sur la complexité des requêtes (mais son utili-sation requiert un travail de formation et d’ap-prentissage).

STORMC’est un système qui combine gestion en streaming et traitement en streaming pour résoudre totalement les problèmes de latence

4 5

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

FLUMEL’idée de ce type d’outil est de permettre le transfert sous Hadoop de gros volumes de données de streaming. Cela permet notam-ment 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.

Inte

rvie

w

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 para-mè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 traite-ments, 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évolution-naire 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 rai-son 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 plate-forme) Hadoop que se jouent désormais les prochaines avancées. On n’a pas besoin d’Ha-doop 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 ame-ner 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 direc-tement 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 édi-teur 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’éco-système Hadoop sur des architectures exis-tantes. 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 abso-lument qu’Hadoop se transforme pour être compatible SQL : la plupart des analystes tra-vaillent 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 ni-veau 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 à ache-ter 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’entre-prise car il faudra probablement du dévelop-pement spécifique pour interfacer leur SI.L’intégration horizontale, elle consiste à utili-ser Hadoop seul et l’exploiter avec des tech-nologies propriétaires. Forcément, cela offre de la flexibilité pour des entreprises qui ont déjà un gros capital technologique et des lo-giciel 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 lais-sant 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 !

JUVENAL

CHOKOGOUÉ

AUTEUR ET LEAD DATA

ENGINEER EN

PRESTATION À LA

SOCIÉTÉ GÉNÉRALE

« Je suis persuadé

que les prochains

développements viendront

encore de l’Open Source »

5

Participez à Big Data Paris

les 11 & 12 mars 2019au Palais des Congrès

et profitez d’une opportunité

unique de vous informer et

networker avec l’ensemble

des acteurs de l’écosystème

Big Data.

Inscriptions surWWW.BIGDATAPARIS.COM/2019

HADOOP,MAP REDUCE... RETOUR SUR 10 ANS

D’INNOVATIONSTECHNOLOGIQUES