Qu’est-ce que Delta Lake ?

Développé par Databricks en 2016, Delta Lake est un format de table ouvert, un cadre open source pour les données tabulaires qui crée une couche de métadonnées par-dessus les formats de fichiers existants. Delta Lake utilise spécifiquement les tables Parquet pour le stockage des données. Parmi les autres formats de table ouverts, citons Apache Iceberg et Apache Hudi.

La couche de métadonnées permet à Delta Lake et à d’autres tables ouvertes d’optimiser les requêtes de recherche et de prendre en charge des opérations de données avancées, dont la prise en charge est impossible pour de nombreux formats de table standard. Les organisations utilisent souvent Delta Lake pour rendre leurs data lakes plus fiables et plus intuitifs.

La création de Delta Lake a constitué une étape critique dans le développement de l’architecture de data lakehouse, qui allie le stockage d’un data lake à la performance d’un entrepôt de données.

Delta Lake et les data lakes sont souvent abordés ensemble, mais il est important de comprendre la distinction entre ces deux technologies.

Un data lake est un environnement de stockage de données à faible coût conçu pour gérer des jeux de données massifs de tous types et formats. La plupart des data lakes utilisent des plateformes de stockage d’objets dans le cloud comme Amazon Simple Storage Service (S3), Microsoft Azure Blob Storage ou IBM Cloud Object Storage.

Delta Lake est un format de stockage de données tabulaires qu’une organisation peut utiliser dans un data lake ou un autre magasin de données.

Delta Lake n’est pas un type de data lake ni une alternative à un data lake. On peut considérer le data lake comme le « où » et Delta Lake comme le « comment » :

• Où sont stockées les données ? Dans un data lake.
• Comment les données sont-elles stockées ? Sous forme de table Delta Lake.

Le format Delta Lake peut faciliter la gestion des data lakes et en améliorer l’efficacité.

Les data lakes présentent de nombreux avantages, mais ils n’intègrent généralement pas de contrôles de qualité des données, et il peut être difficile de les interroger directement. Les organisations doivent souvent extraire les données du data lake, les nettoyer et les charger dans des entrepôts de données et des datamarts séparés avant de pouvoir les utiliser.

En introduisant une couche de métadonnées, Delta Lake donne aux organisations un moyen d’appliquer des schémas, de suivre et d’annuler les modifications, et de prendre en charge les transactions ACID.

Les utilisateurs peuvent exécuter des requêtes en langage de requête structuré (SQL), des workloads d’analyse et d’autres activités directement sur le data lake, rationalisant ainsi la business intelligence (BI), l’intelligence des données (DI), l’intelligence artificielle (IA) et le machine learning (ML).

Delta Lake intègre deux composants principaux : les fichiers de données qui contiennent les données, et le journal des transactions qui contient les métadonnées de ces fichiers.

• Les fichiers de données Delta Lake sont appelés « tables Delta Lake » ou « tables Delta » et ils utilisent le format de fichier Parquet en colonnes.
  
  
• Le journal des transactions stocke l’activité récente dans des fichiers journaux JSON et archive les métadonnées plus anciennes dans des fichiers Parquet. Le journal est stocké dans le data lake avec les fichiers de données.

Le journal des transactions enregistre des informations sur les fichiers de données (telles que les noms de colonne et les valeurs minimales et maximales) et les modifications apportées à ces fichiers (ce qui a été modifié, quand, comment et par qui).

C’est ce journal qui différencie Delta Lake d’un fichier Parquet standard. Le journal des transactions agit essentiellement comme une couche de gestion et un ensemble d’instructions pour toutes les activités effectuées dans le data lake, permettant l’utilisation de fonctionnalités telles que les transactions ACID, le voyage dans le temps et l’évolution des schémas.

Les fichiers Parquet ordinaires sont immuables, ce qui signifie qu’ils ne peuvent pas être modifiés après leur création : ils ne peuvent être que réécrits. Le journal des transactions Delta Lake rend les fichiers Parquet fonctionnellement, voire littéralement, modifiables en séparant les actions physiques (actions effectuées directement sur les données) des actions logiques (actions effectuées sur les métadonnées).

