Nous suivre
Le monde du Data Lakehousing est relativement récent. Pour l'aborder sereinement, il est utile de faire un petit bond en arrière.
Tout a commencé avec le Data Warehouse, qui permettait l'analyse de données. Les volumétries étaient connues et maîtrisées, avec des architectures principalement "maison". On parle souvent de solutions "on-premise" : SQL Server, PostgreSQL, Oracle, installés sur des serveurs "locaux". Ces systèmes étaient optimisés pour des requêtes analytiques complexes sur des données structurées.
Puis, les entreprises ont commencé à produire de plus en plus de données, de types et de formats variés. Ne sachant pas encore ce qu'elles voulaient faire de toutes ces données, elles ont commencé à les stocker. C'est la naissance du Data Lake, propulsé directement comme la star du moment. Le Data Lake permettait de stocker des données brutes, structurées ou non, à grande échelle et à moindre coût.
Cependant, peu se doutaient du bourbier dans lequel ils s'embarquaient en s'y jetant pieds et poings liés. Les Data Lakes, bien que flexibles et économiques, ont rapidement posé des problèmes de gouvernance, de qualité des données et d'accessibilité pour les utilisateurs métier.
Malgré ces défis, les Data Lakes sont venus pallier certaines faiblesses du Data Warehousing traditionnel :
Ces avantages ont jeté les bases des évolutions que nous voyons aujourd'hui.
Pour bien comprendre ce qu'est un Lakehouse et comment il révolutionne notre manière de penser, il est crucial de bien saisir les concepts de Data Warehouse et de Data Lake, comment chacun résout une problématique différente, et pourquoi une nouvelle approche était nécessaire.
Le Lakehouse vient combiner le meilleur des deux mondes : la flexibilité et l'évolutivité du Data Lake avec la structure, la gouvernance et les performances du Data Warehouse. Cette approche permet de gérer efficacement les données à grande échelle tout en fournissant des capacités analytiques avancées, le tout dans un environnement unifié.
Un Data Warehouse (entrepôt de données) est un système centralisé conçu pour stocker, gérer et analyser de grandes quantités de données structurées provenant de diverses sources. Il est optimisé pour les requêtes analytiques complexes et la prise de décision basée sur les données.
Les Data Warehouses traditionnels adhèrent aux principes ACID, qui garantissent l'intégrité et la fiabilité des données :
Il va venir résoudre le problème du Data Warehousing mais en sacrifiant l’acidité;
Un Data Lake est un vaste répertoire de stockage qui contient une grande quantité de données brutes dans leur format natif, qu'elles soient structurées, semi-structurées ou non structurées. Il est conçu pour stocker, traiter et sécuriser de grands volumes de données, et les rendre disponibles pour diverses tâches analytiques.
Les Data Lakes privilégient généralement la disponibilité et la tolérance au partitionnement (AP) au détriment de la cohérence stricte. Cela signifie qu'ils peuvent :
Mais pour être plus spécifique, Les premiers Data Lakes sont tout simplement des data stores (NOSQL), ils étaient distribués et gérés par HDFS . Les plus récents & plus connus aujourd’hui sont des réplicas adaptés par & pour les cloud providers. Pour AWS , S3 avec EMRFS ou encore pour Azure, Azure Storage containers ( ABFS ) en activant la fameuse hierarchical namespace.
Mais la principale faiblesse est que les Data Lakes se sont vite transformés en « data swamp » ( littéralement en français, “marécage de donnée” ) car énormément de données étaient entreposés un peu partout sauf qu’on ne savait rien de ce qu’il y avait à l’intérieur il n’y avait qu’un tas de fichiers plats / structurés ou non qui étaient entreposés. Et avec ça BON COURAGE pour vos projets DATA !!
Quel intérêt d’avoir de la donnée si personne ne sait quoi utiliser ? ( petite pensée à tous ces Data Eng.Scientists qui ont passés des heures à déterrer de la data à droite à gauche)
( gardez cet exemple en tête car juste après on fera la même pour Lakehouse )
Souvent on avait une architecture lambda (terme important). D’un côté le speed layer avec du streaming pour avoir du temps réel. De l’autre des jobs en Batch plus traditionnels pour les processus qui prennent plus de temps avec plus grosse volumétries, jobs plus lourds et - urgents.
Mais cela soulevait plusieurs problèmes.
- Il fallait découpler les deux couches : double complexité
- Doublons des données ou potentiels conflits
Cela pouvait donner quelque chose comme : pour un simple insert.
Data cataloging : ( Mais ce dernier mériterait plusieurs articles rien que pour lui )
Une des solutions pour remonter la pente a été de créer des catalogues:
- Unification des métadonnées : Le catalogue joue un rôle crucial en unifiant les métadonnées des données brutes du lac et des données structurées du warehouse au sein du Lakehouse.
- Gouvernance des données : Il facilite la mise en place de politiques de gouvernance cohérentes sur l'ensemble du Data Lake.
- Découverte des données : Il permet aux utilisateurs de trouver et comprendre les données disponibles, qu'elles soient structurées ou non.
Bon maintenant que nous avons enfin décrassé ou mieux compris ces concepts. Gardons les en tête pour le Data Lakehousing .
Souvent référencé comme Delta lake car databricks était le précurseur dans le domaine et c’est le nom qu’elle a donné à l'architecture DELTA” et par la même occasion à son produit de Lake housing phare : “Delta lake”.
C’est un concept très récent. Et pour la plupart d’entre vous je pense vous l’aurez compris, de par son nom, un mix entre Data Lake et Data Warehouse. L’idée est de mixer le meilleur des deux mondes. J’arrête le teaser ici.
« Le Lakehouse étend le concept de Data Lake à l’ensemble des types de traitements (IA et machine learning, BI, analytique, etc.) des modèles de données et des techniques analytiques tout en conservant les garanties ACID apportées historiquement par un Datawarehouse. »
Vous me direz peut-être; on t’arrête tout de suite, les "Cloud Data Warehouses" de type snowflake ou bigquery basés sur du MPP, peuvent le faire facilement ! Alors oui, c’est complètement vrai mais allez payer quelques sous et ensuite on en reparle. C’est selon le projet, la complexité et le budget alloué.
Différentes options pour différents cas ! Tous les clients n’ont pas un chat code « infinite cash shurn/burn » !
Bref, le monde du Data Lakehousing a été lancé dans un papier de recherche au tout début par databricks. Le concept s’est ensuite vite répandu et plusieurs solutions existent aujourd’hui sur le marché. Open source pour la plupart donc vous pouvez l'utiliser comme vous voulez où vous voulez. La plupart des Lakehouses intègrent leur propre catalogue intégré et renforcent les bonnes pratiques de gouvernance données.
L'architecture Delta des Lakehouses offre une approche unifiée du traitement des données, combinant les avantages des Data Lakes et des Data Warehouses. Ses principaux atouts sont :
Vous vous rappelez du cas plus haut? Adieux le « append-only », maintenant on parle de delta, un changement peut être un append, delete, update.
Prenons l'exemple d'une simple insertion de données :
Les principaux challengers sont :
Leur architecture pour gérer les metadata diffère mais c’est globalement le même concept. Ça permet de réaliser ce qu’on a énuméré plus haut.
Comparatif de ces formats :
Comme vous pouvez le voir, chacun a une fonctionnalité propre et si on devait détailler, cela mériterait son propre (ou sa série) d'article.
Dans le code :
Via Spark, c'est un simple :
python
‘’’
spark.read.format('delta').load(path_to_table)
spark.read.format('iceberg').load(path_to_table)
spark.read.format(‘hudi').load(path_to_table)
‘’’’
Pour lire et pour écrire, c'est quasiment pareil.
Via Trino (Athena ou autre), c'est simplement :
SELECT * FROM table;
Avec des sémantique cas similaire pour les 3 : on peut faire du time travel de la sorte :
SELECT * FROM table VERSION AS OF 1234
SELECT * FROM table TIMESTAMP AS OF '2023-01-01 12:00:00’
Et bien d’autres….
Le Lakehousing représente une avancée majeure dans le monde de la donnée. Il permet de régler les limites connues des deux architectures pré-existantes du Data Warehouse et Data Lake.
Il prend une part grandissante dans l’écosystème de la data car elle transforme fondamentalement notre approche autour de la gestion de données. De plus en plus d’équipes optent pour ce format qui est scalable et résilient, deux termes à la mode aujourd’hui.
L’émergence des outils open source tels que Iceberg, Delta Lake ou Hudi et leur communauté grandissante démontrent que ce n’est pas juste une mode tech. Mais bien les fondements d’un nouveau futur DATA.
Article par B.ERRAJI, consultant OSSIA.
