Pourquoi et comment déployer un Data Lake

Avec l’arrivée des technologies Big Data, l’idée de construire un référentiel de toutes les données d’entreprise est aujourd’hui réalisable. Beaucoup de professionnels se constituent un Data Lake, mais attention à ne pas commettre d’erreur.

C’est incontestablement le terme le plus en vogue dans le monde du Big Data. De plus en plus d’entreprises françaises se sont engagées depuis quelques mois dans la constitution d’un « Data Lake » ou lac de données.

Didier Kirszenberg, HPE

« Le Data Lake répond un peu au Graal historique : le référentiel de données unique de l’entreprise » explique Didier Kirszenberg, responsable des architectures Massive Data chez HPE France. « Avec Hadoop nous pouvons stocker la donnée et lui poser plusieurs masques de structuration à postériori. Il est devenu techniquement possible d’envisager de réussir cette centralisation unique de la donnée. »

 

 

Un référentiel tant pour les données structurées que semi-structurées

Techniquement, le Data Lake n’impose plus une « pré-structuration » de la donnée comme cela est exigé par un data warehouse classique. Par contre, il invite à adopter une approche différente puisque l’entreprise va y faire cohabiter des données très structurées, semi-structurées et non structurées.

Les caractéristiques de ces données seront très diverses. Celles issues d’un ERP restent relativement simples à interpréter. Des données de capteurs issues de l’IoT, ou encore des logs techniques, rendent la notion de timestamping primordiale. L’ordre de collecte devient extrêmement important si l’on souhaite comprendre un phénomène. En outre, il faut alors réconcilier les données manquantes dans une série, redresser les données erronées, etc. « C’est une problématique que nous n’avions pas réellement dans la BI traditionnelle, où l’essentiel de la tâche à effectuer portait sur la réconciliation d’informations issues de différentes sources. Certaines solutions, comme Vertica par exemple, ont des fonctions natives de réconciliation des données manquantes dans les séries. C’est une fonction native, car la solution est bâtie pour le Big Data. »

Une autre dimension dont il faut tenir compte, c’est veiller à ne pas faire disparaitre les signaux faibles si importants pour les data scientists. « Traditionnellement, lorsqu’on faisait du décisionnel ou de l’analytique, on cherchait à comprendre les comportements génériques, rappelle Didier Kirszenberg. On faisait de l’échantillonnage et tout ce qui paraissait anormal était écrêté. L’une des propositions de valeur du Big Data, c’est d’exploiter les signaux faibles. Or si on a écrêté les données, on aura perdu ces signaux faibles, ces données atypiques. Il faut donc se poser la question de savoir si ces données résultent d’un comportement atypique ou s’il s’agit d’une erreur de collecte. Cela signifie aussi que la qualité de données n’est pas qu’une démarche purement technique, mais concerne aussi les métiers. »

La qualité des données, clé de la réussite du Data Lake

Si la technologie Hadoop, mais aussi la baisse du prix des moyens de stockage, permet de constituer de gigantesques référentiels de données à partir desquels les data scientists vont pouvoir générer de la valeur, Didier Kirszenberg réfute l’idée comme quoi l’entreprise doit stocker toutes les données brutes qu’elle a à sa disposition. « La vraie difficulté du Data Lake, réside dans la manière dont il est constitué. Il ne s’agit pas d’envoyer tous les flux de données puis de réfléchir plus tard sur comment exploiter ces données. Il y a un vrai sujet sur la qualité des données. Si on envoie tout et n’importe quoi dans un Data Lake, on recrée les écuries d’Augias. »

Cette problématique de qualité des données, cruciale pour l’intérêt même d’un Data Lake, est particulièrement aiguë sur la donnée non structurée. Constituer un Data Lake de qualité est un projet plus complexe qu’il n’y paraît, car, au-delà de la technique, cela touche aussi à l’organisation, et c’est pour cela qu’il faut nommer des responsables de la donnée, constituer toute une chaine en amont afin de s’assurer de la bonne alimentation du Data Lake avec des données de qualité.

« Pour prendre un exemple, dans le monde de la banque, on s’aperçoit que les codes APE utilisés pour qualifier l’activité des entreprises ne sont pas les bons. Un McDonald’s se verra classé en tant que restaurant et non Fast Food, un Décathlon comme vendeur de chaussures et non magasin d’articles de sport. C’est au métier de dire que tel ou tel code n’est pas correct. Cela n’a rien d’une problématique technique. » Si l’erreur n’est pas corrigée en amont, les algorithmes délivreront des informations faussées en sortie et il sera très difficile de corriger ces erreurs au niveau du Data Lake.

HPE Data Lake

Le Big Data, un monde en innovation permanente

Techniquement, du fait des volumes mis en jeu, une architecture Data Lake est systématiquement dans une approche « scale out ». Néanmoins, quand nous parlons de scale-out, cela n’est pas synonyme de matériel banalisé. Les configurations sont dépendantes des types d’usages qui vont être faits du Data Lake. « Il y a 5 ans nous avons inventé la notion de serveurs x86 hyper-storage. Il s’agit de serveurs x86 qui vont avoir jusqu’à 70 disques et monter des disques avec jusqu’à 10 To de capacité unitaire. Dans le Big Data, le recours à de tels disques est courant lorsqu’on fait du stockage objet sans vocation d’analyse. Par contre, pour faire de l’analyse, nous allons privilégier des disques plus petits et plus performants. »

Les usages du Data Lake évoluent encore rapidement. Les entreprises ont commencé voici quelques mois à exploiter le Machine Learning et elles testent désormais le Deep Learning. « Nous déployons désormais des architectures à base de GPU dans des clusters Big Data et c’est une problématique qui n’existait pas encore il y a 6 mois de cela, témoigne Didier Kirszenberg. C’est la raison pour laquelle concevoir des appliances pour Hadoop est contre-productif : comment créer des appliances dans un domaine où les usages changent aussi rapidement, où les spécifications évoluent aussi vite ? »

La courbe d’innovation du Big Data reste encore très pentue et nous commençons à voir apparaître des notions de Data Tiering sur Hadoop, de même que l’Erasure Coding pour répondre au besoin de la protection de ces énormes volumes de données alors que la réplication classique et le RAID arrivent à leurs limites. Où s’arrêteront les innovations autour du Data Lake ? Nul ne le sait. Un écosystème extrêmement riche s’est construit autour d’Hadoop avec de nombreuses offres et outils additionnels. Une startup comme Esgyn brise toutes les frontières puis qu’elle propose de faire du transactionnel ACID au-dessus d’Hadoop. Le Data Lake arrive dans les entreprises et il est là pour longtemps.