Les données opérationnelles de l’entreprise sont stockées dans des bases de données, le plus souvent structurées et relationnelles. Elles sont structurées dans le sens où elles conservent des données structurées, mais également parce qu’elles sont elles-mêmes dotées d’une structure. Tables, champs, dimensions, variables, tout cela concourt à structurer les données avant de les stocker. Elles sont ensuite conservées dans cette structure et accessibles facilement en utilisant la structure comme moyen de navigation.
Principal inconvénient de ce mode de fonctionnement, les modifications de structure peuvent être complexes, coûteuses en ressources machines et parfois même impossibles à appliquer sans perdre une partie des données. Les choix initiaux de modélisation de la base de données sont donc structurants.
Cela s’applique parfaitement à des données de gestion, financières, pérennes, mais se révèle moins adapté lorsqu’on connaît mal en amont les traitements qui seront appliqués en aval.
Après les infocentres, aussi structurés que les bases opérationnelles, sont apparus les entrepôts de données. Les « data warehouses » ont permis de centraliser toutes les données structurées en silos dans les bases opérationnelles, et de les regrouper dans un même entrepôt.
On a alors appliqué une modélisation en étoile afin de garder le détail de l’information à la granularité la plus faible, et de lui appliquer le plus de dimensions possibles pour maximiser les possibilités d’agrégations et de recherches.
Si l’information la plus détaillée a été conservée, il est ensuite possible de modifier les axes de recherche, les dimensions. Mais bien souvent il est nécessaire, pour des raisons de coût ou tout simplement d’espace de stockage, de faire des choix et lors de la modélisation en étoile, des regroupements sont faits qui aboutissent eux aussi à une forme de structuration de l’information.
Par ailleurs la modélisation en étoile convient bien à des données structurées, relativement prévisibles. Elle est moins adaptée à des données non structurées comme celles issues des réseaux sociaux.
L’apparition des systèmes de stockage arborescents comme Hadoop a ouvert de nouvelles perspectives. Lorsque le besoin est de stocker de gros volumes de données à structures variables, mais surtout dont on ne sait pas à l’avance comment elles vont être utilisées et analysées, apparaît le concept de lac de données.
Schématiquement une bases de données relationnelle, ou un data warehouse, sont des structures verticales. La structuration des hiérarchies, des dimensions, leur donne de la verticalité, de la structure. Ils sont donc ensuite difficile à déconstruire si l’on souhaite en modifier l’organisation. Un peu comme un gratte-ciel, si votre entrepôt de données prend de la hauteur et conserve de plus en plus de données, sa déconstruction devient problématique si vous souhaites changer d’angle d’analyse.
Un lac de données est à l’inverse totalement plat, sans structure. Les données sont conservées sur le même plan. La structure est alors créée au moment de l’analyse. On parle de « data lake » mais aussi de « data reservoir », réservoir de données.
Principal inconvénient de ce mode de fonctionnement, les modifications de structure peuvent être complexes, coûteuses en ressources machines et parfois même impossibles à appliquer sans perdre une partie des données. Les choix initiaux de modélisation de la base de données sont donc structurants.
Cela s’applique parfaitement à des données de gestion, financières, pérennes, mais se révèle moins adapté lorsqu’on connaît mal en amont les traitements qui seront appliqués en aval.
Après les infocentres, aussi structurés que les bases opérationnelles, sont apparus les entrepôts de données. Les « data warehouses » ont permis de centraliser toutes les données structurées en silos dans les bases opérationnelles, et de les regrouper dans un même entrepôt.
On a alors appliqué une modélisation en étoile afin de garder le détail de l’information à la granularité la plus faible, et de lui appliquer le plus de dimensions possibles pour maximiser les possibilités d’agrégations et de recherches.
Si l’information la plus détaillée a été conservée, il est ensuite possible de modifier les axes de recherche, les dimensions. Mais bien souvent il est nécessaire, pour des raisons de coût ou tout simplement d’espace de stockage, de faire des choix et lors de la modélisation en étoile, des regroupements sont faits qui aboutissent eux aussi à une forme de structuration de l’information.
Par ailleurs la modélisation en étoile convient bien à des données structurées, relativement prévisibles. Elle est moins adaptée à des données non structurées comme celles issues des réseaux sociaux.
L’apparition des systèmes de stockage arborescents comme Hadoop a ouvert de nouvelles perspectives. Lorsque le besoin est de stocker de gros volumes de données à structures variables, mais surtout dont on ne sait pas à l’avance comment elles vont être utilisées et analysées, apparaît le concept de lac de données.
Schématiquement une bases de données relationnelle, ou un data warehouse, sont des structures verticales. La structuration des hiérarchies, des dimensions, leur donne de la verticalité, de la structure. Ils sont donc ensuite difficile à déconstruire si l’on souhaite en modifier l’organisation. Un peu comme un gratte-ciel, si votre entrepôt de données prend de la hauteur et conserve de plus en plus de données, sa déconstruction devient problématique si vous souhaites changer d’angle d’analyse.
Un lac de données est à l’inverse totalement plat, sans structure. Les données sont conservées sur le même plan. La structure est alors créée au moment de l’analyse. On parle de « data lake » mais aussi de « data reservoir », réservoir de données.
Premières occurrences de la notion de data lake
Une recherche rapide sur notre moteur préféré remonte des occurrences déjà anciennes de l’usage de la notion de « data lake ». En 1999, Dorian Pyle écrit dans « Data Preparation for Data Mining, Volume 1 » : « In truth, corporations have huge data « lakes » that range from comprehensive data stores to data warehouses, data marts, and even data « garbage dumps » ».
Plusieurs entreprises se positionnent aujourd’hui sur ce concept dont DataLakes, éditeur américain d’une solution analytique dédiée au Big Data, mais aussi Pivotal, la filiale de EMC lancée l’an dernier pour regrouper les compétences Big Data du constructeur. Pivotal s’associe avec Capgemini pour promouvoir le concept de « Business Data Lakes ».
Plusieurs entreprises se positionnent aujourd’hui sur ce concept dont DataLakes, éditeur américain d’une solution analytique dédiée au Big Data, mais aussi Pivotal, la filiale de EMC lancée l’an dernier pour regrouper les compétences Big Data du constructeur. Pivotal s’associe avec Capgemini pour promouvoir le concept de « Business Data Lakes ».
Avantages et inconvénients
Cette structure plate des lacs de données convient très bien aux données dont on décide de conserver l’historique sans forcément savoir par avance quelles analyses leur seront appliquées.
En conservant la donnée brute, sans structure, aucun choix préalable ne vient restreindre les possibilités ultérieures d’analyse. Cette notion de lac de données colle parfaitement avec l’architecture Hadoop. Hadoop n’est pas une base de données, mais un système de gestion de fichiers.
Les données y sont stockées sous forme d’une multitude de fichiers distribués. Et c’est lors de la phase d’analyse que les données sont regroupées et qu’une éventuelle structure est créé.
Conserver par exemple les logs d’un site web sur plusieurs années, les tweets mentionnant des sujets, les statuts sociaux, les commentaires de blogues, les photos identifiées... Tout cela sans savoir au préalable comment les données seront croisées dans le futur, voici un bel exemple de « data lake ».
Bien entendu, le revers de la médaille est que la création de la structure à chaque analyse consomme des ressources machines. Le « data lake » n’est donc pas adapté à des analyses répétitives où la structure des données devrait être recalculée à chaque nouvelle étude.
En résumé, le concept de lac de données / data lake, est à recommander pour de gros volumes de données dont on ne connaît pas a priori les structures analytiques. Il est donc complémentaire du « data warehouse » qui reste la structure la mieux adaptée à l’analyse répétitive et comparative des données structurées de l’entreprise.
Et vous, qu’en pensez-vous ? Avez-vous expérimenté cette nouvelle forme de stockage de données ? A quelles applications vous semble-t-elle adaptée ou à déconseiller ?
En conservant la donnée brute, sans structure, aucun choix préalable ne vient restreindre les possibilités ultérieures d’analyse. Cette notion de lac de données colle parfaitement avec l’architecture Hadoop. Hadoop n’est pas une base de données, mais un système de gestion de fichiers.
Les données y sont stockées sous forme d’une multitude de fichiers distribués. Et c’est lors de la phase d’analyse que les données sont regroupées et qu’une éventuelle structure est créé.
Conserver par exemple les logs d’un site web sur plusieurs années, les tweets mentionnant des sujets, les statuts sociaux, les commentaires de blogues, les photos identifiées... Tout cela sans savoir au préalable comment les données seront croisées dans le futur, voici un bel exemple de « data lake ».
Bien entendu, le revers de la médaille est que la création de la structure à chaque analyse consomme des ressources machines. Le « data lake » n’est donc pas adapté à des analyses répétitives où la structure des données devrait être recalculée à chaque nouvelle étude.
En résumé, le concept de lac de données / data lake, est à recommander pour de gros volumes de données dont on ne connaît pas a priori les structures analytiques. Il est donc complémentaire du « data warehouse » qui reste la structure la mieux adaptée à l’analyse répétitive et comparative des données structurées de l’entreprise.
Et vous, qu’en pensez-vous ? Avez-vous expérimenté cette nouvelle forme de stockage de données ? A quelles applications vous semble-t-elle adaptée ou à déconseiller ?