Hadoop 2 en version stable : quel intérêt pour vous ?

Ca y est, Hadoop 2, ou plus précisément la 2.1.0 est passée en version "bêta".

Et, plus intéressant, la sortie du four de la première version estampillée "stable", la 2.2.0, est maintenant officiellement prévue aux alentours de la mi-Septembre 2013.

Nous ne sommes plus qu'à quelques bugs d'Hadoop 2 !

Tout ça c'est très bien mais quel est vraiment l'intérêt de cette nouvelle version majeure pour un datalab, un cluster de production, un poc ?

Dans cet article, nous allons tâcher de balayer les différences majeures à connaître de cette version par rapport à Hadoop 1 dont nous avions jusque là pris l'habitude.

YARN

Sans doute la première chose qui vient à l'esprit lorsque l'on parle de Hadoop 2, YARN, dont il a déjà été question un précédent article est aussi probablement le changement le plus important.

Ainsi JobTracker et TaskTracker disparaissent au profit du ResourceManager et du NodeManager, deux processus entièrement dédiés à l'ordonnancement des ressources du cluster.

Quelques éléments importants découlent de YARN :

Des clusters plus grands

La première raison de cette évolution architecturale était la gestion efficiente des ressources de très larges clusters (plusieurs dizaines de milliers de noeuds).

Bon à savoir mais il ce sont tout de même des cas extrêmes et il est très improbable que cet aspect représente un intérêt dans votre contexte.

De nouveaux frameworks de calcul distribué

Beaucoup plus intéressant, l'effet de bord de ce découplage qui fait que MapReduce devient un framework comme un autre.

Et ?

C'est un peu comme passer de la production de masse de vêtements au sur mesure. Maintenant, vous allez pouvoir utiliser le paradigme de calcul distribué qui correspond le mieux au problème qui vous est posé.

Le mouvement a d'ailleurs déjà commencé, exemples :

Tez, un MapReduce sur mesure pour Hive et Pig

Oui, Tez est une réimplémentation de MapReduce. Mais avec quelques adaptations qui le rendent mieux adapté au contexte particulier de Hive et Pig.

Ainsi, une requête génère moins de jobs à enchaîner sur le cluster. Moins de jobs, ce sont aussi moins de ressources à allouer donc des requêtes plus véloces.

Storm-Yarn et Spark Streaming, pour les topologies de traitement de flux distribués en temps réel

Twitter Storm et Apache Spark sont des solutions Open Source de traitement de flux distribués en temps réel. Storm dispose depuis peu d'un port pour Yarn développé par Yahoo! : Storm-Yarn.

Ainsi, si votre problème est de construire des topologies de traitement (calcul d'agrégats,  prévisions en R ou autre, …) sur  de grands volumes de flux de données en temps réel, il devient possible de le faire sans avoir besoin de monter un cluster à part, dédié à Storm ou sans générer des jobs MapReduce.

Giraph, pour de l'analyse distribuée de graphes

Dans un précédent article, nous vous parlions des bases graphes et des solutions de calcul sur ces dernières, Apache Giraph est une solution Open Source de calcul distribué sur des graphes. Facebook s'en sert pour l'analyse de leur graphe social.

Ainsi, vous pouvez maintenant reposer sur les ressources de votre cluster Hadoop pour ce type d'analyses.

Une allocation plus fine des ressources

Dans YARN, le ResourceManager et le NodeManager sont dédiés à la gestion des ressources du cluster et à leur ordonnancement. Par conséquent et contrairement à ce que vous connaissiez en Hadoop 1, votre cluster ne gère plus de slots mapper et de slots reducer. A la place, une abstraction plus générique, le container fait son entrée. Celle ci vise à améliorer le contrôle des ressources allouées à chaque unité de traitement, que ce soit du Map, du Reduce ou autre chose.

Quelle différence concrètement ?

A la différence de Hadoop 1, le container se définit selon plusieurs axes :

• la mémoire minimale et maximale pouvant lui être alloué
• le nombre minimum et maximum de vcore pouvant lui être alloué

Des librairies pour s'interfacer avec YARN

L'API permettant de développer un framework de calcul distribué sur YARN est un peu complexe. Des librairies ont été mises au point afin de simplifier l'intégration de nouveaux frameworks de calculs distribué dans YARN.

Ainsi, si vous avez des besoins non couverts de manière satisfaisante par les solutions existantes ou que le coût d'adaptation de vos codes est trop élevé, il est maintenant possible d'envisager l'ajout de son propre framework de calcul distribué à YARN.

Hadoop sur Windows

Hadoop 2 supporte officiellement Windows Server et Windows Azure. Microsoft est d'ailleurs de plus en plus impliqué dans le développement d'Hadoop. Ainsi, si votre SI et vos compétences sont majoritairement sur Windows, le passage à Hadoop n'est plus synonyme de passage à GNU/Linux, ce qui peut être intéressant dans certains contextes.

HDFS

HDFS aussi bénéficie d'un certain nombres d'améliorations, bien que certaines avaient déjà été rendues disponibles dans les différentes distributions du marché.

La haute disponibilité du NameNode

L'une des premières fonctionnalités de HDFS 2 est la haute disponibilité du NameNode, par ailleurs déjà répandue dans les distributions du marché.

Support des snapshots

Il est maintenant possible de créer des snapshots en lecture seule et en lecture écriture de répertoires HDFS.

Ces snapshots ont par ailleurs quelques caractéristiques importantes :

• le coût de création d'un snapshot ainsi que l'espace mémoire qu'il consomme est annoncé comme étant constant (complexité en O(1))
• support de quotas sur le nombre de snapshots
• des métriques sur les snapshots sont disponibles dans l'interface web du Namenode

Support de NFSv3

Le client HDFS en ligne de commande et l'interface web à HDFS n'étaient pas particulièrement agréables, surtout pour des non techniques.

Dorénavant, il est possible de travailler sur HDFS au travers d'un partage NFS standard. Ainsi, HDFS devient réellement un disque partagé comme un autre sur votre réseau.

Couplé au support Kerberos déjà existant dans Hadoop, il est maintenant possible de fournir des partages HDFS sur les postes de votre parc, facilitant par là même grandement son adoption.

Cependant, il faudra voir dans quelle mesure les contraintes propres à HDFS (taille des blocs, fichiers écrits une seule fois) vont impacter l'utilisation via NFS.

Conclusion

Avec cette nouvelle version majeure, Hadoop franchi un seuil de maturité  et le rend maintenant réellement prêt pour nos DSI.

D'autre part, l'intégration de NFS, des snapshots ainsi que l'ouverture à de nouveaux frameworks de calcul distribué le positionne clairement comme la glue, le facilitateur qui facilite l'application de traitements lourds (et donc distribués) sur de gros volumes de données.