Getting Started with Hadoop : Part 1

Disclaimer : Ce billet est la première partie d’un article écrit pour la revue Programmez qui est en kiosque ce mois de Septembre  (n°144) et traite de la technologie Hadoop (une petite pause au milieu de la série consacrée à Node.js).

Avez vous déjà essayé d’indexer le web ? Non ? Et bien Google l’a fait, et le fait tous les jours. En quasi temps réel. Grande nouvelle me direz vous, on le sait depuis longtemps ! Mais ne vous êtes vous jamais demandé comment ? Avoir les plus grandes fermes de serveurs et embaucher les cerveaux les plus brillants ne suffit pas : il s’agit aussi de faire ça intelligemment ! Comment effectuer des traitements sur un ensemble de données de cette taille? La firme de Mountain View a partagé quelques uns de ses secrets en Décembre 2004 dans un whitepaper nommé “MapReduce: Simplified Data Processing on Large Clusters”. Un nom un peu barbare pour dévoiler les principes d’un algorithme simple, MapReduce, pour traiter des données sur des clusters de machines, mais sans en révéler les détails d’implémentation.

Qu’à cela ne tienne, quelques passionnés, Doug Cutting (créateur du projet Apache Lucene, un moteur d’indexation de documents) en tête, se mettent à réaliser une implémentation open source de MapReduce : Apache Hadoop était né ! L’objectif est alors pour Doug d’accélérer un autre de ses projets open source, le projet Apache Nutch, un moteur d’indexation web. Après quelques temps, une version de Nutch basée sur ce qui deviendra Hadoop, est rendue disponible. Et elle se révèle bien plus rapide et simple que la précédente. Yahoo pressent l’intérêt de la chose et va alors employer Doug. Ce dernier et une équipe travaille à plein temps sur le projet Hadoop (nommé d’ailleurs avec le surnom du jouet du fils de Doug, un éléphant qui est aussi devenu le logo). Aujourd’hui la détection de spam et l’indexation des sites web chez Yahoo se basent sur Apache Hadoop, dont la première release date de 2008.

Intérêt

Hadoop ne se destine pas à être utilisé en temps réel, c’est un outil qui vous permet d’effectuer vos traitements batchs. Il se base sur l’algorithme MapReduce afin d’effectuer le traitement de vastes volumes de données sur un serveur ou, et c’est toute sa puissance, sur un cluster de serveurs. Ce n’est pas une solution de stockage de données, et Hadoop ne s’inscrit donc pas dans la mouvance NoSQL, même si on les retrouve souvent associés en pratique (car pour traiter de grandes quantités de données, il faut déjà les stocker et c’est là que NoSQL a tout son sens). Ceci étant dit, quel intérêt pour vous et moi qui ne sommes ni Google, ni Twitter et qui ne possédons pas une ferme de serveurs ? Tout d’abord avec le prix de l’espace de stockage qui diminue, on serait bien tenté de stocker de plus en plus d’informations dans nos applications (de la donnée texte à la photo ou vidéo), et, pour les traiter, d’utiliser quelques serveurs au lieu d’un. Voire même d’utiliser la puissance du Cloud pour le faire grâce à son prix dérisoire, Amazon par exemple permettant de louer un serveur pendant une heure pour 0.085$. Ou peut être pour gagner en vitesse de traitement : au lieu d’acheter un magnifique serveur octocore, peut être que vos deux vieux serveurs qui prennent la poussière viennent de retrouver un intérêt…

Principe

Mais sur quoi repose ce modèle de traitement des données ? Tout s’articule sur le découpage de vos programmes en deux parties distinctes dont les exécutions vont être successives : la phase ‘map’ et la phase ‘reduce’. Le mapper est là pour filtrer et transformer les entrées en une sortie que le reducer pourra agréger une fois la première phase terminée, aboutissant alors au résultat souhaité, que ce soit un simple calcul statistique ou un traitement métier plus complexe. Ces deux phases ne sont pas issues de l’imaginaire des développeurs, mais bien des retours terrains constatés par les Googlers qui travaillaient sur ces problématiques.

Chaque phase est en fait une simple méthode, écrite en Java ou éventuellement dans votre langage préféré (Python, Ruby…), de traitement de données à implémenter. Lors de la première phase, MapReduce reçoit les données et donne chaque élément à traiter à chaque mapper (sur chaque noeud de votre cluster, soit de 1 à n machines). A l’issue de cette phase les données traitées sont redistribuées à chaque reducer (idem, chaque noeud de votre cluster, de 1 à n machines) pour arriver au résultat final.

Même si parfois découper votre traitement en deux phases vous semblera non trivial, une fois cette étape réalisée, passer l’exécution de votre programme sur un cluster de n machines ne sera pas plus compliqué qu’un changement de fichier de configuration. Quand vous écrivez votre programme en suivant le modèle MapReduce, Hadoop se charge ensuite pour vous de passer à l’échelle supérieure.

Si nous n’utilisions pas un framework comme Hadoop, nous devrions aussi écrire une fonction de partitionnement pour répartir les données entre les différents noeuds, une autre méthode pour les redistribuer entre les deux phases, gérer le load-balancing, les possibles échecs de traitement, les inévitables pannes matérielles serveur, etc… Beaucoup de travail pas forcément passionnant !  Mais Hadoop se charge là aussi des tâches ingrates et les optimise probablement mieux que ce que nous aurions pu faire. En résumé, écrire un programme Hadoop est donc aussi simple qu’écrire une méthode Map et une méthode Reduce, et à vous la scalabilté !

Dans un programme MapReduce, aucune valeur n’est traitée sans une clé associée. Les fonctions map et reduce ne reçoivent pas de simples données mais des paires (clé, valeur). Même chose pour les données sortantes des fonctions. Le mapper peut produire 0, 1 ou n couples (clé, valeur) pour un couple (clé, valeur) entrant. Le reducer, lui, va réduire une liste de couples (clé, valeur) produite par les mappers en une seule valeur par clé.

To be continued : si vous êtes impatient, foncez au bureau de presse le plus proche. Sinon je mettrai en ligne la suite dans quelques temps. Ce numéro de Programmez contient également un article de @AgnesCrepet, mon amie JDuchess, sur le BDD (si vous ne savez pas ce que c’est vous avez deux bonnes raisons d’acheter ce numéro). Et c’est un très bon article, écrit avec Mauro Talevi, commiter JBehave, je ne le dis pas juste parce que c’est une amie!