Par Alexandre Lepage, Directeur principal, Entreprise numérique
J’ai participé à deux reprises au cours des dernières semaines à une présentation conjointe Larochelle – Microsoft sur l’offre actualisée en analytique et intelligence d’affaires de Microsoft (Power BI, SQL Server Reporting Services, Office Excel); les deux représentations, l’une à Québec et l’autre à Montréal, ont remporté un grand succès et je remercie à nouveau les auditoires respectifs pour leur présence et leur accueil.
Une des diapos préparées pour positionner l’usage opportun d’un outil de visualisations interactives comme Power BI contenait l’architecture analytique « moderne » suivante :
(Rendons à César ce qui lui revient : il s’agit de l’adaptation française d’une architecture proposée par James Serra dans son article de blogue « What is a data lake? ».)
Compte tenu du grand intérêt que cette diapo a suscité tant dans la Capitale que dans la Métropole, en particulier le data lake, je me disais qu’il serait judicieux de démystifier ce concept dans un article de blogue.
Qu’est-ce qu’un data lake justement ?
Un data lake est d’abord et avant tout une expression malheureuse introduite par James Dixon de Pentaho il y a quelques années pour définir un dépôt de données brutes et disponibles en vrac pour usage potentiel, en distinction d’un dépôt de données formattées et organisées à des fins spécifiques (un entrepôt de données par exemple).
Le data lake est fréquemment mentionné dans un contexte d’initiatives impliquant des données massives, mais ses principales caractéristiques font de lui un composant sensé d’une architecture analytique complète :
- il permet de stocker un volume considérable de données hétérogènes, structurées ou non, sur site ou dans l’infonuagique, grâce à une capacité extensible;
- il conserve les données dans leur état quasi-natif (conversion de types et ajout de métadonnées sont à prévoir), il offre des possibilités d’archivage et de traçabilité des plus utiles;
- les données n’ont pas à être transformées : elles peuvent être chargées systématiquement et efficacement;
- elles n’ont également pas à être modélisées : un data lake peut donc être développé rapidement, parfois automatiquement même, laissant ainsi la chance à des utilisateurs motivés de profiler et/ou fouiller les données sans tarder, voire de raffiner un éventuel modèle dimensionnel subséquent.
Remarquez que je ne précise aucune plateforme particulière ici : comme tout bon concept, le data lake est agnostique quant à la technologie et mentionner une distribution Hadoop donnée, un data lake Azure ou un bon vieux serveur relationnel à ce stade-ci me semble prématuré et accessoire.
Est-ce vraiment un nouveau concept ?
Les pros du marketing sont passés maîtres dans l’art de faire du neuf avec du vieux, et Dieu sait qu’ils sont plutôt criards en cette ère de quatrième révolution industrielle, mais non, je ne crois pas que le data lake soit un nouveau concept en soi :
- historiquement, on considérait un Operational Data Store (ODS) pour y verser des plages de données sources en attentes d’intégration dans un entrepôt de données en aval et afin de limiter l’impact de traitements significatifs dans les systèmes informationnels en amont;
- plus près de nous, les adeptes du data vault (ou de SAP!) suggèrent l’utilisation d’un Persistent Staging Area (PSA) pour y archiver des données brutes, mais versionnées le temps qu’il faudra pour bien préparer et stabiliser la couche de données suivante;
- quelle que soit l’école de pensée, garder quelque part une copie des données sources avant leur réorganisation et réassemblage dans une quelconque structure analytique était et demeure une excellente pratique : le faire dans un data lake me semble tout à fait en continuité avec cette règle de base.
Les loups de mer du data lake pourront faire allusion à l’aspect innovant de stocker des données semi-structurées (XML, HTML, etc.), non-structurées (textes, images, etc.) ou provenant d’objets connectés en réponse à des objectifs analytiques, mais, fondamentalement, le principe de conserver minutieusement des données sources peu importe leur nature n’est pas inédit.
Est-ce indispensable ?
Loin de moi l’envie de philosopher sur l’indispensabilité des choses en général, mais disons simplement que mes équipes et moi favorisons fortement l’emploi d’un data lake dans nos projets, ne serait-ce que pour une et une seule raison : il nous offre une marge de manœuvre.
Les bénéfices de l’intelligence d’affaires et de l’analytique des données sont directement proportionnels à la capacité de passer des données à l’information. Pour ce faire, une plateforme analytique digne de ce nom devra tôt ou tard exposer une version organisée, conformée, agrégée, lissée des données qui résultera d’efforts de modélisation rarement triviaux. Recenser et synthétiser les requis d’affaires, s’approprier un domaine d’application, identifier les bonnes sources et s’assurer de la qualité des données, comprendre les cas d’utilisation et gérer les dépendances et priorités pour ultimement modéliser et produire sont toutes des activités chronophages et, à une époque où les alternatives de stockage et de traitement sont nombreuses et bon marché, le temps demeure rare et précieux. Bien modéliser prend du temps : des idées changeront, des erreurs seront commises et devront être corrigées, les objectifs et plans d’affaires d’aujourd’hui ne sont pas toujours ceux de demain et un modèle devra être ajusté, etc.
Pouvoir accumuler des données rapidement et économiquement tout en se laissant la chance de recommencer pour pallier à une telle dynamique me semble un avantage indéniable : en ce qui me concerne, une transition par un data lake procure, sinon cet avantage, du moins une police d’assurance contre les naufrages.
Est-ce pour tous ?
Le data lake est un outil et, comme tout outil, il n’est bon que dans la mesure où il est employé dans des fonctions pour lesquelles il a été prévu. Une grave erreur alors serait de croire qu’un data lake remplace un entrepôt de données : plutôt, il en est le complément; mieux, il constitue son réservoir.
La prémisse fausse de l’analytique des données dans l’entreprise numérique est de croire que tous les utilisateurs sont des analystes qui veulent et peuvent accéder aux données librement pour produire leurs visualisations eux-mêmes et tirer leurs propres conclusions; ce n’est déjà pas le cas lorsqu’un entrepôt de données robuste est disponible, ce ne peut être vrai si seul un data lake est accessible. Oui, réaliser un entrepôt de données est complexe, mais au-delà des nombreux défis techniques que présente une telle traversée, il y a des enjeux de cohérence et de gouvernance qu’un data lake ne résout absolument pas (à dire vrai, de tels enjeux requièrent des solutions davantage humaines que technologiques, mais ce sera pour un autre article).
Traverser un data lake sans s’y noyer est pour nageurs aguerris seulement et n’est pas Michael Phelps qui veut; pour les autres, interroger un entrepôt de données, plus souvent par l’entremise de visualisations prédéfinies qu’en mode libre-service, demeure, et demeurera pour un bon moment encore, une approche pertinente et privilégiée.
Conclusion
D’aucuns proposeront des arguments de vélocité et de fluidité pour défendre le data lake : j’en suis. D’autres contre-argumenteront avec la désorganisation tourbillonnaire des données qui y sont contenues : j’en suis également. Utilisé à bon escient, comme dépôt de données intermédiaire, un data lake présente des options très intéressantes; mal maîtrisé, on peut se retrouver dans un data lake à broyer des fadaises comme Alain Bashung dans sa cité lacustre !
Je ne sais pas si un article de blogue suffit à couvrir un tel sujet, mais il permet certainement d’ouvrir un débat; à ce propos, que pensez-vous du data lake ?