25 mai 2018
– 4 min de lecture
Jean-Baptiste Piccirillo
Manager Transformation Data
Plusieurs questions se posent aujourd’hui, alors que de nombreux environnements Hadoop sont en production depuis quelques mois / années :
- Le Data Lake est-il aussi utile/utilisé que prévu ? et ne l’utilise-t-on pas, à défaut d’avoir trouvé un usage pertinent, à des fins qui n’étaient pas prévues au départ ( exemple courant … GPP : Gros Passe Plat ou encore EDDC : Extracteur De Données Centralisé … )
- Comment structurer les données dans le Data Lake ? Si c’est pour mettre un Hadoop chez soi et structurer sa donnée dans quelques parquets et des tables hive, mais avec la même logique que nos bonnes vieilles tables SQL normalisés 3NF, à part de dire « Youhou, hadoop on l’a fait, on en a une belle maintenant ! » Quel intérêt ? C’est comme s’acheter une console Switch en ne la décrochant jamais de son socle (pardon pour l’image pour ceux qui ne connaîtraient pas la dernière console de Nintendo…).
- Comment on rend la valeur de l’outil palpable par l’utilisateur final ? Que ce soit pour du reporting quasi temps-réel / journalier / mensuel, de la Data Viz ou de l’analyse de données avancée (un super Random Forest, un neural Network au top en production…) qu’est ce qui fera la différence pour l’utilisateur final ? Par rapport à ce qu’on lui donnait déjà avant…
J’essaie de donner des éléments de réponses ci-dessous et ce n’est que mon humble avis. Si vous avez vos expériences à partager n’hésitez pas.
1 – Le data lake est-il aussi utile/utilisé que prévu ?
Les environnements distribués naissent un peu partout au moment ou j’écris ces lignes. 2 cas caractéristiques existent qui peuvent être problématiques :
Cas 1 – Etre gourmand, trop gourmand : De nombreuses entreprises se sont ruées vers la tendance sans même vraiment avoir eu une réflexion de fond sur la valeur que devraient leur apporter ces nouvelles capacités dans leur contexte, elles se retrouvent aujourd’hui avec des téras stockées qui ne leur apportent pas autant qu’elles l’auraient espérées. On a voulu en mettre beaucoup, on n’a pas pris le temps de travailler sur la description de ce qu’on y a mis (meta data), et peu de gens comprennent vraiment ce qu’on peut y trouver et si c’est vraiment fiable.
Leur Data Lake devient petit à petit un passe-plat facilitant préparations et fournitures de certaines données bien spécialisées, même sur des volumes qui ne justifient en rien son usage, opérant quelques croisements ici et là entre sources originales qui n’étaient pas avant dans le même environnement technique. Elles font face à des bi-modes Hadoop VS Entrepôt Oracle/SAS (pour ne donner qu’un exemple). Certaines données sont dans les deux types de système et l’utilisateur Analyste ne sait pas vraiment lequel utiliser. Alors les Data Scientist, statisticiens – vieux de la vieille continuent à bosser dans SAS parce qu’ils n’ont pas le temps d’apprendre Python, et les petits jeunes qui sortent d’écoles pensent pouvoir changer le monde avec leur modèle de churn codé en Python / Spark mais qui a en réalité déjà été implémenté il y a 10 ans par un Data Miner expert SAS avec une méthode et des résultats similaires… Ce n’est qu’un rien caricaturale.
Pour prouver sa valeur et justifier son coût, ce Data Lake là va devoir se recentrer sur des usages clés porteur de valeur (et de gain euros…) pour l’entreprise, qui justifie son existence, ou mourir de désillusion ou rester un gros GPP (gros passe plat…).
Cas 2 – Etre timide, trop timide : D’autres entreprises plus prudentes, fonctionnent en petites itérations, à base de POC Big Data sous Microsoft AZURE, AWS et autres google cloud, en sélectionnant des cas d’usages qui justifient l’utilisation de telles plateformes. Parfois, le risque est d’être dans l’excès inverse du premier cas, en priorisant trop et en ne montrant rien.
Trouver 3 usages coeur de métier pour commencer est une excellente chose, mais les cas d’usages doivent être assez complets pour montrer l’étendue des possibilités que peut apporter un environnement comme hadoop et tous ses petits (la multitude d’outils d’intégrations, d’analyses, de traitements qui se basent sur hadoop).
Toutefois, faire un vrai POC métier est la clé pour les entreprises qui en sont à ce stade, montrer que Hadoop traite très très très vite un très très très gros volume de données, n’apporte rien au métier. Faire une démo d’un outil métier qui illustre un vrai cas métier en mettant en valeur :
- La performance ressentie par l’utilisateur (des jolis diagrammes qui s’affiche rapidement quand l’utilisateur clique sur la carte 🙂 « C’est beau, ca va vite, c’est utile ! ouaouh ! »
- La valeur/connaissance apportée en plus en allant au bout de l’usage : On sait détecter un problème, une fraude, etc…et ça génère une alerte en temps réel dans l’outil de l’opérateur qui lui recommande l’action à faire ! Ouaouh merci c’est ce qui fallait ! c’était possible alors ? dingue…)
Dans tous les cas, encore une fois allez au bout de l’usage ! On a tendance à s’arrêter juste un peu avant ce qu’il faudrait (par manque de temps, de connaissance métier, de courage). Ne faites pas un POC IT, ayez le courage de faire un vrai POC business pas juste à moitié parce que vous ne connaissez pas assez le métier, allez jusqu’au bout de la démonstration, jusqu’à la jolie petite interface interactive qui fera la différence. Sinon vous n’aurez pas votre Waouh. Faites collaborer les Data Scientist avec les développeurs des appli métiers pour avoir un vrai résultat.
Si vous ne faites pas cela, les gens comprendrons peut être la théorie « D’accord vous faites une grosse boîte où vous mettez toutes les données et puis ça tourne vite comme une machine à laver, c’est ça ? 🙂 ».
Non ! vous voulez un : « Ah, mon opérateur ne va plus devoir scruter toutes les logs à la mano pour essayer de trouver les problèmes, et je vais multiplier par 10 ma productivité donc…En fait…Ai-je toujours besoin d’un opérateur ? » OUI, là on est bon.
2 – Quelques principes pour structurer le data lake
Ne traitez pas votre Data Lake comme une poubelle à données qu’on recyclera peut être un jour en cas de besoin (le fameux « on prend, on sait jamais » du Data Lake, anti GDPR par dessus le marché). Mais traitez le bien comme un lac nourrissant, abreuvant et vital ! Moins de quantité, plus de qualité.
Structurer vos Données intelligemment. Ce n’est pas parce que vous avez beaucoup de place que vous pouvez en mettre de partout et n’importe comment (que dirait votre mère franchement?). Votre Data Lake doit normalement séparer :
- Les données sources (Raw Data) à l’image des données du système sources
- Les données sources (Raw Data) retraitées uniquement par applications de règles purement techniques (votre format de date standard, types de données, etc…). Pas de règles métiers ! Pas ici, le but est juste de récupérer la donnée brute ! C’est d’ailleurs un sage principe que vous trouvez aussi dans la philosophie DataVault de Dan Linstedt. Vous n’appliquez des règles métier qu’au moment de la construction de vues métiers qui répondent à un usage donné. C’est aussi surtout du bon sens…Cela apportera bien plus d’agilité à l’ensemble du système.
- Une Historisation structurée et intelligente des données du Data Lake. « OH Non ! Il a dit « structuré » et « Data Lake » dans la même phrase le monsieur, c’est pas joli ». Malheureusement, beaucoup d’entreprises oublient cette étape. Mais pourquoi donc ? Suivez par exemple ici (encore désolé…) la modélisation Data Vault 2.0, je parle principalement des concepts de Hubs, Links, Satellites, ou au moins la philosophie pour cette partie. Vous pouvez éventuellement exclure de cette phase certaines données exceptionnelles (par exemple si ce sont des données vraiment peu utilisées très spécialisées, que vous savez ponctuelles comme des données externes one shot (que vous n’achetez pas tous les mois…).
!!! Attention je ne dis pas qu’il faut faire un Data Warehouse d’entreprise dans le Data Lake (je ne rentrerai pas dans ce débat). Le Data Lake doit couvrir un certain nombre de cas d’usage spécifiques, qui nécessitent d’historiser (avec agilité !) un certain périmètre de données, qui tend à grandir au fur à mesure que les nouveaux cas d’usages apparaissent.
Si vous vous arrêtez aux Raw Data et aux business View et que vous ne mettez rien entre les deux, que vous ne faites pas ce travail de structuration fonctionnelle, au bout d’un moment vous aurez un gros sac de données applicatives, et les Data Scientists et autres utilisateurs devront eux même comprendre la logique de recoupement de toutes les sources (notamment le grain, la définition des clés techniques/métiers, etc.). Faites ce travail de structuration de l’historisation (DataVault 2.0 recèle de bonnes idées).
- Les données préparées pour être prêtes à l’Usage (Business View), requêtables rapidement pour usages business. C’est dans la consolidation de chacun de ces socles que les règles métiers sont appliquées ! Ici, On ramène les données au plus proche de l’usage et structurées pour l’usage en question. Et n’hésitez pas à dé-normaliser vos Business View! Vous n’êtes pas dans mysql… Plein de lignes et plein de colonnes ? C’est fait pour ! Vous pouvez même aller (dans certains cas) jusqu’à pré-calculer dans une grosse table adaptée tous les indicateurs sur toutes les combinaison de segments (dimensions), de périodes, de dates… (attention, intérêt à mesurer par rapport à votre propre usage de consommation de la donnée), mais ça se fait : « ouahou ! comme les graphiques s’affiche vite… »
- Les métadonnées : leur intégration peut se faire de diverses manières, mais faites en sorte que les gens ait confiance aux données qu’ils utilisent (C’est quoi cette donnée ? d’où vient la donnée ? quelle application, quel fichier source ? Qui l’a saisie ? Quand l’a-t-on intégré au Data Lake ? quelle fréquence de mise à jour ? etc.)
3 – Comment on rend la valeur de l’outil palpable par l’utilisateur final ?
- Ne croyez pas (et je suis sûr que vous ne le croyez pas) que votre Data Lake se suffit à lui même
- S’il est déjà bien structuré (c’est déjà un gros avantage), il a quand même besoin de belles décorations :
- je ne vous apprendrai rien : un outil de Data Viz/report qui plaît au métier (parce qu’il a été impliqué dans son choix…). Je ne ferai pas de pubs ici…
- Une bonne intégration avec les systèmes opérationnels et dans les deux sens (un savoir faire sur le sujet), pas qu’en collecte. Par exemple : Lancer des simulations directement depuis mon application de gestion qui va lancer un job spark sur la business view associée qui elle va renvoyer des résultats en un rien de temps sur l’application de gestion : L’utilisateur est heureux, il ne connaît pas Hadoop ou Spark, il ne veut rien en savoir, mais vous avez amélioré significativement sa façon de travailler. C’est ce qu’il faut viser. C’est cela aller au bout de l’usage.
- Un environnement complet d’analyse pour vos Data Scientist (Data Viz, développement IDE, collaboration/gestion de version, notebooks, les bonnes librairies de dev !) parce qu’ils en ont besoin. Impliquez réellement les principales personnes concernées dans ce choix !
Pour conclure, les idées clés :
- Les usages doivent toujours driver la construction itérative de votre Data Lake
- Ne cherchez pas à refaire un/des Data Warehouse 2 sans vraiment savoir par qui, pour quoi ce sera utilisé, ne cherchez pas à manger un maximum de données pour devenir le plus vite possible la plus grosse base de données et justifier le nom de votre équipe, BIG Data, j’imagine…
- Si on vous pousse un usage auquel on pourrait répondre sur une base mysql, redirigez gentiment le destinateur…A moins que vous soyez force de proposition pour faire évoluer son usage pour justifier l’utilisation d’une telle plateforme.
- Si vous êtes assez matures, ne voyez plus votre Data Lake comme un Lab collecteur qui se suffit à lui-même, si vous allez au bout des usages, vous serez obligés de l’intégrer avec des applications métier (vous savez, l’utilisateur qui clique dans son appli et ça lui sort toute sa simulation en 0.5 secondes…).
- Inspirez-vous de la philosophie de monsieur Data Vault 2.0 (Dan linstedt) (je ne dis pas qu’il faut tout prendre, mais au moins inspirez vous des concepts de Hub / Links / Satellites qu’un enfant de 4 ans peut comprendre pour une structuration agile de l’historique de vos données). Cela évitera bien des noeuds au cerveau à vos utilisateurs, Data Engineer et Data Scientist, et cela apportera de l’agilité au bout du compte.
- Dé-normaliser vos vues métiers ! Dénormalisez vos étoiles, vos 3NF, ça ira bien plus vite !
- Le Data Scientist « Stateu » doit ouvrir les yeux au Data Scientist « Informaticien » sur ce qu’il est vraiment en train de faire tourner. Le Data Scientist « informaticien » doit apprendre au Data Scientist trop « stateu » à produire du code industrialisable et réutilisable. Recrutez les deux types de profils (Ecoles de stats, et école d’ingé informatique)
- Si vous faites collaborer vos Data Scientist avec les équipes de développements des applications métiers, alors c’est que vous êtes sur les bons usages…
Les autres articles qui peuvent vous intéresser
18 octobre 2023
Transformation Data
