Rafik BELLAHSENE, Data Architect
Ces dernières années, l’exploitation des données dans un cadre de pilotage de l’activité n’a cessé de se développer. Avec elle sont apparus de nouvelles problématiques liées aux méthodes traditionnelles d’extraction, transformation et chargement (ETL) des données qui ne sont plus adaptées aux volumes toujours plus importants à traiter. Associés à la complexité croissante des règles métiers à implémenter, il devient de plus en plus difficile pour les data engineers de développer et tester des processus d’intégration performants et robustes.
De manière paradoxale, garantir la qualité des données en fonction des exigences métiers reste un enjeu central, la moindre imprécision et/ou non-conformité aux normes établies par l’entreprise ayant pour conséquence de compromettre la fiabilité des analyses et des prises de décisions.
Un autre défi majeur réside dans la rapidité d’intégration des données. La fréquence d’exécution des flux de données étant toujours plus soutenue, pour répondre à des besoins de traitements en temps réel ou s’en rapprochant, les processus ETL doivent se montrer apte à manipuler les données de manière performante et sans en altérer la qualité.
Pour relever ces défis, les entreprises se tournent vers l’architecture Lakehouse, qui propose une approche intégrée pour la gouvernance, la sécurité et le traitement des données, que ce soit en temps réel ou par lots.
Dans cette perspective, Delta Live Tables (DLT) joue un rôle important en proposant une approche ETL moderne et automatisée. DLT assure la qualité des données et offre une clarté accrue sur leur cycle de vie, optimisant ainsi leur mise à disposition pour les divers secteurs d’activité de l’entreprise.
Delta Live Tables (DLT) est un framework permettant de construire des pipelines de traitement de données à grande échelle. Il est intégré dans l’environnement Databricks et s’inscrit dans l’architecture globale Lakehouse. Il permet de :
- Créer des pipelines ETL de façon déclarative : Comparé à l’approche ETL procédurale, DLT offre une approche plus flexible et lisible pour les transformations de données. Plutôt que de spécifier les étapes à suivre, DLT permet de décrire les résultats souhaités, laissant le moteur DLT gérer les dépendances entre les étapes. Cela favorise la qualité des données et libère les data engineers des contraintes techniques, leur permettant ainsi de se concentrer sur les objectifs métiers.
- Garantir la qualité de données : DLT vérifie la qualité des données en les comparant aux attentes définies par les data engineers. Il génère automatiquement les rapports de qualité de données.
- Offrir un meilleur suivi : DLT surveille de manière globale l’état du pipeline et met à disposition un rapport visuel du flux de données (data lineage), fournissant ainsi une vue globale de la performance, de la qualité, du statut et de la latence du traitement.
- Simplifier les déploiements de données en production : DLT permet de mettre en production les pipelines ou de les retirer en un seul clic, ce qui réduit les périodes d’inactivité et facilite l’adoption des processus d’intégration continue et de déploiement continu (CI/CD).
Delta Live Tables propose des structures de données sous forme de Tables de streaming, vues matérialisées et vues.
Type de structure | Description |
Table de streaming (Streaming Live Table) | Table Delta où chaque enregistrement n’est traité qu’une seule fois. Elle est adaptée aux sources de données en mode ajout (append only) ou incrémental |
Vue matérialisée (Live Table) | Réduit les coûts et améliore la latence des requêtes en précalculant les requêtes lentes et les calculs fréquemment utilisés. Elle est utilisée pour les sources de données avec des mises à jour (update), des suppressions (delete) ou pour le Change Data Capture (CDC) |
Vue | Table virtuelle qui calcule le résultat d’une requête à chaque appel. Elle est adaptée pour les transformations intermédiaires et les vérifications de qualité des données qui ne doivent pas être publiées dans des ensembles de données publics |
En résumé, l’utilisation d’une structure ou une autre est guidée par certains besoins technico-fonctionnels.
Privilégiez :
- Les vues, si :
- Vous souhaitez stocker des résultats de requêtes intermédiaires.
- Vous souhaitez réduire les coûts de stockage et de calcul et que vous n’avez pas besoin de matérialiser les résultats d’une requête
- Les vues matérialisées, si:
- La table est fréquemment consultée
- Vous avez des sources de données en mode upsert / CDC
- Les tables streaming, si :
- Vous avez une source de données qui augmente continuellement ou de manière incrémentale.
- Vous souhaitez un débit élevé et une faible latence pour le pipeline DLT
Lorsque vous configurez votre premier pipeline Delta Live Tables (DLT), il est fort probable que vous vous posiez des questions sur les choix techniques. Pour vous guider dans cette configuration, je vais partir d’une série de questions et vous fournir les réponses correspondantes.
Quel type d’exécution puis-je définir pour mon pipeline DLT ?
Delta Live Tables prend en charge certains types d’exécutions de pipelines, notamment :
- Triggered Execution: Les tables sont mises à jour sur ordonnancement ou manuellement, sans nécessiter le maintien en ligne du compute en dehors des périodes d’exécution. Le traitement des données est stoppé après avoir réussi à actualiser toutes les tables ou uniquement celles sélectionnées dans le pipeline.
- Continuous Execution : Delta Live Tables assure le traitement continu des nouvelles données au fur et à mesure qu’elles arrivent, permettant ainsi de maintenir les tables à jour, ce qui nécessite un cluster qui tourne en permanence.
Le mode d’exécution est indépendant du type de table en cours de calcul. Les vues matérialisées et les tables de streaming peuvent être mises à jour dans les deux modes d’exécution.
Quel est la différence entre les diverses éditions de produit DLT ?
Il existe différentes éditions de DLT. Cependant, le choix d’une édition n’est pas aléatoire et dépend fortement du besoin technique que vous avez.
Edition DLT | Description |
Core | Sélectionnez l’édition Core si votre pipeline ne nécessite pas de fonctionnalités avancées telles que la capture de la modification de données (CDC) ou les attentes (Expectations) de Delta Live Tables |
Pro | L’édition Pro prend en charge toutes les fonctionnalités de l’édition Core, ainsi que la prise en charge de la capture de la modification de données (CDC) |
Advanced | L’édition Advanced prend en charge les fonctionnalités des éditions Core et Pro, et permet également l’application de contraintes de qualité des données (Expectations) |
Quels sont les différents modes de pipeline DLT ?
Mode de développement :
- Le système DLT réutilise un cluster pour éviter les surcharges liées aux redémarrages. Par défaut, les clusters s’exécutent pendant deux heures lorsque le mode de développement est activé. Vous pouvez modifier cette durée en utilisant le paramètre « clusterShutdown.delay » dans la configuration de vos paramètres du compute.
- Il désactive également les mécanismes de relance du pipeline afin de pouvoir corriger immédiatement les erreurs
Mode de production :
Le système DLT :
- Redémarre le cluster en cas d’erreurs spécifiques récupérables, telles que des fuites de mémoire ou des informations d’identification obsolètes.
- Réessaie l’exécution en cas d’erreurs spécifiques, par exemple, une erreur de démarrage du cluster.
Comment sont gérées les mises à jour des vues matérialisées et des vues dans DLT ?
La mise à jour des tables et des vues, ainsi que la manière dont ces tables et vues sont mises à jour, dépendent du type de mise à jour :
- Rafraîchissement complet : Toutes les vues et vues matérialisées sont mises à jour pour refléter l’état actuel de leurs sources de données d’entrée. Pour toutes les tables de streaming, les nouvelles lignes sont ajoutées à la table.
- Rafraîchissement complet total : Toutes les vues et vues matérialisées sont mises à jour pour refléter l’état actuel de leurs sources de données d’entrée. Pour toutes les tables de streaming, Delta Live Tables tente de supprimer l’intégralité des données, puis de charger les données à partir de la source en streaming.
- Rafraîchissement sélectif : Le comportement du rafraîchissement sélectif est identique à celui du rafraîchissement complet, mais il permet de rafraîchir uniquement les tables sélectionnées. Les vues et vues matérialisées sélectionnées sont mises à jour pour refléter l’état actuel de leurs sources de données d’entrée. Pour les tables de streaming sélectionnées, les nouvelles lignes sont ajoutées à la table.
- Rafraîchissement complet sélectif : Le comportement du rafraîchissement complet sélectif est identique à celui du rafraîchissement complet total, mais il permet d’effectuer un rafraîchissement complet uniquement des tables sélectionnées. Les tables en temps réel sélectionnées sont mises à jour pour refléter l’état actuel de leurs sources de données d’entrée. Pour les tables de streaming sélectionnées, Delta Live Tables tente de supprimer toutes les données de chaque table, puis de charger toutes les données à partir de la source en continu.
Pour les vues matérialisées, une mise à jour a le même comportement qu’un REFRESH SQL. Pour les nouvelles tables, le comportement est le même qu’une opération CREATE SQL.
Comment est géré le mode UPSERT dans DLT ?
Le mode UPSERT est uniquement géré en mode CDC (Change Data Capture) pour une vue matérialisée uniquement.
Ce mode connait quelques limites :
- La table de destination d’un CDC ne peut être utilisée comme source streaming pour une autre table. Elle ne peut être différente d’une vue matérialisée
- Les attentes ne sont pas prises en charge dans une requête CDC. Pour utiliser des attentes (expectations) pour le jeu de données source ou cible :
- Pour définir des attentes sur la table source : Ajoutez des attentes sur les données source en définissant une table intermédiaire avec les attentes requises.
- Pour définir des attentes sur la table cible : Utilisez le même principe cité ci-dessus. Ajoutez des attentes sur les données cibles avec une table en aval qui lit les données d’entrée à partir de la table cible.
Quelles sont les optimisations natives offertes par DLT ?
DLT exécute des optimisations chaque jour sur les données entreposées dans le Delta Lakehouse.
Les opérations de ZOrder et d’Auto-optimize sont exécutées par le cluster de maintenance de Databricks.
- Toutes les tables créées et mises à jour par Delta Live Tables sont des tables Delta
- Les tables de Delta Live Tables ne peuvent être définies qu’une seule fois, ce qui signifie qu’elles ne peuvent être la cible que d’une seule opération dans tous les pipelines de Delta Live Tables.
- Les tables de Delta Live Tables ne peuvent être modifiées en dehors d’un pipeline DLT
Dans cet article, je vous ai présenté Delta Live Tables et ses diverses configurations.
Dans un prochain article, je ferai une démonstration de l’outil en implémentant des pipelines de transformation de données en Python & SQL. Pour des flux de données SQL orientés Analytics (Implémentation d’un Delta Lakehouse), je vous conseille, pour l’heure, l’utilisation de Dbt dans Databricks. Si vous voulez en savoir plus, Hamza Zelmat vous explique ici comment déployer pas à pas dbt votre Delta Lakehouse.
Pour conclure, Delta Live Tables demeure un bon outil de data engineering, facilitant la création et la maintenance des logiques ETL à grande échelle. Il possède également tous les atouts nécessaires pour les applications IoT.
En revanche, il reste incomplet pour des applications data en mode batch. A ce propos, Databricks a annoncé des modifications majeures à venir lors du AI Summit 2023.