EDITO - Un data lake, oui mais pourquoi ?

La notion de data lake (lacs de données), très liée au Big Data, est récente. La structure et l'utilisation de ces lacs de données sont différentes de celles des bases de données relationnelles, datawarehouses et autres datamarts, outils de business intelligence plus anciens.

Il est communément admis que la notion de lac de données a été initiée par James Dixon, le CTO de la société d'analytique Pentaho, en 2010. La description métaphorique qu'il en fait en comparant data lake et datamart est également assez répandue : « imaginez un datamart comme étant un magasin rempli de bouteilles d'eau, purifiée, emballée et structurée pour en faciliter la consommation. Le data lake est en revanche une vaste étendue d'eau dans un état plus naturel. Le contenu d'un data lake provient en amont d'une source qui remplit le lac et ses divers utilisateurs peuvent venir l'observer, y plonger ou en prélever des échantillons1 ». Autrement dit, là où un datamart place les données dans des fichiers ou des dossiers structurés, un data lake présente une architecture à plat.

Notons que, contrairement à un lac naturel, dans un data lake, toutes les données, qui y sont stockées dans un état brut et quasiment non-transformées, sont issues des divers systèmes sources et qu'aucune donnée n'en sort jamais. Pour être en mesure de retenir toutes ces données, un lac de données s'appuie sur une architecture matérielle de type Big Data, très différente de celles mises en œuvre par la plupart des entrepôts de données (datawarehouse).

À l'inverse d'un entrepôt de données, un lac de données contient toutes sortes de types de données, structurées ou non-structurées, issues de systèmes transactionnels traditionnels mais aussi de sources comme les capteurs qui fleurissent avec l'IoT (Internet of Things), les réseaux sociaux ou encore des images. Et ce n'est que lorsqu'on cherche à les utiliser pour les analyser que ces données sont transformées. Pas avant, contrairement aux entrepôts de données. Les analyses passent par des métadonnées (données décrivant d'autres données) et non pas par des tables, certes structurées mais forcément moins souples.

De ce fait, un lac de données peut être aussi bien exploité par un utilisateur expert en analytique, voire par un data scientist, pour faire des analyses prédictives, par exemple, que par un utilisateur de base, qui ne cherche qu'à connaître les volumes de ses ventes sur la période (et à qui un entrepôt de données traditionnel donnerait sans doute également satisfaction). Les lacs de données favorisent la créativité de leurs utilisateurs.

Présentés ainsi, les avantages et le potentiel d'une approche de type lac de données semblent alléchants. Faut-il pour autant sauter à pieds joints dans ce type d'architecture décisionnelle ? Sans doute pas, surtout si l'on a déjà mis en œuvre une solution de business intelligence basée sur des outils plus traditionnels, comme un datawarehouse et des bases de données relationnelles. Surtout si la solution donne satisfaction. Si en revanche elle montre ses limites et ses travers, pourquoi ne pas envisager d'installer un data lake en parallèle de la solution existante ? Enfin, si vous en êtes aux prémices de l'installation de vos outils décisionnels, il peut valoir le coup d'envisager les deux approches et de les comparer.

Le dossier de recherche du CXP publié dans la présente édition de votre lettre « L'Œil Expert » vous fournira des éléments et des bonnes pratiques si vous envisagez de construire un lac de données.

1 cf. https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/

Commentaires

Publier un nouveau commentaire