Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo

 


Le concept de « data lake » - lac de données : explication de texte


Rédigé par le 22 Avril 2014

Depuis quelques mois, on voit apparaître dans des articles et des présentations le terme de « lac de données », le plus souvent sous l’appellation en anglais de « data lake ». Nos données ne seraient donc plus aujourd'hui stockées dans des « entrepôts » mais sous forme de lacs. A-t-on progressé ou est-ce un nouveau concept marketing qui disparaîtra aussi vite qu’il est apparu ?



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.

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 ».

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 ?




Commentaires

1.Posté par Claude-Henri MELEDO / ALDECIS le 23/04/2014 11:35
Les questions sont éternelles. Les réponses portent parfois de nouveaux noms (de par l'utilisation d'une nouvelle génération de technologie), mais sont rarement innovantes sur la méthode.

Effectivement au Hadoop Summit 2014, il n'était question que de "Data Lake" !

Le "Data Lake" répond à la même problématique de stockage avant structuration analytique (quand cela devient un "Data Warehouse" généraliste ou un "Data Mart" thématique)... Tout comme le faisait le vieux concept de l' "ODS / Operating Data Store" ; sauf que maintenant on s'intéresse en plus aux données non structurées et semi-structurées.

L'ODS qui stockait les données sans chercher vraiment à les structurer, arrivait donc en amont du Data Warehouse. On pouvait également lui faire reprendre le très vieux rôle du concept précédent qu'on appelait auparavant "Infocentre", dans le sens où en plus d'être la base préparatoire du Data Warehouse, il pouvait permettre de faire du reporting opérationnel à la maille la plus fine (sur des informations certes structurées, mais sans chercher à conserver des historiques comparables) http://en.wikipedia.org/wiki/Operational_data_store

La question sera donc de savoir si on conserve le niveau intermédiaire de l'ODS, situé entre le "Data Lake" et le "Data Warehouse". Mon opinion est que dans la mesure où les ETL / EAI ont certaines faiblesses structurelles, il est fort à penser que l'ODS aura toujours besoin d'exister.
http://datatechblog.com/2014/02/mda-datalake/

2.Posté par Francois Nguyen le 23/04/2014 20:37
J'aime assez l'image de Data Lake : cela me permet d'expliquer derrière qu'il faudra une usine de retraitement de l'eau (car pas toujours potable) et beaucoup de tuyauterie pour qu'un utilisateur puisse accéder à la donnée aussi facilement qu'en tournant un robinet. Bref, qu'un cluster Hadoop, c'est bien mais... pas suffisant.

3.Posté par F le 04/11/2015 20:56
A quand un data sea puis un data ocean ?

4.Posté par Philippe NIEUWBOURG le 04/11/2015 21:06
C'est une excellente idée ! Et si ce n'est déjà fait, je suis certain que vous aurez raison dans quelques mois.

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store