Big da­ta : Map­py passe à la vi­tesse su­pé­rieure

L’ex­ploi­ta­tion di­recte par des ou­tils d’ana­lyse tra­di­tion­nels d’im­por­tantes vo­lu­mé­tries de don­nées reste pro­blé­ma­tique. Map­py a trou­vé la so­lu­tion : In­dexi­ma. De­puis, la so­cié­té ne fait plus de com­pro­mis entre vo­lu­mé­trie, per­for­mances, coût et gra­nu­la­ri­té

IT for Business - - RETOURS D’EXPÉRIENCES -

Sto­cker de grands vo­lumes de don­nées est une chose, pou­voir les ana­ly­ser sans dé­pen­ser des for­tunes en mé­moire, en ser­veurs et en mo­teurs de bases de don­nées en est une autre. En l’état, il n’exis­tait rien de vrai­ment in­tel­li­gent sur le mar­ché à mettre au-des­sus d’ha­doop, alors nous avons ac­com­pa­gné In­dexi­ma dans le dé­ve­lop­pe­ment d’une so­lu­tion vrai­ment adap­tée à la pro­blé­ma­tique des big da­ta », ex­plique Ni­co­las Kor­chia, res­pon­sable de l’équipe BI chez Map­py.

Spé­cia­liste du cal­cul d’iti­né­raire et des ser­vices de car­to­gra­phie, Map­py est re­con­nu comme le lea­der fran­çais de la re­cherche lo­cale par la carte sur In­ter- net, mo­biles et ta­blettes. Avec plus de 13 mil­lions d’uti­li­sa­teurs men­suels de ses ser­vices, la so­cié­té a at­teint les 373 mil­lions de vi­sites sur l’an­née 2016. « Soit une manne pro­vi­den­tielle d’in­for­ma­tions sto­ckées sous forme de logs que nous ex­ploi­tions re­la­ti­ve­ment peu jus­qu’en 2013, pour­suit Ni­co­las Kor­chia. Il y a un peu plus de trois ans, nous avons pris conscience du ca­pi­tal en notre pos­ses­sion et avons cher­ché des so­lu­tions pour l’ex­ploi­ter avec pour ob­jec­tif de ti­rer par­ti de cette masse d’in­for­ma­tions pour al­ler cher­cher de nou­veaux bu­si­ness mo­dèles » . Ty­pi­que­ment, une ana­lyse des logs per­met à la so­cié­té de sa­voir quels sont les cal­culs d’iti­né­raire les plus de­man­dés sur une ré­gion, ou en­core comment sont consom­més les points d’in­té­rêt par les uti­li­sa­teurs. Elle per­met aus­si de sa­voir com­bien d’iti­né­raires sont cal­cu­lés à par­tir d’un res­tau­rant et même de sa­voir si les clients de res­tau­rants ja­po­nais pré­fèrent les dé­pla­ce­ments en Bla­bla­car… « En fait, on peut en­vi­sa­ger beau­coup de choses, mais uni­que­ment à condi­tion de conser­ver une gra­nu­la­ri­té suf­fi­sante des in­for­ma­tions, pré­cise Ni­co­las Kor­chia. Or, pour des rai­sons de coûts et de dé­lais des trai­te­ments, nous étions obli­gés de conso­li­der les in­for­ma­tions dans des cubes of­frants re­la­ti­ve­ment peu de flexi­bi­li­té et d’agi­li­té au ni­veau de l’ana­lyse. Du coup, on per­dait une par­tie de la ri­chesse des in­for­ma­tions » .

Avant la prise de conscience et la mise en place d’une équipe dé­diée à la BI en 2013, l’ar­chi­tec­ture de Map­py re­po­sait sur des trai­te­ments dé­ve­lop­pés en in­terne en Py­thon pour gé­rer les 200 Go de log quo­ti­diens en­re­gis­trés par les 700 ser­veurs en pro­duc­tion. Sto­ckés dans Mi­cro­soft SQL Ser­ver, ils étaient en­suite agré­gés dans des cubes. Une in­fra­struc­ture re­la­ti­ve­ment tra­di­tion­nelle dans le do­maine de la BI, mais qui n’était plus adap­tée à la stra­té­gie d’ana­lyse de don­nées à grande échelle que la so­cié­té sou­hai­tait mettre en place. Map­py adopte donc Ha­doop pour trai­ter et sto­cker ses logs dans leur glo­ba­li­té afin de conser­ver toute la ri­chesse des in­for­ma­tions. Au pas­sage, la so­cié­té se dote d’une équipe de 15 per­sonnes, dont 7 da­taen­gi­neers et 3 da­tas­cien­tists, char­gés d’ex­traire, d’ana­ly­ser et de mettre les don­nées à dis­po­si­tion à par­tir d’ou­tils tels que Ta­bleau, mais aus­si Ex­cel, etc. Fi­ni les rap­ports pré­pro­gram­més, Map­py passe à la BI self-ser­vice ! Sauf que l’ex­ploi­ta­tion di­recte de don­nées à par­tir d’ha­doop (HDFS) n’est ac­ces­sible qu’aux uti­li­sa­teurs fa­mi­liers avec les don­nées brutes, rai­son pour la­quelle la ma­jo­ri­té des en­tre­prises adoptent des struc­tures re­la­tion­nelles ou mul­ti­di­men­sion­nelles (OLAP) in­ter­mé­diaires pour consti­tuer des jeux de don­nées

adap­tées aux be­soins de chaque ana­lyste. En outre, le ba­layage ligne par ligne opé­ré par les mo­teurs Ha­doop, dont no­tam­ment Spark, ra­len­tit d’au­tant plus l’exé­cu­tion des re­quêtes que la vo­lu­mé­trie est im­por­tante.

