Technologies

Fr HUG : Savoir bien structurer les données dans Hadoop pour éviter l'explosion des ressources

---

Le club des utilisateurs Hadoop français (Fr HUG) s'est réuni dans les locaux de l'IESEG, à la Grande Arche de La Défense, le 4 juin 2015 sur le thème de la modélisation du datalake.

Publicité« Il faut structurer les données dans les datalakes pour les analyser, même si elles sont non-structurées en entrée, sinon on ne peut rien en faire » a martelé Cyrille Coqueret, directeur technique BI & Big Data chez Edis Consulting. Il s'est exprimé à la réunion du French Hadoop User Group (Fr HUG, le club des utilisateurs français de Hadoop) qui a eu lieu dans les locaux parisiens de l'IESEG le 4 juin 2015.
Cette école de commerce est d'ailleurs en train de lancer une formation pour les Data Scientists, ce qui a motivé son intérêt à ainsi aider le Fr HUG.


Cyrille Coqueret, directeur technique BI & Big Data chez Edis Consulting

Mais deux erreurs courantes inverses ne doivent pas être faites selon Cyrille Coqueret. La première, donc, est de ne pas structurer les données proprement. Dans ce cas, les informaticiens sont les seuls à avoir une chance de se retrouver dans le datalake sans s'y noyer. Beaucoup du bénéfice du Big Data est ainsi perdu si les utilisateurs finaux ne peuvent rien faire.
La seconde consiste au contraire à adopter une structure classique de SGBD-R « en étoile » avec d'innombrables jointures inter-tables. Cyrille Coqueret avertit : « sous Hadoop, la phase de consolidation va alors consommer trop de ressources mémoire et réseau. » La bonne logique à adopter, selon lui dans la plupart des cas, est donc de constituer une seule table avec des dimensions ajoutées autant que nécessaire. Deux inconvénients émergent alors : la modélisation a priori, ce qui le contraire de l'approche Big Data, et un nombre de colonnes qui s'accroît au point que les utilisateurs finaux peuvent aussi se perdre. Pour limiter l'impact de ces inconvénients, il faut séparer les datasets dans le datalake, optimiser le format (compression...) et favoriser la modélisation évolutive avec la possibilité de rajouter des colonnes autant que le besoin s'en fait sentir.
Les datasets peuvent également voir leur usage facilité avec une approche SBA, en intégrant un moteur de recherche pour la consultation des données en « full texte » avec des vues simplifiées.Il a pointé l'intérêt de Sinequa dans ce contexte, ce moteur intégrant nativement des thésaurus de synonymes.


De gauche à droite : Nicolas Korchia, responsable BI chez Mappy, et Florent Voignier, architecte Big Data chez Databig

Toujours au cours de cette réunion, deux entreprises ont témoigné de leurs usages des solutions construites autour d'Hadoop.

PublicitéLa première a été Mappy, du groupe SoLocal (ex-Pages Jaunes). Hadoop a été utilisé pour analyser les logs concernant les quatre millions de points d'intérêts locaux (PIL) sur les cartes publiées par cette société (par exemple : un musée, une boulangerie...). Le but était de choisir quels PIL mettre en avant. Ce sont pourtant 150 Go de logs qui sont générés chaque jour.
L'ancienne technologie déployée reposait sur une alliance Python/SQL Server avec des cubes Olap construit avec la technologie Microsoft et une consultation par les utilisateurs finaux sous Excel. « Mais nous avions besoin de plus de 24 heures pour traiter une journée de logs » se souvient Nicolas Korchia, responsable BI chez Mappy. Absence de scalabilité, interdiction des analyses exhaustives et usage de logs agrégés étaient autant de problèmes à régler.
Dans un premier temps, seul l'agrégation en haut de chaîne de traitement a été remplacé par Hadoop. Mais la phase de consolidation impliquait une latence trop importante qui a pu être diminuée en adoptant un traitement Java. La scalabilité de cette solution a permis de réduire les temps de traitement à 2 heures.
L'architecture finale a reposé sur un stockage dans Hadoop Yarn 2.5.2 sur des baies EMC² Isilon en HDFS. Hive, Java et Map Reduce ont permis de faciliter les traitements tandis que l'interrogation par les utilisateurs finaux passait par Tableau et le requêteur Spark SQL.


Michael Thiriet, architecte technique BI et Big Data chez PSA Peugeot Citroën

A l'inverse, PSA Peugeot Citroën a fait le choix d'une architecture largement IBM (Hbase/BigSQL...) avec une visualisation sous Tableau. Ces outils vont être de plus en plus déployés pour analyser les logs des voitures connectées. Ces logs serviront à des offres commercialisées par le constructeur automobile auprès de ses clients, les premier niveau de service étant gratuit. Des services en lien avec la sécurité, la maintenance, la gestion de flotte ou l'information de trafic devraient voir le jour prochainement.
Face aux réticences, Michael Thiriet, architecte technique BI et Big Data chez PSA Peugeot Citroën, explique : « on localise quelqu'un bien plus avec son téléphone qu'avec son véhicule. » La plupart des données sont de plus anonymisées et les véhicules concernés sont dotés d'un bouton « conduite privée » pour bloquer le suivi.

Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO

Partager cet article