Le monde des Big Data s’apparente à un parcours de montagnes russes. Les distributions Hadoop sont devenues de plus en plus complexes au fil des années : à l’heure actuelle, l’écosystème Hadoop présente une maturité et un nombre de projets de nature à couvrir les besoins d’un éventail complet de cas d’usage. Cependant, selon les prévisions de Gartner, les distributions Hadoop n’atteindront pas le plateau de productivité.

Dans le même temps, de nouvelles offres proposées par les principaux prestataires cloud mêlent les concepts de SaaS et de Big Data. A titre d’exemple, les frontières s’estompent entre HDFS, Amazon S3 et le stockage en lac de données Azure. La nouvelle génération d’architectures de traitement massivement parallèle (MPP) dans le cloud, telles que Snowflake ou Redshift, est pratiquement impossible à distinguer des systèmes SQL-on-Hadoop comme Spark ou Presto (pensez à Qubole ou Databricks, pour ne citer que quelques exemples). Nous vivons clairement une époque intéressante en ce qui concerne la gestion de données.

Toutefois, dans ce monde en constante évolution, un concept en particulier se trouve au cœur de la plupart des discussions : le data lake (ou lac de données). Il s’agit d’un endroit regroupant toutes les données, doté d’une capacité de stockage quasi infinie et d’une puissance massive de traitement. Pourtant, en dépit de leurs avantages manifestes, les data lakes font l’objet de nombreuses critiques.

Les principaux obstacles associés aux lacs de données peuvent cependant être surmontés grâce à la virtualisation des données. De fait, la virtualisation a de nombreux points communs avec les lacs de données, car les deux architectures partent du principe de mettre toutes les données à la disposition de l’utilisateur final. Dans chacune d’entre elles, l’accès élargi à de grandes quantités de données est mis au service du décisionnel (BI, Business Intelligence), de l’analytique et d’autres nouvelles tendances telles que le Machine Learning (ML) et l’intelligence artificielle (IA).

Le lac de données logique (terme inventé par Mark Beyer du Gartner)  est une approche mixte, associant un lac de données physique à une couche virtuelle qui lui est superposée, ce qui offre de multiples avantages.

  1. Charger d’abord, demander ensuite ?

Alors qu’une gouvernance de bonne qualité est indispensable pour qu’un lac de données soit exploitable, un tel principe peut facilement conduire à une absence de gouvernance, avec de multiples copies incontrôlées des mêmes données, des versions obsolètes et des tables inutilisées. En outre, en raison des restrictions et des législations locales applicables aux données, toutes ne peuvent pas être reproduites dans le lac.

Dans une architecture logique, les données ne sont pas nécessairement persistantes mais connectées. Cela signifie que l’accès à la plupart d’entre elles n’exige aucun investissement initial pour leur importation dans le lac de données logique.

  • La couche de virtualisation des données permet d’accéder à celles-ci dans leur lieu d’origine, rendant inutile l’existence de copies multiples des mêmes données.
  • Dans les cas où un accès direct à la source n’est pas optimal pour des raisons de performances, des technologies de virtualisation des données peuvent faciliter leur chargement dans le lac physique, rendant la transition totalement transparente.
  • Il est possible d’adopter une approche similaire pour atteindre un niveau supérieur de nettoyage et de transformations. Si nécessaire, les données peuvent être facilement rendues persistantes.
  1. Quelles données brutes pour le data lake ?

C’est généralement une erreur que de commencer par créer un lac de données puis de définir les pipelines devant alimenter celui-ci, avant de déterminer les résultats et bénéfices attendus. Mieux vaut tout d’abord se demander quelles données doivent aller dans le lac, dans quel but et avec quel niveau de granularité.

Dans un système logique, les données brutes peuvent demeurer à leur source et seules celles qui sont utiles doivent être importées. Ces données peuvent être organisées, transformées, agrégées et combinées au sein du modèle logique, de sorte que les seuls éléments nécessaires deviennent en définitive persistants dans le lac de données.

  1. Complexité et compétences ?

La gestion d’un cluster Hadoop sur site ou l’optimisation d’un système dans le cloud sont des tâches complexes. Lorsque celles-ci se retrouvent confiées à des utilisateurs non techniciens qui se sont vus promettre une puissance hors pair et une capacité de stockage infinie, c’est le désastre assuré. Or l’acquisition des compétences adéquates pour exploiter le cluster avec succès est difficile et coûteuse. Dans bien des cas, les data lakes ne sont utilisés que par des data scientists, ce qui amoindrit leur potentiel.

Avec une couche virtuelle, les utilisateurs métiers n’ont pas besoin d’interagir directement avec le système back-end.

  • La couche virtuelle offre un moteur SQL plus simple d’utilisation, qui fait abstraction des complexités du back-end pour les opérations de lecture, les chargements de données et le traitement des requêtes complexes.
  • En outre, un catalogue convivial facilite l’accès au modèle des données, à leur origine, à leurs descriptions et à leur aperçu.
  • Les demandes faites au service informatique sont moins nombreuses et l’utilisation du lac de données s’élargit à un public non technicien plus vaste.

Un data lake logique peut raccourcir les cycles de développement et réduire les coûts opérationnels en comparaison d’un data lake physique traditionnel. Il contribue également à développer l’adoption du data lake et à accroître son retour sur investissement.

___________
Olivier Tijou est Directeur Général de Denodo France, Belux et Suisse francophone