Hadoop User Group : passer du pilote à la production, pas si simple

Le Data Lake, digne successeur du Data Warehouse ?

La Business Intelligence de grand-papa, c’était un entrepôt de données avec sa modélisation en étoile ou en flocon, son ETL qui tournait chaque nuit pour alimenter les utilisateurs en données fraiches le matin. Une approche que le Big Data remet totalement en cause.

Il « suffit » de déverser toutes ses données brutes dans un « Data Lake », un lac de données, puis laisser les Data Scientists travailler… Une vision loin d’être aussi simple dans la réalité des entreprises, comme l’a souligné Cyrille Coqueret, Directeur Technique Business Intelligence & Big Data de la société EDIS Consulting .

« L’objectif de la mise en place d’un Data Lake, c’est de manipuler de très gros volumes de données. On va pouvoir stocker des données structurées, non structurées, des données internes ou externes à l’entreprise. On va pouvoir enfin « dé-siloter » les données, ce qui n’a pas toujours été réussi avec les Datawarehouse. Le Data Lake permet aussi de gagner en agilité sur les données avec cette possibilité d’ajouter de nouvelles données de manière très rapide, et enfin donner aux utilisateurs les moyens d’être autonomes dans leurs analyses. »

Selon lui, beaucoup de projets de Data Lake menés actuellement par les entreprises françaises se limitent encore à ce déversement de données ; aux Data Scientists de réaliser leurs analyses et de se « débrouiller » pour croiser les données mises à leur disposition. Une approche essentiellement axée sur la technologie.

Pour Cyrille Coqueret, l’approche ne doit pas être uniquement technique, mais avant tout méthodologique et fonctionnelle. « Les entreprises négligent bien souvent les problématiques de production et de maintenance de ces Data Lake. On peut démarrer rapidement un projet, mais souvent les projets restent bloqués au niveau du PoC (Proof-of-Concept), sans jamais pouvoir passer en production. Le Big Data, ce n’est pas magique. On récupère des données non structurées, des données semi-structurées ou structurées en entrée, mais si on veut les analyser et en tirer quelque chose, il faut les structurer. Or, pour l’instant, il n’existe pas de bonnes pratiques à appliquer pour structurer un Data Lake. »

Hadoop, ses forces et sa faiblesse

L’expert oppose l’approche traditionnelle en Business Intelligence où l’on construit un entrepôt de données en l’alimentant de données internes, généralement alimenté en batch durant la nuit et dans lequel les données sont parfaitement structurées, normalisées. Une structuration qui a donné naissance aux traditionnels schémas en étoile ou en flocon, conçus pour les bases de données relationnelles. Ce modèle avait ses atouts, mais aussi de vraies limites, certaines en termes de souplesse, avec un schéma difficile à faire évoluer, d’autres en termes de coût du stockage et de montée en charge.

Sur ce plan, le Big Data et son approche Data Lake apporte une véritable solution. Néanmoins Hadoop présente une faille : son architecture ultra-distribuée est à la peine lorsqu’il s’agit de réaliser des jointures entre données.

« Si on cherche à transposer le modèle de l’étoile sur Hadoop, on va avoir un énorme fichier de données d’un côté qui va être morcelé sur plusieurs serveurs et de petites tables de dimensions sur une autre machine. Lorsqu’on lance une requête qui nécessite une jointure, cela génère plusieurs jobs qui sont ensuite réconciliés en phase de reduce pour arriver au résultat voulu. On a une mauvaise répartition de la charge : on va solliciter l’ensemble des serveurs car les données sont très éparpillées, on va générer un gros trafic réseau au moment de la réconciliation des données et enfin un pic de consommation mémoire au moment où on consolide les résultats. »

Dénormaliser pour mieux distribuer les charges sur le cluster

Une approche peu performante selon l’expert qui suggère une autre manière d’organiser les données.

« Il faut dénormaliser au maximum les données, on les enrichit de faits dans un même fichier. On va avoir de gros fichiers qui contiennent toutes les données sur lesquelles on va pouvoir requêter. »

De cette manière, les données vont être mieux distribuées sur le cluster et les jointures seront, de facto, déjà réalisées. « Nous allons avoir une meilleure répartition de la charge, beaucoup moins de trafic réseau puisque les agrégations sont déjà réalisées et moins de mémoire consommée lors du reduce. »

Cette dénormalisation engendre une duplication des données et accroit mécaniquement la volumétrie de stockage. Mais avec le Big Data, les volumes de stockage ne sont plus un critère bloquant.

