Moderniser l'ETL SQL dans le Lakehouse avec des modèles déclaratifs

Databricks apporte l'ETL déclaratif aux workflows de data warehousing dans le Lakehouse, permettant aux professionnels du SQL de simplifier plus facilement la logique de transformation complexe dans les environnements familiers où ils travaillent déjà.

Cela fait partie d'une stratégie plus large visant à intégrer le modèle d'exécution déclaratif d'Apache Spark™ Declarative Pipelines dans un plus grand nombre d'expériences de création sur Databricks. Au lieu de devoir travailler dans un environnement dédié aux pipelines, les utilisateurs de SQL peuvent désormais définir des modèles d'ETL courants directement au sein de leurs requêtes SQL dans le Lakehouse Databricks.

Simplifier les modèles d'ETL récurrents dans le Lakehouse

L'ETL SQL déclaratif sur Databricks n'est pas nouveau. Aujourd'hui, des milliers d'utilisateurs orientés SQL s'appuient déjà sur des primitives déclaratives telles que les vues matérialisées et les tables de streaming pour simplifier les transformations récurrentes, maintenir à jour les tables en aval et accélérer les charges de travail BI.

De nombreux modèles d'ETL récurrents sont faciles à décrire mais difficiles à exploiter, nécessitant une logique SQL personnalisée, une planification manuelle et du liant d'orchestration. Ces modèles incluent l'ajout de nouveaux enregistrements, l'application des modifications CDC et l'actualisation des seules données ayant changé.

Les primitives déclaratives fonctionnent car elles permettent aux utilisateurs de décrire la table ou la vue qu'ils souhaitent, au lieu de coder manuellement chaque étape nécessaire pour la maintenir à jour. Databricks gère la planification, l'actualisation et le traitement incrémentiel le cas échéant, de sorte que les utilisateurs n'ont pas à coder manuellement la logique requise pour maintenir les tables à jour.

Nous étendons désormais cette même approche déclarative au-delà de l'éditeur de pipelines Lakeflow à d'autres modèles d'ETL récurrents pour les professionnels du data warehouse et du SQL. Désormais, les utilisateurs du Lakehouse peuvent définir le modèle d'ETL qu'ils souhaitent (directement dans l'éditeur SQL, par exemple) tandis que Databricks gère le traitement incrémentiel, la logique de mise à jour, la planification et l'orchestration nécessaires pour l'exécuter de manière fiable.

Les premières primitives déclaratives disponibles dans le Lakehouse

Les premières opérations déclaratives disponibles dans l'éditeur SQL du Lakehouse correspondent à trois modèles d'ETL récurrents courants : les mises à jour en ajout uniquement (append-only), la capture de données modifiées (CDC) et les écrasements par lots (batch overwrites).

Plusieurs de ces modèles sont déjà disponibles via des API déclaratives comme AUTO CDC dans Lakeflow ; le changement ici consiste à les rendre accessibles directement dans le Lakehouse pour les analystes SQL.

Ces flux peuvent être actualisés selon un calendrier, déclenchés par des mises à jour en amont, exécutés à la demande ou orchestrés via des tâches SQL dans Jobs.

Mises à jour en ajout uniquement

Les mises à jour en ajout uniquement constituent le modèle standard derrière de nombreuses tables de streaming aujourd'hui ; elles sont utilisées pour ajouter de manière incrémentielle de nouveaux enregistrements d'une source vers une table cible. Elles sont couramment utilisées pour les charges de travail d'ingestion, comme le chargement de nouveaux enregistrements depuis un stockage d'objets cloud avec Auto Loader.

Au lieu d'écrire et de planifier une logique d'insertion répétée, les utilisateurs de SQL peuvent définir un flux APPEND simple qui suit automatiquement les nouvelles données par rapport aux données précédemment traitées dans la source. Databricks gère le suivi de l'état et ajoute de manière incrémentielle les nouveaux enregistrements à mesure qu'ils arrivent, gérant automatiquement le pipeline serverless sous-jacent.

Cela offre aux utilisateurs de SQL un moyen simple d'opérationnaliser l'ingestion de type ajout sans avoir à créer, planifier ou gérer manuellement un pipeline distinct.

Découvrez comment définir des flux APPEND dans le Lakehouse.

Capture de données modifiées

Les pipelines CDC figurent parmi les modèles les plus courants — et les plus complexes — de l'ETL SQL. Les équipes utilisent souvent MERGE INTO pour traiter les insertions, les mises à jour et les suppressions, mais les données CDC peuvent arriver dans le désordre, nécessitant une logique supplémentaire pour éviter des résultats incorrects.

AUTO CDC permet aux utilisateurs de SQL de définir la logique CDC avec quelques lignes de code déclaratif dans le Lakehouse. Avec AUTO CDC, il est facile de spécifier les clés, le séquençage, la gestion des suppressions et de choisir de stocker les résultats sous forme de SCD Type 1 ou SCD Type 2, sans avoir à écrire manuellement des pipelines de fusion complexes.

« Chez bsport, SQL AUTO CDC nous a offert un moyen beaucoup plus simple et modulaire de gérer l'ingestion de données dans Databricks. En découplant les chargements de tables d'un pipeline unique, nous avons amélioré la disponibilité et la fraîcheur des données sur l'ensemble de notre plateforme. Cela nous permet de traiter les données de tiers de manière indépendante, ce qui nous offre une meilleure gestion des pannes, réduit la complexité de l'orchestration et rend la configuration globale plus facile à exploiter et à faire évoluer. Pour notre équipe, cela a créé un flux de travail basé sur SQL plus propre, plus flexible et doté d'une plus grande fiabilité en production. »—Adrien Marteau, Head of Data, bsport

