Le domaine de la data n’a cessé d’évoluer depuis les années 50. Les différentes ruptures technologiques ont amené les entreprises à faire évoluer leurs besoins afin de conserver leur compétitivité.

Face à la nécessité d’améliorer leurs performances commerciales, il devenait nécessaire pour les entreprises de pouvoir analyser leurs données afin de faciliter et accélérer la prise de décision. On a alors assisté à l’avènement de la Business Intelligence (BI) et du Data Warehouse dans les années 2000, puis au début du Big Data.

 

Le Data Warehouse pour centraliser les données

L’objectif du Data Warehouse est de centraliser les données fragmentées dans de multiples bases grâce aux processus d’ETL.

Le processux ETL du Data Warehouse

Basé sur les moteurs relationnels existants, le Data Warehouse présente de nombreux avantages :

  • La donnée est structurée et son schéma est forcé ;
  • Les relations entre les objets préservés sont garanties, assurant ainsi la consistance de la donnée ;
  • L’accès à la donnée y est simple et performant ;
  • Les utilisateurs disposent d’un seul point d’accès à la donnée.

Les deux premiers avantages cités constituent pourtant les principaux défauts du Data Warehouse : comment ingérer et servir des données semi-struturées (json par exemple) ou non-structurées (images, documents) ?

Le Data Lake (ou « lac de données ») a donc été développé pour exploiter ces données.

 

Le Data Lake pour l’exploitation des données

Depuis le début des années 2010, l’essor des usages d’Internet (smartphones, réseaux sociaux, e-commerce) a amené les entreprises à collecter un large volume de données. L’exploitation de ces données permet de baser les processus de décision sur les faits et d’y appliquer de la data science afin de prédire les comportements (financier, processus, clients, etc.).

Cette forte augmentation du volume et du type de données collectées a nécessité la conception d’un nouveau paradigme : le Data Lake, un stockage distribué de la donnée sous forme de fichier, analysé avec des moteurs dédiés (Hadoop Map Reduce, Spark, Hive).

 

Principaux avantages du Data Lake :

  • La scalabilité : il est facile d’ajouter du stockage ou de la puissance de calcul ;
  • La flexibilité : on peut y mettre tout… absolument tout !

Toutefois, le Data Lake a également contribué à complexifier nos architectures. En raison de ses faibles performances, il est nécessaire de copier les données dans des bases dédiées à l’analytique. Afin d’adresser des usages de data science, il est nécessaire d’y adosser de nombreux outils, et les technologies se multiplient.

Les outils de référence de la Data Science

 

Les inconvénients du Data Lake :

Le Data Lake présente toutefois de nombreux autres défauts :

  • La donnée est dupliquée ;
  • Il n’est pas possible d’assurer des contraintes d’intégrité ;
  • Les schémas de données évoluent sans cesse ;
  • Au fil du temps, garder un Data Lake structuré et cohérent devient compliqué.

L’objectif est désormais de simplifier cela et d’introduire un nouveau paradigme alliant le meilleur du Data Warehouse et du Data Lake. Avec le Lakehouse, Databricks est un des premiers à apporter une véritable solution à ces problématiques.

 

Lakehouse : le meilleur du Data Warehouse et du Data Lake

Le Data Warehouse et le Data Lake répondent ensemble à de nombreux usages mais au prix d’architectures à la complexité élevée, impliquant le maintien de plusieurs structures de données et outils, et nécessitant de posséder des compétences sur plusieurs technologies.

Ne serait-il pas possible d’allier l’ensemble de ces besoins autour d’un seul outil ? C’est là qu’intervient le Lakehouse qui vise à combiner le meilleur du Data Warehouse et le meilleur du Data Lake.

Databricks a choisi de répondre à cette problématique en s’appuyant sur Apache Spark et Delta Lake.

 

Qu’est-ce que le Lakehouse ?

Le Lakehouse consiste à réunir, sous une seule architecture, le Data Warehouse et le Data Lake. Basé sur le Data Lake, son objectif est d’adresser avec un seul outil l’ensemble des use cases data : Streaming, BI, Machine Learning.

Schéma simplifié du Lakehouse