Néanmoins, certaines conséquences sont plus gênantes. « Avec cette démarche, la modélisation est définie a priori et on accroit le nombre de colonnes, ce qui rend le modèle plus difficile à utiliser par le Data Scientist. On connaissait déjà cette problématique avec les univers Business Objects, par exemple, où on pouvait se retrouver avec 400 objets différents. L’utilisateur ne s’y retrouvait pas et seule l’IT pouvait les manipuler au final. »

L’expert évoque différentes pistes pour contourner ces limitations : bien réfléchir au partitionnement des données, utiliser la compression de données, ou encore avoir recours à un format de stockage optimisé, comme le format Parquet créé par Twitter.

Chaque entreprise trouve ses recettes pour concilier gros volumes de données, performances et agilité

Autre écueil de taille à la solution de modélisation a priori évoquée par Cyrille Coqueret, la perte de souplesse pour les analystes. « Les Data Scientists doivent pouvoir se faire leurs propres jeux de données et c’est pour cela que l’on préconise de laisser les données de détail dans les datasets, laisser l’information brute et favoriser une modélisation évolutive. Le format JSON est adapté à cela car il est autoporteur de sa structure. Il permet donc d’ajouter des informations sans problème. »

L’expert a livré à ses pairs quelques astuces comme par exemple basculer les indicateurs habituellement stockés en colonne pour les passer en ligne.

Cette recette, EDIS Consulting l’a appliquée dans le cadre d’un projet réalisé pour le centre de recherche d’un industriel afin de stocker les données de capteurs. Avec un stockage des données par ligne, l’ajout d’un nouveau capteur à chaque ligne ne pose pas véritablement de problème et ainsi le modèle de stockage des données devient indépendant du nombre de capteurs « allumés » lors du test.

Tout en gardant une bonne modélisation et de bonnes performances, les consultants sont ainsi parvenus à conserver de la souplesse, au prix d’un accroissement des volumes puisque les données doivent être répétées à chaque ligne.

Enfin, face à l’accroissement du nombre de colonnes dans les datasets qui les rendent moins lisibles par les Data Scientists, Cyrille Coqueret suggère la création de vues avec un nombre de colonnes plus restreint. Des vues qui répondront à 80% des besoins des utilisateurs. « Au lieu d’avoir des fichiers avec 200, 300 ou 400 colonnes, on va générer des fichiers plus restreints, avec de 20 à 40 colonnes maximum pour qu’ils restent manipulables par un utilisateur final. »

Autre piste creusée par EDIS Consulting pour son client, le couplage à un moteur de recherche. « L’idée, c’est d’indexer les données du dataset pour permettre une recherche full-text ou par colonnes. L’utilisateur saisit sa requête en langage naturel. Il peut alors sélectionner les datasets et les colonnes dont il va avoir besoin, puis exporter le dataset des données qui correspondent à l’analyse qu’il veut mener. »

Pour son client, Cyrille Coqueret a utilisé le moteur Sinequa afin de permettre au Data Scientists de créer eux-mêmes les fichiers de données dont ils ont besoin pour leurs analyses.

Une série de recettes en attendant de voir des meilleures pratiques émerger. « Il n’y a pas encore suffisamment de retours d’expérience dans ce domaine de la modélisation des Data Lakes. Nous pensons que c’est actuellement un frein à la mise en production des projets Big Data » conclut l’expert.

Les communautés travaillent sur de nouvelles solutions… techniques

Face à cette problématique de modélisation, plusieurs pistes ont été évoquées par l’assistance de cette édition du Hug France, notamment le recours à Impala sur du stockage Parquet pour les uns. La solution Kylin a aussi été évoquée par d’autres.

Projet Apache depuis la fin d’année 2014, il s’agit d’un moteur OLAP qui vient s’appuyer sur Hive/Hadoop. L’arrivée de cubes de données (les coboids dans la terminologie d’eBay) recoupe en partie l’approche de Cyrille Coqueret en introduisant de la redondance aux données pour gagner en performance.

Kylin est une solution qui a été initialement développée par eBay pour ses besoins internes et qui est aujourd’hui ouverte à tous sur Github.

Autre solution innovante présentée lors de cette soirée dédiée au Big Data, celle mise en œuvre par Mappy. Devant l’envolée exponentielle des besoins de ses utilisateurs, avec un stockage qui est passé de 10 millions de données agrégées en octobre 2012 à 2,7 milliards aujourd’hui, le Français a eu recours à Map/Reduce d’Hadoop, puis le Big Data In-memory de Spark SQL pour enfin tester aujourd’hui la toute nouvelle solution Big Data « temps réel » du Français DataBig.