Discuter avec des spécialistes de la Data, c’est comme passer une soirée avec des médecins. On entend un florilège de mots compliqués dont la structure peut sembler tellement alambiquée que la signification nous échappe complètement. En bonus et spécifique aux nouvelles technologies (en commun avec le marketing) nous pouvons même avoir droit à des anglicismes dans tous les sens, voire des blagues privées auxquelles on rigole nerveusement sans en comprendre un mot.
Parce que Wikipédia a souvent tendance à présenter les choses de manière complète mais rude pour la compréhension, je vous propose une définition simplifiée des principaux termes utilisés dans la Data, ce qu’ils impliquent et comment ce qu’ils représentent peut vous servir, vous et votre business. Avec un peu de chance, vous deviendrez vous aussi un(e) fin(e) connaisseur(se) et pourrez enfin rire naturellement aux blagues de votre équipe Data …
Pour mieux exposer les concepts, nous allons prendre pour exemple une situation classique, celle d’Alice : jeune entrepreneuse, dynamique et pleine d’enthousiasme. Elle a récemment décidé de lancer une plateforme internationale de streaming vidéo. Ses utilisateurs peuvent mettre en ligne des vidéos, les regarder, les commenter…Son succès est aujourd’hui planétaire et elle songe sérieusement à s’intéresser à la Data, ce pseudo-or noir comme ils en parlent …
Le Lac de données n’est rien de plus qu’un espace de stockage massif (théoriquement une quantité indéfinie) peu coûteux de données (quel que soit leur format !) dans une organisation “libre”. Pour comprendre simplement : le disque dur de votre ordinateur est littéralement un Data Lake : il stocke une quantité potentiellement très importante de données brutes et vous pouvez explorer sa structure grâce à votre explorateur. Sa performance de requêtage n’est en général pas extraordinaire, et est dépendante de la manière dont vous allez répartir la donnée en répertoires (appelés aussi partitions). Grâce à la grande diversité de la donnée, c’est également lui qui sera la base de travail pour les Data Scientists qui vont par exemple explorer la donnée, travailler sur du Machine Learning, expérimenter des transformations…
Pour prendre notre exemple initial : un Data Lake peut être une bonne solution pour stocker ses vidéos. Les utilisateurs téléversant en grande quantité, Alice va avoir besoin d’un espace élastique de stockage, dont le coût n’explosera pas avec cette quantité. Parce que les vidéos sont indexées par utilisateur et qu’Alice aimerait avoir un minimum de performances, elle va organiser son Data Lake avec un répertoire par utilisateur, chaque répertoire stockant toutes les vidéos dudit utilisateur.
A titre anecdotique : le Data Lake n’imposant par nature aucune structure, il peut se transformer chez certains en Data Swamp, traduisant un marais de données dans lequel l’ordre n’est qu’un lointain souvenir …
Exemples de solutions de Data Lake : AWS S3, Azure Blob Storage, GCP Cloud Storage, Apache Hadoop…
Pour Extract Transform Load, littéralement “extraire”, “transformer” puis “charger”. L’ETL caractérise les actions de récupération de la donnée d’un flux (temps-réel ou non), application de transformations, puis retransmission vers un autre emplacement. Ces opérations peuvent correspondre à n’importe quelle fonction informatique : une agrégation sur une fenêtre temporelle, un enrichissement d’enregistrements, une extraction d’un sous-ensemble de données, …
Reprenons la situation d’Alice : sa plateforme est beaucoup utilisée, et à des fins d’amélioration elle aimerait obtenir quelques informations clés. Par exemple, elle souhaiterait connaître en temps réel le nombre d’utilisateurs qui regardent une vidéo sur sa plateforme à chaque minute qui passe.
Elle va donc pour cela avoir besoin d’une chaîne d’ETL : son application mobile envoie constamment des événements lorsque son utilisateur lance une vidéo. Cette dernière chaîne intervient donc en faisant une agrégation sur une fenêtre de temps d’une minute. Très simplement, ce n’est rien de plus qu’un programme informatique qui va récupérer les événements pendant une minute, tout compter puis retransmettre son résultat. Et voilà ! Une première métrique simple qu’elle va pouvoir réutiliser dans ses sublimes tableaux de bord.
Exemples de solutions d’ETL : AWS Glue, Azure Data Factory, GCP DataFlow, Apache Spark, …
L’entrepôt de données, est une forme de Data Lake amélioré ou spécialisé. Tout y est bien organisé, facilement accessible, avec un volume très élevé (comparativement plus faible que celui du Data Lake ceci dit). Vous pouvez en récupérer à n’importe quel moment de très grandes quantités de données et l’information qu’il contient s’accumule sans cesse. Sa principale distinction se trouve autour de la structuration temporelle de son stockage et la forme particulière de sa donnée.
De manière plus pratique, une Data Warehouse est en réalité une base de données améliorée pour être capable de gérer facilement des requêtes demandant d’analyser potentiellement des Gigas-Octets de données. Pour ce faire, elle répartit l’information sur plusieurs disques en concurrence, lui permettant à la moindre requête de lire plusieurs secteurs de stockage en même temps.
En plus de sa structure matérielle, la forme dénormalisée de sa donnée lui permet également d’optimiser ses performances. En effet, quitte à prendre plus d’espace, la Data Warehouse va stocker des enregistrements dont une partie de l’information peut se répéter, pour lui éviter des opérations coûteuses de matching lui faisant initialement économiser de l’espace.
Pour prendre à nouveau notre situation : comme Alice aime les belles visualisations synthétiques, elle aimerait voir la répartition de vidéos vues sur l’année, par catégorie de contenu. Pour ce faire, à chaque fois qu’un de ses utilisateurs termine de regarder une vidéo, un événement est envoyé à son architecture Data. Une pipeline d’ETL enrichit la donnée de chaque enregistrement afin de lui intégrer des informations de son utilisateur et de la vidéo (sa tranche d’âge par exemple, la catégorie de la vidéo…). Tout ceci correspond à une quantité massive d’enregistrements. Elles vont donc être intégrées dans une Data Warehouse. Alice pourra alors innocemment demander à son entrepôt les enregistrements de l’année entière pour réaliser son “élémentaire” visuel.
Pour résumer, une Data Warehouse correspond simplement à une énorme base de données capable de lire de manière concurrente sur beaucoup de disques SSD une donnée structurée et optimisée pour le requêtage de masse.
Exemples de solutions de Data Warehousing : AWS RedShift, Azure Synapse Analytics, GCP BigQuery, Apache Hive,Snowflake, …
Le Centre de Données correspond à un espace virtuel dans lequel il est possible de référencer et requêter l’ensemble de vos sources de données. Son objectif n’est rien de plus qu’une centralisation de l’information que vos systèmes sont capables de vous mettre à disposition. Son plus se situe dans sa capacité à avoir connaissance de la structure (ou non) de la donnée de chaque source, et la possibilité de la requêter afin d’en obtenir rapidement une information.
Repartons avec l’entreprise d’Alice, aussi fougueuse que l’originalité de son concept : sa donnée se situe dans une pluralité d’endroits. Le Data Lake des vidéos, la base de données métier (utilisateurs et informations des vidéos), la Data Warehouse d’événements en temps-réel, mais aussi (par exemple) les fichiers des normes de chaque pays sur ce qu’il autorise à diffuser ou non, son CRM référençant les clients annonceurs intéressés, le Google Analytics d’utilisation de votre application… Tout ceci représente une potentielle grande diversité de sources, que le Data Hub est là pour répertorier. Dorénavant, Alice pourrez automatiquement savoir à partir des informations client du CRM la quantité de vidéos qui correspondraient à ses attentes, et la masse d’utilisateurs susceptibles d’être intéressés par celles-ci.
Exemples de Data Hubs : Azure Purview, Data Hub, …
Toute structure génère par nécessité de la donnée. Qu’elle soit issue du domaine métier, d’interactions avec des terminaux, ou même de l’internet des objets. Toute cette donnée est par essence source de valeur. Dans notre exemple de streaming de vidéos, mieux connaître les habitudes des utilisateurs, mais aussi les principales métriques de la plateforme en général permettrait d’obtenir des indicateurs précis et surtout essentiels pour l’avenir du business. Quel que soit le modèle de rémunération associé, mieux connaître son métier ne peut qu’être bénéfique dans une approche Data Driven d’amélioration continue.
Chaque chose en son temps ! Vous n’avez à priori pas de nécessité de démarrer tout de suite une énorme Data Warehouse et des centaines de jobs d’ETL.
Le plus important est de collecter la donnée que vous générez afin d’en faire une étude exploratoire. L’objectif est par exemple de créer ou d’utiliser des connecteurs pour exporter votre donnée vers un Data Lake, sans prévoir pour le moment de travail dessus. Vous emmagasinerez comme cela et à bas coût un historique de connaissances qui sera par la suite prêt à être valorisé.
Une fois suffisamment de données collectées (cela dépend de vous : trois jours, plusieurs semaines, quelques mois), à vous et vos équipes d’aller regarder ce qu’il s’y passe. A l’aide d’outils comme PowerBI, Apache Superset,QLik (outils de Business Intelligence) ou simplement d’un Notebook Python/SQL, vous allez pouvoir tenter de mettre en relation des informations, les transformer à la volée et chercher des relations qui ont du sens pour votre métier. L’idée est simplement de créer l’ébauche qui vous permettra de valoriser la donnée que vous générez. Ne vous forcez pas à utiliser tout ce que vous pourriez utiliser, et préférez vous servir de données qui vont vraiment vous être bénéfiques au quotidien.
Prenons un exemple : Il vous est (dès aujourd’hui) possible d’exporter quotidiennement toutes les interactions de vos utilisateurs dans le Data Lake d’AWS, S3. Au bout d’un mois, vous pouvez connecter un outil de Business Intelligence (PowerBI, Quicksight) à ce Data Lake pour que vous puissiez le requêter en direct et créer sans plus attendre à partir de votre donnée !
Si votre métier génère des quantités de données faibles, il est probable que vous ayez déjà atteint le bon niveau d’optimisation entre valorisation de données et coûts d’infrastructure. Cela dit pour plus de confort ou si vous souhaitez aller plus loin, vous pouvez continuer en créant vos jobs d’ETL qui exporteront la donnée que vous aurez sélectionné (en la structurant) vers votre Data Warehouse flambant neuve. Les mêmes outils de Business Intelligence préféreront s’y connecter plutôt qu’au Data Lake, et bénéficieront de performances nettement améliorées.
Une fois vos pipelines de données bien définies, peut être sera-t-il temps de songer à utiliser votre donnée pour autre chose que de la Business Intelligence. Par exemple, mettre à disposition votre donnée à vos utilisateurs en Open Data, ou encore créer vos modèles d’Intelligence Artificielle et de Machine Learning. Bref, le monde s’offre à vous…
Merci d’avoir pris le temps de lire.