Découvrez comment créer des flux AUTO CDC pour SCD Type 1 et Type 2.

Écrasements par lots

Certaines charges de travail d'ETL par lots ont seulement besoin d'actualiser un sous-ensemble spécifique de données, comme une plage de dates, une partition ou un segment d'activité. Traditionnellement, les équipes gèrent souvent cela avec des recalculs complets coûteux ou une logique d'écrasement personnalisée.

Les flux REPLACE WHERE apportent au Lakehouse un modèle déclaratif pour le recalcul par lots incrémentiel et ciblé. Les utilisateurs définissent un prédicat sur la table cible, et Databricks actualise automatiquement cette région. Grâce à Enzyme, le moteur d'incrémentation automatique de Databricks, Databricks peut identifier et traiter uniquement les données qui ont changé au sein du prédicat spécifié lorsque cela est possible, au lieu de recalculer l'intégralité de la table cible ou de réécrire toute la tranche correspondante.

Lors des tests de référence du Lakehouse, REPLACE WHERE optimisé par Enzyme s'est exécuté 3,4 fois plus vite et a coûté 2,5 fois moins cher que le REPLACE WHERE traditionnel. Cela est utile pour le retraitement sélectif, l'évolution du schéma, les backfills (rattrapages de données) et l'itération sur une petite fenêtre de données avant de traiter une plage historique plus large.

Découvrez comment utiliser les flux REPLACE WHERE pour actualiser un sous-ensemble ciblé d'une table (et lisez le blog de la communauté ici).

En résumé : pourquoi cela est important pour les professionnels du SQL

Moderniser votre ETL ne nécessite pas une réécriture totale ni un engagement absolu envers des frameworks de pipelines complexes. L'intégration de la sémantique déclarative dans vos opérations SQL Lakehouse existantes vous permet de combiner votre code existant avec du SQL déclaratif modernisé là où cela est le plus pertinent.

Vous pouvez conserver vos requêtes SQL procédurales existantes et optimisées pour les tâches personnalisées, tout en intégrant de manière transparente des opérations déclaratives telles que l'ingestion en ajout uniquement, AUTO CDC ou les écrasements par lots ciblés pour les modèles récurrents nécessitant beaucoup de maintenance. Cela vous offre le meilleur des deux mondes : un contrôle total sur votre logique SQL traditionnelle, combiné à une gestion automatisée de l'état, de la gestion des dépendances et de l'évolution du schéma là où vous le souhaitez, le tout directement au sein du Lakehouse.

Des primitives déclaratives aux pipelines déclaratifs complets

L'intégration de primitives déclaratives dans vos flux de travail SQL quotidiens constitue un point de départ pratique et fluide pour gérer des tables individuelles et une logique incrémentielle. À mesure que votre projet gagne en envergure et en complexité, votre flux de travail de développement peut naturellement évoluer à ses côtés.

Pour les équipes qui gèrent plusieurs transformations liées, des dépendances partagées et des flux de production, l'éditeur de pipelines Lakeflow offre une expérience de développement plus riche et orientée projet pour l'ETL déclaratif, avec la prise en charge du développement multi-fichiers, de la gestion des dépendances, de la visualisation des pipelines, de la validation intégrée et du déploiement en production.

Cela est particulièrement utile pour les équipes qui gèrent de nombreuses transformations liées à travers différents domaines, produits de données ou unités commerciales. Au lieu de maintenir des scripts déconnectés ou de centraliser toute la logique dans un seul grand projet, les équipes peuvent organiser les flux déclaratifs dans des pipelines gouvernés et détenus par l'équipe sur Databricks. Avec Unity Catalog, chaque équipe peut s'appuyer sur des actifs de données partagés, gérer les autorisations de manière cohérente et comprendre le lignage à travers les pipelines et les consommateurs en aval.

Les professionnels du SQL peuvent commencer par des flux déclaratifs dans l'éditeur SQL familier, puis passer à l'éditeur de pipelines lorsqu'ils ont besoin d'un environnement plus structuré pour des projets plus importants, une gestion plus approfondie des pipelines et un développement en équipe.

En savoir plus sur la création de flux de travail ETL déclaratifs avec l'éditeur de pipelines Lakeflow.

Utilisez Genie Code pour démarrer plus rapidement

Genie Code permet aux professionnels du SQL de découvrir et d'appliquer plus facilement ces modèles ETL déclaratifs dans les flux de travail qu'ils utilisent déjà. Au lieu de partir d'une page blanche ou de traduire manuellement du SQL existant en un modèle prêt pour la production, les utilisateurs peuvent demander à Genie Code de les aider à générer, expliquer et affiner des flux déclaratifs.

Par exemple, un utilisateur travaillant avec des données CDC peut demander à Genie Code de l'aider à créer un flux AUTO CDC, y compris les clés appropriées, la colonne de séquence, la gestion des suppressions et le comportement SCD Type 1 ou Type 2. Un utilisateur travaillant avec une logique de traitement par lots récurrente peut demander à Genie Code de l'aider à convertir une logique de remplacement existante en un flux incrémentiel REPLACE WHERE.

À mesure que l'ETL déclaratif devient disponible dans un plus grand nombre d'expériences de création, Genie Code peut aider à guider les utilisateurs vers le modèle déclaratif adapté à la tâche à accomplir.

Pour commencer, explorez la documentation liée dans chaque section ci-dessus et utilisez Genie Code dans l'éditeur SQL pour identifier où les flux APPEND, les flux AUTO CDC ou les flux REPLACE WHERE peuvent simplifier votre logique ETL existante.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original