Le premier facteur de succès d’une telle approche est d’être capable d’apporter au Data Lake les avantages du Data Warehouse. C’est là qu’intervient Delta Lake.

 

Delta Lake : gestion de la consistance des données

Présenté par Donatien Tessier dans un précédent article, Delta Lake est une couche de stockage s’appuyant sur les systèmes HDFS existants et Parquet pour le format de fichier. L’objectif de Delta Lake est d’ajouter tous les manquements que l’on connait au Data Lake, et qui sont les forces du Data Warehouse :

  • Les transactions ;
  • Des schémas forcés mais évolutifs ;
  • L’historisation de la donnée grâce aux journaux de transactions ;
  • Le support des opérations de mise à jour incrémentale (Delete / Update / Merge).

Grâce à Delta Lake, nous disposons désormais d’une couche de stockage qui nous garantit la consistance de notre donnée mais ne règle pas la problématique de la performance d’accès à la donnée.

Databricks répond à cette problématique grâce à un nouveau moteur d’exécution adossé à Spark 3.0 : Photon.

 

Delta Engine / Photon

Dans le monde de la BI, l’un des modèles de données les plus répandus est le modèle en étoile. La problématique de ce modèle associé à Data Lake est le temps de calcul des tables de dimensions.

Spark 3.0 a apporté une première réponse à cette question de la performance avec le Delta Engine.

 

Les composants de Delta Engine

Le Delta Engine est le moteur de Spark. Il comporte trois composants :

  • L’optimiseur de requêtes dont l’objectif, tout comme en SQL, est d’optimiser la requête à effectuer (calcul des données à charger, suppression d’instructions non-nécessaire, etc.) ;
  • Le moteur d’exécution qui effectue le traitement ;
  • Un système de cache afin de réduire les I/O et d’augmenter les performances d’accès à la donnée.

Sur nos différents projets nous avons pu voir des améliorations significatives des performances en migrant vers Databricks 7.0 et Spark 3. Mais est-ce suffisant pour adresser les usages Data Warehouse ?

La réponse de Databricks à ce sujet est claire : non, ce n’est pas suffisant.

 

Comment répondre aux exigences de performances des projets Data Science ?

En ajoutant Photon au moteur d’exécution du Delta Engine : ce nouveau moteur entièrement réécrit en C++ est optimisé pour tirer le meilleur des capacités des CPUs récents et des architectures cloud.

 

Schéma simplifié de Delta Engine

Photon est actuellement en private preview sur Azure Databricks, mais les premiers benchmarks de Microsoft montrent d’ores et déjà les avancées effectuées.

Ainsi, en répondant aux problématiques de la consistance de la donnée avec Delta Lake et des performances avec Photon, Databricks apporte au Data Lake les avantages du Data Warehouse, optimise les usages ETL et Data Science là où le produit était déjà efficace et complète sa vision du Lakehouse.

Optimisation de la Data Science avec Delta Lake

 

Des outils de Data Science plus appropriés et simples

Le Lakehouse est la réponse pour unifier nos architectures data, en réduisant le nombre d’outils nécessaires pour adresser la BI, les usages Data Lake, et enfin la charge d’exploitation de ces plateformes (sécurité, réseau, etc.).

Grâce à Delta Lake et Photon, Databricks propose actuellement l’offre la plus mature sur le Lakehouse. Mais il n’est pas le seul acteur du marché à aller vers cette architecture unifiée. Pour ne citer qu’Azure, Microsoft avance ses pions avec Azure Synapse mais prend la philosophie dans l’autre sens : ils vont du Data Warehouse (en s’appuyant sur SQL Data Warehouse) vers le Data Lake, en y incluant les clusters sparks. Toutefois, l’offre Synapse reste encore faible sur la partie data science et nécessite d’acquérir a minima les compétences SQL et Spark, là où Databricks s’appuie exclusivement sur Spark.

Quoi qu’il en soit, nous ne pouvons qu’apprécier cette simplification en cours. Gageons que dans les années à venir le paradigme du Lakehouse s’améliorera vers toujours plus de simplicité et de performance.

 

✍️ Cet article a été co-rédigé par : Matthieu Klotz (Cellenza) et Seifeddine Saafi (Databricks).