Avec Delta Lake 3.0, Databricks tente de faire communier Delta, Hudi et Iceberg

UniForm remet les tables Parquet au centre du jeu

Cette fonctionnalité fournie par Databricks, disponible en préversion publique depuis le runtime de sa plateforme cloud, diffère des approches concurrentes. Des acteurs comme Snowflake, Oracle et Cloudera entendent offrir un support natif du format de stockage Iceberg.

La stratégie des responsables du projet Delta Lake consistait davantage à transformer les tables Iceberg et Parquet en tables Delta. En ce sens, Delta Lake 3.0 apporte un moyen de conversion sans toutefois réécrire ou modifier les fichiers Parquet sous-jacents.

Pourquoi UniForm est-il intéressant ? Selon Hemavathi Thirappathi, directrice senior, spécialiste des architectures de données et de Databricks chez Capgemini, l’objectif est « d’éliminer les silos en ne stockant qu’une fois les tables au format Parquet ».

En revanche, les métadonnées sont entreposées plusieurs fois, pour mettre à jour les tables Delta, Hudi et Iceberg associées.

Il ne faut cependant pas oublier qu’il s’agit bien là d’un nouveau format de stockage de tables. Certes, celui-ci est open source et ses créateurs considèrent que les tables Parquet ne doivent pas être réécrites. Quid des performances ?

« Lorsque UniForm est activé, il faut s’attendre à une très faible surcharge d’écriture Delta, car la conversion et la transaction Iceberg se produisent de manière asynchrone après la validation Delta », ajoute Hemavathi Thirappathi dans un billet publié sur LinkedIn.

Selon Databricks, les performances d’écriture de Delta seraient 5 % plus lentes avec UniForm, mais la lecture des fichiers compatibles Iceberg serait 30 % plus rapide qu’avec le format Iceberg natif. À titre de comparaison, Benoît Dageville, cofondateur et directeur du produit chez Snowflake annonçaient lors du Snowflake Tour parisien que l’éditeur arrivait à obtenir des performances pratiquement équivalentes entre le format Iceberg et celui de Snowflake.

Une possible dépendance à gommer

Pour autant, il existe actuellement une grosse limitation. « UniForm est en lecture seule du point de vue d’Iceberg, bien que cela ne puisse pas encore être appliqué, car UniForm utilise des validations basées sur le système de fichiers lors de l’écriture d’Iceberg », prévient la documentation. « Si un outil externe (qui n’est pas Delta Lake) écrit dans cette table Iceberg, cela peut détruire votre table Delta et entraîner une perte de données, car le writer Iceberg peut effectuer un nettoyage des données ou un ramassage des ordures dont Delta n’a pas connaissance ».

Plutôt que de prendre directement en charge les tables Iceberg, il s’agit de pousser une forme d’interopérabilité avec les outils qui lisent des tables Iceberg et qui ne seraient pas déjà ou difficilement compatibles avec Delta. Ces outils peuvent être ceux de Dremio, Starburst, Snowflake, Fivetran, Airbyte, Informatica, AWS, GCP, dbt, Confluent, etc.

« C’est un excellent concept », déclarait en juin dernier Kevin Petrie, analyste chez Eckerson Group auprès de SearchDataManagement, une publication sœur du MagIT. « Le mélange d’entrepôts de données, de lacs de données, de lakehouse et d’autres approches crée des problèmes de qualité des données, des complexités de transformation et une confusion quant aux données à exploiter pour un projet spécifique ».

Toutefois, UniForm n’est un excellent concept que si l’utilisation de Delta Lake 3.0 n’entraîne pas de dépendance vis-à-vis de Databricks, principal contributeur du projet Delta Lake, poursuit Kevin Petrie. Si le choix de Delta Lake 3.0 réduit les autres options de reformatage ou de déplacement des données de Delta Lake vers un autre format de stockage, UniForm sera problématique, affirme-t-il.

