Hadoop expliqué aux développeurs en 7 questions

Voici un article qui résume toutes les questions qu’un développeur peut se poser sur Hadoop.

Qu’est-ce qu’Hadoop ?

Hadoop offre deux outils :

  • Un système de stockage de données dans un cluster appelé HDFS
  • Un outil pour paralléliser un traitement sur les données du cluster : MapReduce

Comment le système de stockage fonctionne-t-il ?

Lorsque vous ajoutez un document dans le système de fichier HDFS il est automatiquement dupliqué en 3 exemplaires sur le cluster, de manière transparente. Ainsi, si un serveur tombe, la donnée est toujours disponible.

Mieux, Hadoop prend même en compte la proximité des serveurs les uns avec les autres ; sont-ils dans le même rack de serveur ? Sont-ils dans le même Datacenter ? Grâce à cette connaissance de la topologie du réseau, Hadoop peut protéger la donnée des pannes de plus grandes ampleurs.

Hadoop gère donc le cluster comme un seul gros disque dur. Il garantit qu’aucune donnée ne pourra être perdue ou indisponible lorsque vous aurez besoin de les traiter.

Comment le traitement fonctionne-t-il ?

Lorsqu’une machine seule, même en utilisant tous ses threads, ne peut plus effectuer un traitement dans un temps acceptable, on décide de lancer ce traitement sur un cluster. Ainsi, chaque nœud du cluster effectue une partie du traitement. C’est là qu’Hadoop intervient.

Cependant, notre cluster est composé de plusieurs serveurs et l’échange de données entre ces serveurs est long. Il faut donc limiter au maximum les échanges réseau pendant le traitement.

C’est pourquoi le modèle Map Reduce est devenu populaire il y a quelques dizaines d’années. Il permet de partager un traitement entre plusieurs serveurs, chacun résolvant une partie du problème puis faisant remonter ses résultats. L’indépendance de chaque serveur lors du traitement est garant du minimum d’échange entre les serveurs.

Mais... Map Reduce n’est pas nouveau, si ?

Absolument, la parallélisation de traitements est depuis longtemps réalisée à l’aide du pattern Map Reduce. Cependant, Hadoop a apporté une nouvelle notion : la « data locality ».

Lorsque l’on décide d’appliquer un traitement sur le cluster, au lieu que la donnée soit transférée sur le ou les serveurs ayant le fichier jar de traitement, c’est le fichier jar qui est copié puis exécuté sur les serveurs ayant la donnée. Le raisonnement derrière cette pratique est simple ; le programme de traitement pèse quelques Mégaoctet alors que la donnée à traiter peut peser plusieurs Go. Il vaut mieux donc copier le programme plutôt que la donnée. De même, Hadoop ayant connaissance de la topologie du réseau, il va tenter tant que possible de diviser le traitement sur des serveurs physiquement proches les uns des autres. De la sorte, la récupération des résultats avant la phase de Reduce sera plus rapide.

D’un point de vue pratique, Hadoop a su rester simple en permettant aux développeurs d’implémenter un traitement Map Reduce en définissant uniquement deux fonctions : Map et Reduce. Pour autant, la configuration du cluster et le découpage des traitements sous forme de Map et Reduce ne sont pas toujours évidents.

Que sont les outils Hive, Pig, Flume ou Spark souvent cités avec Hadoop ?

Des outils peuvent s’interfacer facilement avec Hadoop pour en étendre les possibilités.

Nous avions évoqué plus haut la difficulté à décrire des traitements de données avec le pattern Map Reduce. Pour limiter cette difficulté, des outils comme Pig et Hive fournissent une syntaxe plus proche du SQL pour requêter les données du cluster. En tâche de fond, ce pseudo SQL sera converti en fonctions Map et Reduce. Une génération de code pas toujours idéale pour les performances, mais qui simplifie le développement.

D’autres outils peuvent se greffer à Hadoop pour faire du streaming (Flume), exécuter des traitements en favorisant la RAM plutôt que le HD (Spark) et bien d’autres.

Vous pouvez avoir un aperçu de l’écosystème Hadoop à cette adresse : https://hadoopecosystemtable.github.io.

Pourquoi cet engouement pour Hadoop ?

Il faut bien l’avouer, Google a donné un grand coup de communication sur le Big Data. Et cette frappe de départ a largement excité le monde des entreprises qui s’intéresse au Big Data sans réellement en voir les usages pour l’instant.

Pour autant, d’un point de vue technologique, Hadoop a l’avantage de pouvoir traiter efficacement des données sur un cluster de serveur traditionnel, avec une connexion réseau traditionnelle. Jusqu’à aujourd’hui des clusters, HPC par exemple, demandaient comme prérequis une infrastructure réseau coûteuse (InfiniBand vs. 1/10GigE). Le coût pour la mise en place d’un cluster est donc largement réduit. Ainsi, les clusters anciennement réservés aux centres de recherche sont devenus accessibles pour des entreprises lambda visant désormais à optimiser leur process interne, détecter des fraudes, personnaliser la relation client ou encore délivrer de nouveaux produits.

Cette diminution des coûts associée à la communication excessive autour du Big Data a conduit tous les grands groupes à se pencher sur la question et à mettre en place leur(s) cluster(s).

Quel volume de donnée doit-on traiter pour avoir un intérêt à utiliser Hadoop ?

La première chose à rappeler est qu’utiliser Hadoop pour une quantité de données trop faible est coûteux en infrastructure (gérer le cluster est complexe) et en temps (sur des petites quantités de données, Hadoop est plus lent qu’une approche plus traditionnelle).

Vient donc naturellement la question de la quantité de données nécessaires.

Il est important de préciser que nous parlons du volume de données nécessaire pour UN traitement. Ce n’est pas parce que votre entreprise dispose d’un To de données que vous avez besoin d’Hadoop. Vous ne réaliserez jamais un traitement qui utilise 100 % des données à votre disposition. En revanche, si le jeu de données nécessaire à votre traitement dépasse le To, vous pouvez commencer à envisager Hadoop.