Arguments sur la création d'un "Data Lake"

**bstevy** · 28/04/2015, 07h42

Bonjour à tous,

Je suis à la recherche d'argument pour savoir si l'IT de ma boite va dans la bonne direction ou s'apprête à se planter dans le mur le plus proche.

Voici la situation quelque peu étrange dans laquelle je suis.

1- Je suis membre de l'équipe DWH. Et vous savez quoi ? Nous n'avons pas de DWH. Ça veut pas dire que je fais rien, ça veut juste dire que je m'occupe en fait de faire des extractions sur la base opérationnelles pour les métiers plutôt que de m'occuper de maintenir un dwh sur lesquels les métiers pourraient faire toutes les extractions qu'ils voudraient...
Je trouve ça un peu curieux comme façon de faire, qu'est-ce que vous en pensez ?

2- Nos voisins coréens viennent de commencer (ou peut être finir, je n’ai pas tellement suivi) un projet de data Lake. Et donc notre direction a décidé qu'on devrait nous aussi en faire un.
Est-ce que vous pensez que c'est une bonne raison ? Est-ce que le fait qu'il n'y ait pas de dwh ne devrait pas justement constituer notre priorité, ou le data Lake peut se permettre de le remplacer ?

Je me retrouve un peu entre le marteau et l'enclume, et autour de moi, j'ai des managers qui me disent des choses aussi absurde que "mais vas-y, construit un DWH. Il te faut quoi ? Des hommes, de l'argent ? Tu peux nous faire ça en combien de temps ?" genre, les mecs ils ne savent même pas ce que c'est.

Si vous pouviez me donner votre avis sur le point 1 ou le point 2, ça pourrait m'être utile.

Merci d'avance.

Steven

**Elros** · 28/04/2015, 13h21

Bonjour,

Pour ton point 1, il m'est arrivé de travailler pour différents clients fonctionnant de cette façon. Je pense que s'il travail de cette méthode c'est par méconnaissance de ce que peut leur apporter un DWH. Il y'a certainement une histoire de budget et de ROI.
Lorsque de tu répètes toujours les mêmes extractions et que tu commences à allouer une équipe pour faire ce genre de tâche car les besoins des utilisateurs évoluent et que tu as du mal à suivre le rythme de leur demande, tu dois commencer à réfléchir à ce que tu peux faire pour améliorer la vie quotidienne des utilisateurs. Et l'entrepôt de données et/ou magasins de données et/ou cube analytique doivent arriver comme proposition de solution.

Pour ton point 2, un data lake ressemble fortement au principe du Big Data, ce qui est différent (pas toujours adapté à une entreprise) d'un projet DWH. L'intérêt d'un data lake est que sa structure est évolutive part rapport à celle d'un DWH car on stock un maximum d'information brute sans les lier comme on le ferait dans un modèle de données classique.

Un article très intéressant à lire : http://www.decideo.fr/Le-concept-de-...xte_a6976.html

Elros

**bstevy** · 28/04/2015, 13h29

Merci pour cette réponse et pour l'article.

Ok, donc c'est bien ce que j'avais cru comprendre à la base, un datalake, c'est pas un super dwh...

Il faut que je creuse la question mais je pense qu'ils n'ont pas le besoin d'un datalake, et qu'un simple dwh bien fait suffirait largement.

**bstevy** · 01/05/2015, 10h36

@Elros
Je reviens un peu sur le sujet car les discussions ont un peu évolué dans mon entreprise avec l'arrivée notament du chef de projet datalake ^^ donc j'ai besoin d'autres infos.

J'ai un peu du mal à saisir la finalité du datalake en fait.

Pour moi qui ai toujours travaillé sur les dwh, j'ai cette image un peu rapide du : le dwh est créé par l'info (avec l'aide des métiers bien sur) et les utilisateurs sont les métiers qui, via des outils type BO, peuvent faire toutes les analyses dont ils ont besoin.

Mais quand je lis des choses sur les data lake, j'ai déjà beaucoup plus l'impression de me retrouver dans une section R&D, je me trompe ?
Les interfaces ne me semblent absolument pas adaptées aux utilisateurs métier, et chaque "analyse" va demander une collaboration entre l'it et les métiers (en plus de tout ce qui est maintenance) pour être mise en place et en même temps un sacré temps de calcule.
De ce fait, je vois deux finalités : l'une, c'est le stockage... (mais bon, sans but précis, c'est un peu de la perte de temps je trouve - c'est pour occuper les équipes qui n'ont rien à faire ou dépenser un reste trop important de budget) et l'autre, c'est l'exploration de données, où là, effectivement, on peut trouver des choses intéressantes, mais le RIO est difficilement prévisible.

Je suis dans la bonne direction, où y'a des choses qui m'échappent ?
Hésitez pas à commenter ce que j'ai dit, si vous aussi vous partagez ces idées ou si vous voyez les choses autrement.

**Elros** · 01/05/2015, 16h46

L'intérêt du data lake est d'avoir accès à toutes les données qui touchent une entreprise à "un seul endroit" (en réalité les données sont généralement stockées sur plusieurs serveurs) et sans structure. Le fait qu'il n'y ait pas de structure te permet de croiser n'importe qu'elle données entres elles. Attention tout de même, on ne peut pas croiser toutes les données entre elles. C'est là que généralement le data scientist arrive. Son rôle est de faire parler les données et le lac de données lui permet de faire toutes les analyses dont il rêve !
Par exemple, au début de twitter on aurait pas eu l'idée d'analyser les tweets. Et pourtant aujourd'hui, cela devient courant pour connaitre les avis des utilisateurs par rapport à une marque, un candidat aux élections. Pour les élections présidentielles de 2012, Obama a réussit à exploiter les technologies du Big Data pour mieux cibler les électeurs.

La mise en place est pas toujours évidente, plus ardu à mettre en place qu'un entrepôt de données.
L'accès au lac de données n'était pas très user friendly au début, mais aujourd'hui on a des outils comme Kibana "Elastic search", Tableau Software, Qlikview, SAS, etc. (la liste est longue).

En effet si on possède un lac de données et qu'il reste simplement d'un endroit de stockage, il n'y aucun intérêt ! Cependant, avec des personnes tels qu'un data analyst et/ou data scientist il y'a un réel intérêt. Toutefois, je pense toujours que toute les entreprises n'ont pas forcement besoin d'investir dans ce genre de projet.

Il serait intéressant q'un data scientist vienne échanger avec nous. :-)

Elros