Pourquoi utiliser Delta Lake ?

Dans cet article je vais vous présenter ce qu’apporte véritablement la solution Delta Lake, proposée en open source par Databricks. En effet, sortie le 29 Avril 2019, la première version de Delta Lake se présente à nous sous la forme d’une couche de stockage open source apportant les transactions ACID à Apache Spark et rendant pas conséquent les données des data lakes plus fiables. Selon moi, elle a changé beaucoup de choses dans la gestion des cycles de vie de nos data lakes, c’est pourquoi j’ai eu envie de vous les présenter au travers cet article de blog.

Delta Lake pour une meilleure intégrité des données

Nous le savons tous, depuis quelques années, les entreprises stockent leurs données sur des Data Lakes, appelé aussi en français lac de données. Il n’est pas s’en dire que la gestion des mises à jour est généralement problématique.  

Prenons l’exemple typique de fichiers de logs applicatifs : lors de la première ingestion, les logs du 01/03/2020 sont nettoyés et traités pour garder les informations essentielles. A partir de ces informations, une nouvelle table « clean_log » partitionnée par jour au format “parquet” est créée.  

Le lendemain, lors de l’ingestion du 02/03/2020, au moment de l’ajout des nouvelles entrées, un problème survient au moment de l’écriture. La table « clean_log » est donc maintenant corrompue. Soit une copie est disponible avant le problème d’écriture, soit il faut reconstituer la table à partir des fichiers d’origines. Dans cet exemple, la deuxième solution ne semble pas très coûteuse sachant que l’historique est de deux jours. Imaginez maintenant le coût d’une telle solution avec un historique de deux ou trois ans. 

En utilisant Delta Lake, cette situation ne se produit plus ! Avec cette solution, la transaction en échec est annulée et Delta Lake revient à l’état précédent. Il est donc possible de reprendre là où l’opération a échoué.  

La garantie de l’intégrité des données est un des premiers atouts majeurs de Delta Lake.

Gestion de l’historique grâce à la composition d’une table Delta Lake

L’idée a été de reprendre ce qui existe déjà depuis des décennies pour les bases de données, je parle ici des logs transactionnels. En effet, une table Delta Lake est composée de fichiers au format parquet et de logs transactionnels. 

Dans ces logs sont stockés toutes les activités effectuées sur une table. 

Par exemple, lorsque l’on affiche les 3 dernières opérations, voici ce que nous retrouvons  : 

Ainsi, il est facile de retracer l’historique. D’ailleurs, il est aussi possible de copier la table à un état précédent ou même de revenir à cet état.
En fonction des cas, vous pourrez limiter ou augmenter la durée de rétention de l’historique. Par défaut, celle-ci est de 7 jours glissants. 

Optimisation du nombre de fichier et cohérence des données

Un des autres atouts de l’utilisation de Delta Lake est l’optimisation du nombre de fichier parquet. Plus il y a de fichiers différents, plus les opérations de lecture et d’écriture sont coûteuses. Ainsi, Delta Lake permet de limiter le nombre de fichiers parquet au minimum. De plus, il y a également un mécanisme de cache qui peut être utilisé pour réduire encore le nombre I/O. 

Une autre problématique à laquelle répond Delta Lake est la cohérence des données dans le temps en s’assurant de la cohérence des schémas. En effet, Delta Lake garde en mémoire le schéma utilisé lors de la création de la table. Si une manipulation pour insérer des nouvelles données ne respectant pas ce schéma est lancé alors le traitement se verra refusé , vous aurez donc ce message : 

“org.apache.spark.sql.AnalysisException: A schema mismatch detected when writing to the Delta table.”

Il est néanmoins possible d’autoriser la modification du schéma avec l’ajout de nouvelles colonnes. Ainsi, on profite d’une cohérence qu’apporte une base de données mais avec la souplesse d’un Data Lake. 

La syntaxe pour lire ou écrire dans une table est très proche de la syntaxe pour manipuler du parquet. A la place de « parquet », il faut spécifier « delta » : 

Dans un Data Lake, les ingestions sont régulières et toujours en append (ajout de valeur). Si l’on veut faire un “update” ou un “delete”, nous devons parcourir à minima toute la partition pour effacer les lignes souhaitées et ajouter la nouvelle ligne en cas d’update. Voici deux exemples :

Exemple de delete en PySpark : 

Exemple d’update en PySpark : 

Pour finir

Delta Lake permet de réaliser des merges sur les tables existantes. Le principe est simple : au moment de mettre à jour la table existante, il est possible de mettre en place une condition permettant de décider s’il faut insérer des données ou bien mettre à jour des données existantes à partir des nouvelles données. Il est également possible de supprimer ces données. 

Voici un exemple en Spark SQL : 

J’espère avoir réussi à vous convaincre d’utiliser Delta Lake, cette solution vous permettra d’apporter à vos data lakes plus de fiabilité et de performance. Sachez aussi que Delta Lake offre de nombreuses autres fonctionnalités comme par exemple l’accès à une table à la fois en batch et en streaming.

Pour découvrir les autres fonctionnalités en détail, je vous conseille de lire la documentation de Delta Lake présente sur le site Datbricks.