Le big data et la notion de datalake nouvelle génération

La notion de datalake se démocratise mais c'est quoi un datalake temps réel ou réactif ? Le point.

La notion de datalake est de plus en plus à la mode et commence à arriver dans nos systèmes d’information (SI). Nous sommes forcés de constater que ce nouveau concept ressemble à des choses que l’on a déjà connues (datawarehouse, infocentre, datamart…).

Alors en quoi est-ce si différent ?

Le datalake dans sa définition première représente cette zone où l’on déverserait toute ses données internes ou externes afin d’en extraire cette quintessence que tout chef d’entreprise espère… Le Graal de l’exploration de la donnée en somme.

Ce nouveau paradigme de datalake est né du fait que l’on peut avoir une approche différente de celle des entrepôts de données (datawarehouse) qui étaient lourds à mettre en place et surtout très rigides.

En effet , tout le monde a été confronté, au fait, que l’alimentation, la modélisation, la restitution dans son datawarehouse donnent le vertige quand les utilisateurs demandent une nouvel indicateur.

La modélisation multidimensionnelle et l’alimentation des tables d’agrégats sont un cauchemar en termes de délai de mise à disposition. De plus, l’utilisateur devra exprimer son besoin de façon très précise afin d’optimiser l’axe d’analyse voulu car sinon les temps de requêtage seront trop long.

La frustration sera d’autant plus grande que si une nouvelle demande survient, il devra repasser par toute la chaîne (conception, modélisation, alimentation, restitution...)

C’est là que le dig data et la notion de datalake intervient. Les technologies telles que Hadoop et Impala (Cloudera) permettent de donner une respiration à votre SI.

On peut utiliser la capacité des composants Hadoop et du monde NoSQL pour réaliser un datalake réactif. On peut maintenant avec ce type de technologie alimenter notre entrepôt de données en temps réel avec un mode message. Kafka est une des briques du monde Hadoop (développée par LinkedIn) qui fonctionne comme un broker de message et qui permet de déverser une quantité de données très importante dans notre datalake. Les systèmes sources s’abonnent à des Topics (File d’attente) et déposent leurs données.

Ensuite , et en temps réel, on utilise Spark Streaming afin de dépiler les files d’attente et stocker les données dans le datalake

Le stockage dans le système Hadoop peut être de plusieurs natures. Si le temps réel avec des milliers d’utilisateurs sont la cible de votre application, on utilisera alors le stockage dans Hbase (base en mode colonne). Si au contraire, vous voulez avoir un datawarehouse ouvert avec une réactivité importante sur de très forts volumes, vous utiliserez Impala. Vos utilisateurs n’auront plus besoin de vous spécifier leurs besoins, ils exploreront les données sans contrainte, du fait de la vélocité de la plateforme Hadoop.

Ainsi la notion de datalake permet de stocker les données au même endroit pour des usages différents. C’est une révolution pour les utilisateurs, on active telle ou telle brique du datalake afin de résoudre telle ou telle problématique.

Néanmoins, tout n’est pas tout rose, le datalake réactif va profondément modifier la vie du SI, car les systèmes sources devront se mettre au diapason pour répercuter chaque modification en temps réel et l’envoyer au broker de messages.

Tout le monde n’aura pas forcément besoin d’une réactivité de son SI à la seconde, mais en tant que directeur informatique il faut se projeter sur une vision à 3 ans, à 5 ans. Quels seront les challenges de demain pour l’entreprise ?

Mais ce qui est certain c’est que le batch 2.0 est né avec cette notion de datalake réactif qui se démocratise. On peut maintenant espérer que les informations actualisées ne soient plus à J+1 mais on pourra dans un avenir proche, espérer une fraicheur de quelques minutes, voire de quelques secondes.

Les technologies big data comme Hadoop (HDFS, Kafka, Spark, Impala, SolR) vont offrir au SI la respiration dont il a besoin pour les exigences de demain.