Delta Kernel, pour simplifier le développement des connecteurs

Dans cette même volonté de simplification, Delta Lake 3.0 intègre, en préversion, le projet Delta Kernel. Il s’agit d’harmoniser le fonctionnement des connecteurs qui exploitent le protocole Delta chargé de la garantie des propriétés ACID par-dessus le data lake.

« Nous avons au moins huit implémentations différentes de ce protocole », expliquait Denny Lee, Senior Staff Developer Advocate chez Databricks, lors du Data & IA Summit 2023, en juin dernier. « Pourquoi ? Parce que chaque équipe des éditeurs ou des projets open source développe ses propres connecteurs ».

Databricks et les contributeurs au projet Delta avaient déjà œuvré à simplifier le parsing des fichiers de logs et le rejeu de ces logs au moment d’utiliser les données. La lecture des tables Parquet est prise en charge par la plupart des outils du marché. Pour autant, comme le protocole Delta évolue, les connecteurs doivent aussi évoluer.

Les API Table de Delta Kernel implémentent les spécifications du protocole pour lire et écrire les tables Delta. « Delta Kernel abstrait la gestion des logs et des données et joue le rôle d’une boîte noire pour le connecteur et le moteur de traitement », déclare Tathagata Das, Staff Software engineer chez Databricks.

L’idée est de permettre de développer des librairies Java, Python et Rust pour lire des tables Delta « sans besoin de comprendre les détails du protocole Delta ». Par défaut, il n’y aurait pas besoin de redévelopper les connecteurs, mais simplement de mettre à jour la version de Delta Kernel pour suivre les évolutions de Delta Lake.

Pour autant, il est possible de personnaliser les connecteurs en fonction du moteur en s’appuyant sur les API « TableClient ». « Vous avez la possibilité de prendre ce même kernel, d’y intégrer un reader Trino sur des fichiers Parquet, pour que cela soit plus rapide dans ce contexte », illustre Denny Lee.

Aujourd’hui, les librairies Java disponibles permettent de :

• « Lire des données à partir de petites tables Delta dans un seul thread au cours d’un seul processus.
• Lire les données de grandes tables Delta à l’aide de plusieurs threads dans un seul processus.
• Construire un connecteur complexe pour un moteur de traitement distribué et lire de très grandes tables Delta ».

Plus tard, il sera possible « d’écrire dans les tables Delta à partir de plusieurs threads, processus ou moteurs distribués », d’après la documentation du projet Delta Lake. La version Rust de Delta Kernel arrivera plus tard.

C’est donc maintenant aux équipes chargées de développer les connecteurs de se pencher sur ce projet.

Une plateforme a priori plus robuste et plus performante

En outre, Delta Lake 3.0 apporte des améliorations des performances et du fonctionnement des opérations Merge, Update et Delete. Les opérations Merge et Delete seraient deux fois plus rapides qu’auparavant, tandis que les updates pourraient être « jusqu’à dix fois plus rapide ».

Pour ce faire, les trois opérations sont effectuées en activant la fonction d’optimisation du stockage delection vectors, introduite dans la version 2.3.0 de Delta Lake. « Par défaut, lorsqu’une seule ligne d’un fichier de données est supprimée, l’ensemble du fichier Parquet contenant l’enregistrement doit être réécrit », relate la documentation du projet. « Lorsque les vecteurs de suppression sont activés pour la table, certaines opérations Delta utilisent ces vecteurs pour marquer les lignes existantes comme supprimées sans réécrire le fichier Parquet. Les lectures ultérieures de la table résolvent l’état actuel de la table en appliquant les suppressions notées par les vecteurs à la version la plus récente de la table ».

Enfin, cette mouture intègre une version 2 du format checkpoint. Ce système qui permet de stocker des états de tables à un moment T dans le temps est désormais plus robuste. En lien avec checkpoint, les contributeurs apportent une capacité de compression des logs.