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.
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 :
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.
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 :
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.
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.
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.
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 :
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 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 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é.
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é.
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 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.
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.