Si de nom­breuses so­lu­tions existent pour ac­cé­lé­rer l’exé­cu­tion des re­quêtes sur de grosses vo­lu­mé­tries, « au­cune n’est in­tel­li­gente, es­time Ni­co­las Kor­chia. Ex­traire des jeux de don­nées sous forme de cubes, même dis­tri­bués pour ga­gner en per­for­mance, ne per­met pas d’ob­te­nir la sou­plesse que nous re­cher­chions. Idem pour les bases re­la­tion­nelles » . Quant à l’ap­proche qui consiste à mul­ti­plier les bases NOSQL au-des­sus d’ha­doop pour dis­po­ser de jeux de don­nés per­for­mants, « elle n’est ni simple ni avan­ta­geuse fi­nan­ciè­re­ment car très consom­ma­trice de res­sources qu’il faut en­suite ad­mi­nis­trer. Et ne par­lons pas de l’op­tion in-me­mo­ry, certes performante et adap­tée à notre be­soin de sou­plesse, mais sim­ple­ment exor­bi­tante en termes de coûts en RAM pour pou­voir trai­ter notre vo­lu­mé­trie », ajoute le res­pon­sable.

C’est alors que Map­py croise Florent Voi­gnier et sa fu­ture base de don­nées In­dexi­ma. Si la start-up n’est lan­cée qu’en mars 2016, c’est dès 2014 que son fon­da­teur planche sur un mo­teur d’in­dexa­tion pour ac­cé­lé­rer l’ana­lyse et la vi­sua­li­sa­tion de don­nées en en­vi­ron­ne­ment Ha­doop. En­semble, Map­py et Florent Voi­gnier vont peau­fi­ner une so­lu­tion qui com­bine dif­fé­rentes tech­niques dont no­tam­ment le cu­mul d’index mul­ti-di­men­sion­nels in-me­mo­ry, des pré-agré­ga­tions de jeux de don­nées et un sto­ckage à plu­sieurs ni­veaux. Par­ti­cu­liè­re­ment adap­tée à l’ana­lyse de très gros vo­lumes sans im­pac­ter les per­for­mances, la so­lu­tion In­dexi­ma ap­porte aus­si à Map­py toute la sou­plesse dont elle avait be­soin. Dans un pre­mier temps, dé­but 2014, Map­py teste la so­lu­tion en mode POC et, convain­cue par son po­ten­tiel, elle s’im­plique dans le dé­ve­lop­pe­ment. Quelques mois plus tard, l’ar­chi­tec­ture BI de Map­py com­mence à prendre forme. Sto­ckés dans Ha­doop, les logs sont agré­gés par des trai­te­ments écrits en Ma­pre­duce avant d’être in­jec­tés dans In­dexi­ma sous dif­fé­rentes formes se­lon les be­soins : sur disque, in-me­mo­ry, etc. Équi­pés de leurs ou­tils de BI tra­di­tion­nels, les uti­li­sa­teurs ac­cèdent di­rec­te­ment à la base pour réa­li­ser leurs ana­lyses. « La prin­ci­pale dif­fé­rence, c’est que l’agré­ga­tion est ef­fec­tuée à un ni­veau beau­coup plus fin qui nous per­met de conser­ver toute la ri­chesse de nos logs, ex­plique Ni­co­las Kor­chia. Nous ne sommes plus li­mi­tés par la vo­lu­mé­trie ou les per­for­mances, la par­ti­cu­la­ri­té d’in­dexi­ma étant d’être ca­pable de gé­rer 100 à 1 000 fois plus ra­pi­de­ment n’im­porte quelle vo­lu­mé­trie que les so­lu­tions ac­tuelles » .

En pro­duc­tion de­puis plus d’un an, l’ar­chi­tec­ture de Map­py compte dé­sor­mais quelques 20 mil­liards de lignes de don­nées agré­gées dans In­dexi­ma. Le temps de ré­ponse des re­quêtes est pas­sé d’en­vi­ron 20 se­condes à 0,1 se­conde. « Nous avions six ma­chines avant et nous avons tou­jours six ma­chines au­jourd’hui, mais avec une vo­lu­mé­trie qui a été mul­ti­pliée par 20, et sur­tout 15 uti­li­sa­teurs connec­tés si­mul­ta­né­ment qui ob­tiennent des ré­ponses qua­si-im­mé­diates à leurs re­quêtes. En termes de per­for­mance, de sou­plesse, mais aus­si éco­no­mique, nous avons ga­gné sur tous les fronts. At­tendre des mi­nutes, par­fois même des heures, pour qu’une re­quête s’exé­cute n’est ja­mais très ren­table, sans comp­ter que ça li­mite le da­tas­cien­tist dans les ex­plo­ra­tions qu’il peut faire » , sou­ligne Ni­co­las Kor­chia. Ré­sul­tat, Map­py entre dans une nou­velle ère, son ser­vice BI tour­nant à plein ré­gime pour trou­ver les bu­si­ness mo­dèles de de­main. « Il y au­ra un avant et un après In­dexi­ma, pré­dit Ni­co­las Kor­chia. Quand on n’est plus obli­gé de choi­sir ou de faire des com­pro­mis entre coût, per­for­mances et vo­lu­mé­trie, ça change tout. En d’autres termes, il n’y a vrai­ment plus au­cune li­mite aux ques­tions que l’on peut se po­ser au­tour des don­nées » .•

Ma­rie Va­ran­dat

« Quand on n’est plus obli­gé de choi­sir ou de faire des com­pro­mis entre coût, per­for­mances et vo­lu­mé­trie, ça change tout ». Ni­co­las Kor­chia, res­pon­sable de l’équipe BI chez Map­py

Ré­sul­tats de re­quêtes.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.