Par exemple, un utilisateur ne peut pas supprimer une seule colonne d’une table Parquet sans réécrire l’ensemble du fichier. Avec le format Delta Lake, l’utilisateur peut supprimer cette colonne en modifiant les métadonnées de la table pour marquer cette colonne comme supprimée. La colonne reste dans le fichier, mais toutes les requêtes, mises à jour et écritures ultérieures voient ces métadonnées et traitent la colonne comme inexistante.  

Les propriétés désignées par l’acronyme « ACID » sont l’atomicité, la cohérence, l’isolation et la durabilité : les propriétés clés d’une transaction de données fiable.

• Atomicité : toutes les modifications apportées aux données sont effectuées en une seule opération.
• Cohérence : les données sont dans un état cohérent au début et à la fin d’une transaction.
  
  
• Isolation : l’état intermédiaire de la transaction est invisible pour les autres transactions.
• Durabilité : les modifications apportées aux données persistent et ne sont pas annulées.

Les data lakes standard ne peuvent pas prendre en charge les transactions ACID. Sans garanties ACID, les data lakes sont sujets à des phénomènes d’échec des transactions, d’écritures partielles et à d’autres problèmes susceptibles de corrompre les données. 

Le journal des transactions Delta Lake peut enregistrer les informations relatives aux transactions conformément aux principes ACID, rendant les data lakes plus fiables pour les pipelines de données en streaming, la business intelligence, l’analytique et d’autres cas d’utilisation. 

Les administrateurs peuvent définir des exigences en matière de schémas dans le journal des transactions, exigences qui s’appliquent à toutes les données au moment de leur ingestion. Les données qui ne répondent pas à ces exigences sont rejetées.

Les administrateurs peuvent également utiliser le journal des transactions pour modifier le schéma d’un fichier existant, par exemple en ajoutant de nouvelles colonnes ou en modifiant les types de colonnes. C’est ce que l’on appelle « l’évolution des schémas ».

Bien qu’il ne s’agisse pas d’un index traditionnel, le journal des transactions peut permettre aux requêtes de récupérer les données plus rapidement et plus efficacement.

Par exemple, imaginons qu’un utilisateur recherche une certaine valeur dans une colonne. En utilisant les métadonnées du journal des transactions, la requête de l’utilisateur peut ignorer tous les fichiers dans lesquels la valeur cible ne peut pas exister. Si la valeur minimale est supérieure ou si la valeur maximale est inférieure à la valeur cible, la requête peut ignorer le fichier.

Le journal des transactions stocke également les chemins d’accès aux fichiers. Au lieu d’analyser l’ensemble du data lake, les requêtes peuvent utiliser ces chemins pour accéder directement aux fichiers pertinents.

Delta Lake peut utiliser des techniques telles que l’ordonnancement en Z (z-ordering) pour stocker des données similaires à proximité les unes des autres sur le disque, ce qui permet d’ignorer facilement les fichiers non pertinents et de trouver ceux qui le sont. 

Les fichiers Parquet normaux ne sont pas modifiables, mais les utilisateurs peuvent manipuler les tables Delta via la couche de métadonnées. Delta Lake prend en charge toutes sortes d’opérations sur les données, notamment l’ajout ou la suppression de colonnes, la mise à jour des entrées et la fusion de fichiers.

Comme le journal des transactions enregistre tout ce qui se passe dans les tables Delta, il conserve l’historique des versions pour chaque table. Les utilisateurs peuvent interroger les versions antérieures et même remonter le temps, c’est-à-dire annuler les modifications pour restaurer les versions précédentes des tables.

Delta Lake dispose d’un écosystème robuste de connecteurs. Le format peut être utilisé avec différents moteurs de calcul, comme Apache Spark, Apache Hive, Apache Flink ou Trino. Delta Lake dispose également d’interfaces de programmation d’applications (API) pour Python, Java, Scala et d’autres langages, permettant aux développeurs de gérer et d’interroger les tables Delta par programmation.

Bien que Delta Lake n’applique pas de contrôles de sécurité de manière native, il peut s’intégrer à des outils de sécurité et de gouvernance des données. Ces outils peuvent ensuite utiliser les métadonnées du journal des transactions pour l’audit des activités, le suivi des modifications et l’application des politiques de contrôle d’accès basé sur les rôles (RBAC).

Delta Lake peut accepter à la fois des données en streaming et des données par lots, et les données peuvent être envoyées à partir de tables Delta vers des services connectés sous forme de flux ou de lots.

Delta Lake 4.0, la prochaine version majeure de Delta Lake, prévoit d’ajouter de nouvelles fonctionnalités, notamment :

