Spark contre MapReduce : quelle solution pour les entreprises
La jeune technologie Spark doit remplacer MapReduce dans les architectures Big Data. Mais où en est-on ? LeMagIT fait le point.
Out MapReduce. La percée fut belle, mais les développeurs Big Data actuels ont faim de simplicité et de rapidité. Et quand il s’agit de choisir un framework pour exécuter des tâches dans un environnement Hadoop, ils sont de plus en plus nombreux à préférer une très jeune alternative : Spark.
C’est au moins le message envoyé au marché par les fournisseurs de solutions Big Data qui se jettent derrière Apache Spark, pour en faire la prochaine perle du Big Data.
Lors du dernier Spark Summit qui s’est tenu en juin à San Francisco, Mike Olson, Chief Strategy Officer de Cloudera évoque « l’époustouflante » croissance de Spark et du profond changement des préférences clients qui en résulte. « Nous pensons que Spark sera le framework de traitement généraliste et dominant pour Hadoop », indique-t-il. « Si vous voulez un bon moteur transversal aujourd’hui, vous choisissez Apache Spark, mais pas Apache MapReduce. »
Mike Olson choisit minutieusement ses mots, quand il parle de généraliste. Selon lui, s’il existe une place pour les moteurs de traitement dédiés, comme Apache SolR pour la recherche et Cloudera Impala pour les requêtes SQL, la bataille pour la suprématie des frameworks capables de prendre en charge une grande variété de travaux analytiques (d’où cette notion de généraliste) rassemble désormais deux acteurs – et c’est une bataille que Spark est en train de remporter.
Pour faire simple, Spark répond à nombre de critiques au long cours sur MapReduce : sa latence et le mode batch. « On sait depuis très longtemps que MapReduce était un bon outil aux premiers jours d’Hadoop », assure Arun Murthy, fondateur et architecte d’Hortonworks. Selon lui, la technologie a été créée dans les labos de Google pour cibler un cas d’usage particulier : la recherche Web. Après plus de 10 ans, il a évolué, mais peut-être pas suffisamment pour répondre à l’appétit grandissant des entreprises pour les applications Big Data.
« Sa force : il était suffisamment malléable pour étendre son champ d’action », explique Arun Murthy. « Mais on sait également que MapReduce peut résoudre certains cas d’usage, mais pas de façon optimisée. MapReduce a certes créé une rupture. Il est aujourd’hui naturel que de nouvelles technologies remplacent MapReduce. »
Rapidité et simplicité
Mais en quoi Spark se distingue-t-il ? Le principal avantage pour les développeurs est la rapidité. Les applications Spark sont plus rapides, et de loin, que celle bâties sur MapReduce – Mathei Zaharia, CTO de Databricks, une société qui propose une offre Spark dans le Cloud, qui se repose sur Cassandra et non pas Hadoop, parle d’un facteur de 100.
Il est important de noter que Spark peut fonctionner sur plusieurs systèmes de fichiers et de bases de données, dont HDFS.
Spark prend une longueur d’avance sur MapReduce car il gère la plupart de ses opérations en mémoire, copiant les jeux de données d’un système de stockage physique vers de la mémoire RAM bien plus rapide. De son côté, MapReduce écrit et lit les données depuis le disque dur. Si les accès disque peuvent prendre plusieurs millisecondes pour accéder à 1 Mo de données, les taux d’accès des données placées en mémoire passent en dessous de la milliseconde.
Pour Nick Heudecker, analyste chez Gartner : « Un client, qui dispose d’un vaste cluster Hadoop, a mis en place un pilote Spark capable de réduire le temps de traitement de 4 heures (avec MapReduce) à 90 secondes (avec Spark). »
Pour de nombreuses entreprises, cela est très attractif, commente-t-il. « Elles peuvent passer de deux analyses par jour sur un jeu de données type à autant d’analyses qu’elles le souhaitent. »
Lors du Spark Summit en juin, Brian Kursar, directeur data scient chez Toyota Motor Sales USA, a expliqué avoir vu des améliorations dans l’exécution des analyses de son application CRM. Celle-ci traite quelques 700 millions d’enregistrements extraits des réseaux sociaux, d’études et de centres de contacts, pour détecter les taux de churn et des incidents afin de faire intervenir des agents si nécessaire.
Avec MapReduce, l’analyse demande 160 heures de calcul. Presque 7 jours, rappelle Brian Kursar. « Le résultat produit arrive un peu tard », affirme-t-il. La même tâche, ré-écrite pour Spark, n’a demandé que 4 heures.
Autre avantage de Spark sur MapReduce, sa relative facilité d’utilisation et sa flexibilité. Cela n’est pas surprenant : Mathei Zaharai a créé Spark lors de son PhD à l’Université de Berkeley pour répondre aux limites de MapReduce, identifiées lors de travaux d’été avec les premiers utilisateurs d’Hadoop, dont Facebook.
« J’ai constaté que les utilisateurs souhaitaient aller plus loin avec leurs données que ce que MapReduce pouvait apporter », raconte-t-il. « Il était très limité. Il ne supportait pas les requêtes interactives, ni les algorithmes avancés comme le Machine Learning. Cela a créé beaucoup de frustrations. Mon objectif a donc été de résoudre ces problèmes. En même temps, je voulais qu’il soit plus facile d’adopter les mécanismes du Big Data pour obtenir plus rapidement des résultats. »
La plupart des utilisateurs s’accordent à dire que Spark est plus convivial : « L’API est vraiment plus facile à utiliser que celle de MapReduce », explique Brian Kursar.
Justin Kestelyn, en charge des relations développeurs chez Cloudera, a expliqué dans un billet de blog que l’API pour Scala, Java et Python peut réduire la taille du code d’un facteur compris entre 2 et 5 fois la taille du code MapReduce.
Toutefois, cette facilité d’utilisation ne se fait pas au détriment de la flexibilité, explique Mike Gualtieri, analyse du cabinet d’étude Forrester, dans un rapport publié cette année. Au contrainte, explique-t-il, Spark comprend des outils spécialisés qui peuvent être utilisés soit de façon autonome, soit ensemble, pour développer des applications.
C’est le cas de SparkSQL, pour les requêtes sur les données structurées relationnelles, Spark Streaming, pour le traitement de flux de données en quasi temps réel via des micro-batches ; MLib pour le Machine Learning ; et GraphX pour représenter sous la forme de graphes des données reliées de façon arbitraires, comme les connexions des utilisateurs de réseaux sociaux.
Une technologie qui ne fait qu’émerger
Toutefois, le point faible de Spark est sa jeunesse et donc son immaturité. Ce que partage, Len Hardy, architecte en chef chez Northern Trust, une société de services financiers qui utilise une distribution Cloudera ainsi que de nombreux autres outils au-dessus de leur implémentation, comme Hive (pour l’entrepôt de données), Flume (agrégations de logs) et Cloudera Impala (pour les requêtes SQL).
Aujourd’hui, Len Hardy n’utilise pas Spark en production. « Nous gardons de la distance par rapport à Spark », confie-t-il. « Il s’agit d’un problème de maturité. La technologie est certes pleine de promesses, et nous l’utiliserons à terme, sans aucun doute – d’ailleurs nous l’utilisons déjà dans des PoC. Mais le projet est jeune sur le marché. Pour notre plateforme de données d’entreprise, là où nous posons nos données pour nos partenaires et nos clients et sur lesquelles ils s’appuient pour prendre des décisions, nous avons besoin d’outils en béton et je ne pense que Spark en soit là pour le moment. »
Cette prudence est justifiée. Tous les principaux fournisseurs Hadoop se ruent pour vanter leur support de Spark pour l’entreprise, mais comme le précise Nick Heudecker de Gartner : « le support commercial de Spark est presque toujours intégré à d’autres packages, mais les professionnels de la gestion de l’information et de l’analyse de données doivent être conscients du fait que le rythme des développements de Spark complique la tâche des fournisseurs qui doivent supporter la dernière version des composants. »
Les APIs et les bonnes pratiques sont encore en développement, ajoute-t-il. Les fournisseurs ont du mal à supporter de la même façon tous les composants du framework. Les utilisateurs doivent faire attention de ne pas déployer leurs applications critiques sur des fonctions qui ne sont pas supportées ou partiellement.
Mike Olson de Cloudera confirme que Spark est encore jeune. « Nous n’en sommes qu’au début. Il reste encore beaucoup de travail à faire autour de la sécurité, par exemple », explique-t-il.
Plusieurs mois après le Spark Summit, il confirme que dans un futur pas si lointain, la plupart des nouvelles fonctions analytiques dans Hadoop reposera sur Spark et non pas sur MapReduce. « La principale tendance à venir pour le cluster Hadoop sera Spark. Je ne sais pas quand cela arrivera », poursuit-il. « Aujourd’hui, je ne peux pas le prédire précisément, mais certains de nos clients, particulièrement dans les services financiers et les biens de consommation, ont enclenché le processus. D’autres vont surement suivre. »
Traduit et adapté par la rédaction
