Hadoop 2, sorti depuis peu (Generally Available), apporte avec YARN la possibilité de construire des applications de traitement de données fonctionnant nativement sur Hadoop. YARN ouvre la voie pour Hadoop au Data Processing au-delà de Map-Reduce, en séparant la problématique de la gestion des ressources des clusters de celle du traitement des données. Cette séparation rend possible tout un ensemble de nouveaux projets.
Des projets comme Stinger et Tez permettent, dans le cadre de certains scénarios, d'atteindre des temps de réponse adaptés à l'interaction humaine. STORM s'applique au traitement de flux de données. Spring a déjà annoncé le Spring YARN framework, qui s'adresse aux développeurs Java souhaitant écrire leurs propres applications YARN. Ainsi, en s'appuyant sur le système de stockage et la plate-forme de gestion de clusters d'Hadoop, les applications de traitement de données peuvent offrir à leurs utilisateurs la possibilité d'interagir avec la donnée de multiples façons.
Nous avons parlé de YARN à Rohit Bakhshi, responsable produit chez Hortonworks, et discuté des implications pour les utilisateurs d'Hadoop.
Rohit nous donne un aperçu de ce que permet de faire YARN :
La dynamique autour d'Hadoop a pris de l'ampleur et de plus en plus d'entreprises (pas seulement les acteurs majeurs de l'Internet) veulent stocker TOUTES leurs données entrantes dans Hadoop. Elles veulent ensuite permettre à leurs utilisateurs d'interagir avec ces données d'une multitude de manières différentes : en batch, de façon interactive, en analysant les flux au fil de leur réception ou autre. Et ce qui est important pour ces entreprises, c'est de permettre de faire tout cela simultanément, sans qu'une application ou une requête se mette à consommer toutes les ressources du cluster.
En faisant d'Hadoop 2 un système de données multi-applications, YARN permet à la communauté de répondre à toute une génération de nouveaux besoins au sein même d'Hadoop. YARN apporte une solution à l'entreprise en traitant ces nouvelles exigences au niveau du système, dans ses fondations, plutôt que par le recours à des extensions commerciales qui complexifient l'environnement pour les clients.
Pour aller plus loin, l'entreprise sera capable de déployer des clusters Hadoop multi-tenant, servant de multiples objectifs et répondant aux SLA, cela à travers différentes organisations et frameworks applicatifs.
YARN assure une compatibilité des exécutables pour les applications utilisant les APIs mapred mais uniquement une compatibilité des sources pour les applications utilisant l'API mapreduce de Hadoop 1.x. Rohit clarifie ce point :
Avec Hadoop 2.0, les clients soumettent leurs applications MapReduce au framework MapReduce v2 qui est exécuté sur YARN. Avec Hadoop 1.0, les clients soumettaient leurs applications à MapReduce v1. Les APIs font référence au framework MapReduce mis à la disposition des développeurs pour leurs applications. L'API org.apache.hadoop.mapred est l'API d'origine et c'est celle qui est la plus couramment utilisée pour créer des applications MapReduce. Toutes les applications MapReduce v1 créées avec cette API peuvent être soumises pour exécution à MapReduce v2, sur YARN. Aucun changement n'est nécessaire pour l'application dans ce cas.
Les APIs org.apache.hadoop.mapreduce sont plus récentes et les binaires ne sont pas compatibles entre MapReduce v1 et MapReduce v2 sur YARN. Les applications MapReduce v1 utilisant ces APIs devront être recompilées avec les jars Hadoop2.x. Après recompilation, elles pourront être soumises pour exécution à MapReduce v2 sur YARN.
Ces points sont abordés plus en détails ici.
La montée de version d'un cluster Hadoop existant est elle aussi supposée être simple :
Hadoop et HDP (qui comprend tous les composants liés à Apache Hadoop) supportent une montée de version "in-place" depuis HDP 1.3 (Hadoop 1.x) vers HDP 2.0 (Hadoop 2.x). Toutes les données existantes sont maintenues et les métadonnées sont mises à niveau "in-place", sans migration. La configuration a évolué entre HDP 1.3 et HDP 2.0, certaines propriétés sont rendues obsolètes, d'autres sont apparues. Les configurations existantes en HDP 1.3 doivent donc être migrées vers HDP 2.0.
À savoir s'il y aurait matière à inquiétude au sujet des sociétés utilisant Hadoop de façon prématurée sur des ensembles de données trop petits, Rohit répond qu'il voit les choses différemment :
Hadoop est utilisé de multiples façons, il est open source et nous pouvons y voir tout type d'utilisations. Je ne considère pas ce genre d'utilisation comme étant "prématurée". En fait, beaucoup d'entreprises commencent avec seulement un petit cluster, quelques nœuds et quelques téraoctets, mais ces environnements vont potentiellement grossir, grossir jusqu'à devenir un énorme réservoir de données, un système de données moderne. Les clusters de petite taille ne sont pas "prématurés", ils sont le début de quelque chose.
L'annonce officielle vous propose des informations complémentaires sur cette nouvelle release.