• Des commits (validations) coordonnés visant à rationaliser le processus d’écriture sur plusieurs tables et à partir de plusieurs moteurs à la fois.
  
  
• Un nouveau type de données « variant » pour le stockage des données semi-structurées, qui sont traditionnellement difficiles à stocker dans un format de table.
  
  
• L’élargissement de type, qui permet aux utilisateurs de modifier le type de données d’une colonne. 

Apache Iceberg est un format open source haute performance conçu pour être utilisé avec de très vastes tables de données analytiques. Comme Delta Lake, Iceberg crée une couche de métadonnées par-dessus les formats de table existants pour prendre en charge les transactions ACID et d’autres opérations dans le data lake.

Iceberg peut stocker des données dans des fichiers Parquet, ORC ou Avro, tandis que Delta Lake utilise exclusivement les fichiers Parquet. Iceberg utilise également une couche de métadonnées à trois niveaux au lieu d’un journal de transactions unique comme Delta Lake.

Iceberg s’intègre de manière native à de nombreux moteurs de requêtes différents, et c’est un choix courant pour l’analytique basée sur SQL dans les data lakes. 

Comme Delta Lake et Iceberg, Hudi ajoute une couche de métadonnées par-dessus la couche de données. Hudi peut utiliser les formats de fichier Parquet, HFile et ORC, et sa couche de métadonnées prend la forme d’une « chronologie » (ou ligne du temps) qui enregistre tout ce qui se passe dans la couche de données.

Hudi est conçu pour le traitement incrémentiel des données, où de petits lots de données sont fréquemment traités. L’accent mis sur le traitement incrémentiel fait d’Hudi un choix courant pour l’analytique en temps réel et la capture des données modifiées (CDC). 

Le développement du format Delta Lake a ouvert la voie à la création des data lakehouses.

Pendant longtemps, les organisations géraient principalement leurs données dans des entrepôts de données. Bien qu’utiles pour l’analytique et la BI, les entrepôts nécessitent l’utilisation de schémas stricts. Ils ne fonctionnent pas bien avec les données non structurées ou semi-structurées, qui sont devenues plus répandues et plus omniprésentes avec les investissements de plus importants des entreprises dans l’IA et le ML.

Avec l’essor des data lakes au début des années 2010, les organisations disposent désormais d’un moyen de regrouper toutes sortes de données provenant de diverses sources au même endroit.

Cependant, les data lakes ont leurs propres inconvénients. Les processus de contrôle qualité leur font souvent défaut. Ils ne prennent pas en charge les transactions ACID, et il n’est pas facile de les interroger directement.

Pour rendre les données utilisables, les entreprises devaient souvent créer des pipelines de données ETL (extraction, transformation, chargement) distincts afin de déplacer les données d’un data lake vers un entrepôt.  

Delta Lake est apparu en 2016, ajoutant les transactions ACID, l’application de schémas et le voyage dans le temps aux data lakes, les rendant plus fiables pour l’interrogation directe et l’analytique.

Passé en open source en 2019, Delta Lake a joué un rôle clé dans la conception de l'architecture des data lakehouses, qui allie la flexibilité des data lakes à la performance des entrepôts de données.

Nombre d’organisations créent des data lakehouses en créant une couche de stockage Delta Lake par-dessus un data lake existant et en l’intégrant à un moteur de traitement de données tel que Spark ou Hive.

Les data lakehouses permettent la prise en charge de l’intégration des données et rationalisent l’architecture de données en éliminant la nécessité de gérer des data lakes et des entrepôts de données distincts, une approche pouvant conduire à des silos de données.

De leur côté, ces architectures rationalisées permettent de garantir que les data scientists, les ingénieurs de données et les autres utilisateurs peuvent accéder aux données dont ils ont besoin, quand ils en ont besoin. Les workloads d’IA et de ML sont des cas d’utilisation courants pour les data lakehouses optimisés par Delta Lake.

Les data lakes sont, en eux-mêmes, déjà utiles pour ces workloads, car ils peuvent héberger des quantités considérables de données structurées, non structurées et semi-structurées.

En ajoutant des fonctionnalités telles que les transactions ACID et l’application de schémas, Delta Lake contribue à garantir la qualité et la fiabilité des données d’entraînement, ce que les data lakes standard ne peuvent pas faire à un tel niveau.