Comment Mappy utilise Hadoop, Spark SQL, Hive et MapReduce
Depuis près de 3 ans, Mappy a doté sa BI d’une brique Big Data couplée à la DataViz de Tableau Software. Une brique qui ne cesse de monter en puissance devant l’afflux de données et les exigences de ses utilisateurs.
Avec 10 millions de visiteurs uniques chaque mois, dont 7,2 millions sur le Web, Mappy est le champion français de la cartographie. Mais pour faire face au rouleau compresseur Google, la filiale du groupe Solocal (ex-Pages Jaunes) a choisi de se différencier en privilégiant les POI (Point of Interest), les contenus attachés aux positions géographiques. Il gère ainsi 4 millions de fiches de restaurants, d’hôtels, de commerçants divers.
Pour accompagner cette stratégie, le Français a mis en place des outils d’analyse de cette audience un peu particulière : « Nous avons environ 120 serveurs en production », souligne Nicolas Korchia, responsable Business Intelligence chez Mappy. « A nos applications mobiles, à ces serveurs, nous posons des questions telles que est-ce que le 4e serveur de plans est aussi performant que les autres ? Est-ce que l’application pour iPhone version 2.3 est encore utilisée et sur quels terminaux est-elle encore utilisée ? Nous avons aussi des questions commerciales pour savoir si par exemple les hôtels Booking sont beaucoup cliqués en ce moment ou s’il faut les booster pour générer plus de chiffre d’affaires. Beaucoup des réponses à ces questions sont dans les logs de nos serveurs. » Si les fichiers de logs générés par les serveurs de Mappy sont très riches en données, ceux-ci posent un problème majeur de volumétrie puisque ce sont 150 Go de données qui sont produites chaque jour par ces 120 serveurs.
Hadoop est intégré progressivement à la chaîne décisionnelle
Jusqu’à 2012, Mappy utilisait une chaîne de traitement des logs serveur composée d’une phase agrégation développée en langage Python. Les données agrégées étaient ensuite stockées sur Microsoft SQL Server. Des cubes OLAP sous Microsoft Analysis Services permettaient aux analystes de consulter ces données via Excel et des extractions PDF. Florent Voignier, Architecte Big Data chez Databig, en mission chez Mappy depuis 3 ans, précise : « Cette chaîne présentait un gros problème de performance car il fallait plus de 24 heures pour traiter 24 heures de données. Mappy était arrivé au maximum de la scalabilité verticale de cette approche. »
Devant la pression des utilisateurs qui réclament toujours plus d’indicateurs, Mappy va alors doper sa chaine décisionnelle au Big Data. « Au départ, la base de statistiques agrégées comptait 10 millions de lignes. SQL Server pouvait faire cela, mais il y avait beaucoup de nouvelles stat serveurs à agréger », ajoute Florent Voignier. « Nous avons proposé un cluster Hadoop pour agréger les données, tout en conservant la chaîne BI traditionnelle, afin d’introduire progressivement Hadoop chez Mappy. Nous avons donc conservé SQL Server, les cubes OLAP et Excel, Hadoop n’étant utilisé que pour l’agrégation des données. »
Ce passage à Hadoop, et plus particulièrement à des jobs Java sur Map/Reduce, a eu un effet immédiat. La phase d’agrégation des données est passée de plus de 24 heures de traitements à 2 heures seulement. Un gain de performance spectaculaire alors que l’équipe ne dispose que d’un petit cluster de 4 serveurs et 32 cœurs de calcul au total. Pour obtenir un tel résultat, l’équipe décisionnelle a dû optimiser sa chaine de calcul : « Nous avons choisi Map/Reduce et Java car les données serveur chez Mappy sont très hétérogènes, avec les logs standards Apache ou Varnish, mais aussi des logs propriétaires Mappy avec des ID à reconsolider. Avec Java Map/Reduce, on peut réaliser ce que l’on souhaite sur les données en entrée et traiter ce problème. En outre, se posait le problème de la performance. Si on raisonnait simplement, nous aurions fait un job par ferme avec un pipeline de job derrière, nous aurions eu au moins 100 jobs Map/Reduce à lancer chaque nuit. Pour maximiser les performances, nous avons essayé de regrouper au maximum les traitements dans chaque job Map/Reduce. Un même job peut agréger des stats serveurs, mais aussi faire dans le même temps un filtrage, dégager des informations de suivi d’audience, éventuellement envoyer ces informations vers une autre chaine de traitements qui réalise des traitement spécifiques, selon la nature de la donnée. En 5 jobs Map/Reduce, nous réalisons l’équivalent de 100 jobs. Comme Map/Reduce présente de gros temps de latence, en regroupant les traitements, on va beaucoup plus vite. »
SQL Server a fait la place à un cluster Hadoop
Cet accroissement de la puissance disponible s’est traduit par un accroissement tout aussi spectaculaire du nombre de statistiques mises à disposition des analystes. De 10 millions de lignes, ce sont 460 millions de lignes qui devaient potentiellement être chargées dans SQL Server. La mise en place de nouveaux indicateurs a fait exploser le nombre de lignes des tables. De plus, le management de Mappy a demandé à ce qu’un suivi d’audience soit mis en place pour chacun des 4 millions de POI gérés par le site.
« Nous devions être capable de tracker comment les visiteurs interagissent avec les POI. Combien de fois un POI a été visible sur une carte, combien de fois l’adresse a été affichée, combien de fois le POI a été cliqué, tout cela pour 4 millions de POI à réaliser chaque jour », détaille Nicolas Korchia. « Notre conclusion était que si effectivement nous étions capables de calculer ces statistiques, nous devions travailler sur la façon dont les utilisateurs allaient accéder à ces informations agrégées avec la mise en place d’une couche Dataviz. »
Le logiciel de visualisation de données de Tableau Software a été choisi. Mais, avec 460 millions de lignes à traiter, Mappy devait trouver une alternative à SQL Server pour stocker ses données agrégées. C’est la solution Spark SQL, alors encore en version alpha qui est alors testée. « Toute la partie SQL Server, cubes OLAP et SQL Server a été remplacée par cette nouvelle chaine », explique Florent Voignier. « Nous avons conservé Map/Reduce pour agréger les données brutes mais, après avoir évalué différentes technologies, nous sommes passés à Spark SQL, une solution in-memory pour traiter les requêtes soumises par l’outil de dataviz choisi : Tableau. La mise en place de cette nouvelle chaîne a été l’occasion de passer sous Hadoop 2, basé sous YARN avec nos deux moteurs de calcul Map/Reduce et Spark SQL. »
Coupler Spark SQL à Tableau a demandé de recompiler toute la plateforme Big Data
Spark SQL était alors une solution très récente et les ingénieurs ont eu quelques difficultés à connecter Tableau et Spark SQL. « Au départ, Tableau n’était pas conçu pour se connecter à Spark SQL qui était un projet très nouveau », ajoute Florent Voignier. « Nous avons dû le « rebuilder », notamment son driver Hive Server 2 qui permet de le connecter à Tableau. Nous avons dû patcher quelques lignes pour que cela puisse fonctionner. Nous avons aussi rebuildé Hadoop 2 pour lui ajouter les algorithmes de compression que nous souhaitions et aussi Spark SQL pour qu’il soit compatible avec YARN, car ce n’était pas le cas de la distribution officielle. Nous n’avons pas choisi la distribution Cloudera car nous voulions vraiment la toute dernière version de Spark SQL. Au final, nous avons pu avoir une solution orchestrée par YARN. »
Au niveau matériel, un nouveau cluster de 6 nœuds a alors été déployé. Chaque serveur offre 24 cœurs, soit 144 cœurs au total, et 128 Go de RAM. Côté stockage, les données ne sont pas stockées sur le cluster Hadoop mais sur un cluster de serveurs de stockage Isilon qui propose HDFS parmi les protocoles supportés. « Nous avons 6 nœuds et chacun d’eux compte 36 disques. L’avantage, c’est de pouvoir disposer d’un grand nombre de disques en parallèle. Sur les fichiers morcelés par Hadoop, le parallélisme fonctionne très bien. Nos deux clusters pointent sur les mêmes données et le cluster Isilon peut être sollicité par d’autres services Mappy qui ne font pas nécessairement du Hadoop. Nous avons évalué ce passage à Isilon et par rapport à un stockage direct sur chaque serveur. Nous avons obtenu un gain de performance d’un tiers alors que je m’attendais à une perte. »
Tous ces efforts vont porter leurs fruits. Les gains apportés par Spark SQL sont très significatifs : Par rapport à Hive sur Map/Reduce, le temps de traitement d’une requête générée par Tableau est passé de 159 secondes à 59 secondes seulement. Dans le mode « in-memory » supporté par Spark SQL, celui-ci tombe à 21 secondes. « C’est trois fois plus rapide. Le facteur pourrait être de 10, mais les requêtes générées par Tableau consomment beaucoup de CPU et donc le In-Memory ne permet pas un tel gain à cause de cela », commente l’expert.
Il précise : « Les requêtes générées ne sont pas comparables à celles d’un être humain. En fonction des manipulations des utilisateurs, le logiciel peut générer des requêtes qui ne sont pas du tout optimisées, avec notamment des CAST qui réalisent des conversions de données entre types différents, ce qui consomme énormément de CPU. De même que les dates en timestamp, qui sont des nombres de secondes. En termes de CPU, ce sont des requêtes très lourdes. »
Autre constat réalisé après le déploiement de Spark SQL, certaines « grosses » requêtes sont plus lentes voire font planter cette solution Big Data : « Ce qui nous a surpris, c’est que pour les grosses jointures, HIVE se montre légèrement plus rapide que Spark SQL. Cela peut être dû à des optimisations réalisées au niveau des jointures. Certaines jointures, avec des tables de faits d’un milliard de lignes, des tables de dimensions de 4 millions de lignes par jour ne fonctionnent que sur Hive. »
Diviser les temps de réponse par 3 grâce au « in-memory » ne suffit plus…
Néanmoins, le constat de la mise en place de Spark SQL est plus que positif pour l’équipe BI. Les gains de performances sont spectaculaires et pour les grosses requêtes, Hive assure la fiabilité de la plateforme : « Nous étions satisfaits de ces résultats, sauf qu’aujourd’hui, la BI doit être instantanée », souligne Nicolas Korchia, responsable Business Intelligence chez Mappy. « Les analyses interagissent avec Tableau et s’ils doivent attendre ces 21 secondes, plusieurs minutes, c’est trop. Dès que nous avons mis un outil pour accélérer la donnée, on nous a demandé d’enrichir les données, d’ajouter des colonnes. C’est comme cela que nous sommes passés de 10 millions à 1 milliard 250 000 lignes sur des stats « dites » agrégées. Cette approche a montré ses limites. »
La prochaine étape est en cours de développement. Elle se baptise Galactica.io. « Nous avons réfléchi sur comment nous allions pouvoir résoudre ce problème, et nous avons proposé à Mappy un projet, Galactica.io », explique Florent Voignier. « La solution à ces problèmes de performances consiste à pré-agréger les données. L’idée de construire des indexes sur ces données dé-normalisées. On indique quels groupements de colonnes on souhaite indexer et à chaque niveau de l’index des agrégats sont calculés pour chaque insertion, donc en temps réel. On indique si on souhaite des sommes, des min, des max, et quels groupements de colonnes on souhaite indexer. Compatible Hive server 2, Galactica prend ces requêtes générées par Tableau et si ses index lui permettent de répondre, il envoie la réponse instantanément, et s’il n’a pas l’index correspondant, il peut toujours transmettre la requête à Spark SQL. »
Pur projet de R&D, Galactica n’est pas encore en production chez Mappy mais déjà les premiers résultats sont plutôt prometteurs. La requête qui prenait 21 secondes grâce au mode « in-memory » de Spark SQL livre un résultat en 100 ms seulement. Objectif atteint s’il s’agit de délivrer un résultat en temps réel à un utilisateur Tableau.
« L’autre avantage, c’est que si un traitement Map/Reduce est en cours de fonctionnement pour un batch, que les CPU sont à 100%, vous pouvez néanmoins avoir une requête qui répond sous la seconde avec Tableau », ajoute Florent Voignier. Les développements se poursuivent sur Galactica.io et le besoin est de plus en plus urgent : ce ne sont plus 1,2 milliard de lignes qui sont stockées sur le cluster Hadoop de Mappy, mais 2,7 milliards aujourd’hui… Le bras de fer entre développeurs et analystes continue…
