Cas pratiques dbt

Contexte : La colonne order_id doit être unique dans la table des commandes transformées. Le Problème : Aucun contrôle d’unicité n’est actuellement en place. Contraintes : Ajouter un test unique dans le fichier schema.yml. Ne pas modifier la structure du modèle SQL. Livrable attendu : Fournir la configuration YAML permettant de vérifier automatiquement l’unicité de order_id.

Contexte : Un modèle tente de référencer un autre modèle via la fonction ref(). Le Problème : Le nom utilisé dans ref() ne correspond à aucun modèle existant. Extrait actuel : select * from {{ ref('customer_data') }} Le modèle réel s’appelle customers. Contraintes : Corriger la référence sans modifier la logique métier. Maintenir la dépendance correcte entre modèles. Livrable attendu : Proposer une correction permettant au modèle de compiler et s’exécuter correctement.

Contexte : Deux modèles dbt se référencent mutuellement via ref(). Le Problème : La compilation échoue en raison d’une dépendance circulaire. Extrait logique actuelle : model_a utilise ref('model_b') model_b utilise ref('model_a') Contraintes : Identifier la boucle. Réorganiser la logique sans perdre l’intégrité des transformations. Livrable attendu : Proposer une restructuration des modèles éliminant la dépendance circulaire.

Contexte : Un modèle censé être une table est matérialisé en view par défaut. Le Problème : Les performances sont insuffisantes pour les requêtes fréquentes. Extrait actuel : {{ config(materialized='view') }} Contraintes : Modifier la matérialisation en table. Conserver la logique SQL existante. Livrable attendu : Proposer une configuration adaptée permettant une matérialisation en table pour améliorer les performances.

Contexte : Le projet dbt utilise une variable d’environnement pour définir le schéma cible. Le Problème : L’exécution échoue car la variable n’est pas définie. Extrait actuel : {{ env_var('DBT_SCHEMA') }} Contraintes : Définir correctement la variable dans l’environnement ou fournir une valeur par défaut. Livrable attendu : Proposer une correction garantissant la compilation et l’exécution du projet dbt.

Contexte : Un modèle dbt tente d’utiliser une table source définie dans un fichier YAML. Le Problème : L’exécution échoue car la source n’est pas correctement déclarée. Extrait actuel : select * from {{ source('sales', 'transactions') }} La source sales n’existe pas dans le fichier sources.yml. Contraintes : Déclarer correctement la source dans un fichier YAML. Respecter la structure dbt. Livrable attendu : Proposer une déclaration correcte de la source permettant l’exécution du modèle sans erreur.

Contexte : L’équipe métier souhaite consulter le total des ventes par mois. Le Problème : Les données brutes ne sont pas agrégées et nécessitent une transformation répétée. Contraintes : Créer un modèle dbt utilisant GROUP BY sur une colonne date. Calculer SUM(amount). Respecter les conventions dbt. Livrable attendu : Écrire un modèle dbt produisant une table agrégée prête pour reporting mensuel.

Contexte : Votre équipe data commence à utiliser dbt pour structurer les transformations analytiques dans le data warehouse. Le Problème : Les requêtes SQL sont exécutées manuellement sans versioning ni structuration claire. Contraintes : Créer un modèle dbt simple à partir d’une table source sales_raw. Utiliser une requête SELECT propre et documentée. Respecter la convention de nommage des modèles. Livrable attendu : Écrire un modèle dbt basique permettant de transformer les données brutes en une table propre prête pour analyse.

Contexte : Les analystes utilisent les tables transformées mais manquent de documentation. Le Problème : Les modèles dbt ne sont pas documentés dans le fichier YAML. Contraintes : Ajouter une description au modèle et aux colonnes principales. Générer la documentation via dbt docs. Livrable attendu : Proposer un exemple de documentation YAML claire pour un modèle et ses colonnes.

Contexte : Une colonne id dans une table transformée ne doit jamais contenir de valeur NULL. Le Problème : Aucun test de qualité des données n’est encore configuré. Contraintes : Ajouter un test not_null dans le fichier schema.yml. Ne pas modifier la table source. Livrable attendu : Fournir la configuration YAML permettant de tester automatiquement la non-nullité de la colonne id.

Contexte : Un modèle incrémental est utilisé pour charger des données journalières. Le Problème : Des doublons apparaissent car la clé unique n’est pas correctement définie. Extrait actuel : {{ config(materialized='incremental') }} Aucune unique_key spécifiée. Contraintes : Définir une unique_key adaptée. Gérer correctement les mises à jour via strategy='merge' si supportée. Livrable attendu : Proposer une configuration incrémentale corrigée garantissant l’absence de doublons.

Contexte : Un modèle utilise une table directement sans passer par ref(). Le Problème : dbt ne détecte pas correctement la dépendance, impactant l’ordre d’exécution. Extrait actuel : select * from analytics.customers Au lieu d’utiliser {{ ref('customers') }}. Contraintes : Remplacer les références directes par ref(). Garantir un DAG correct dans dbt. Livrable attendu : Proposer une correction assurant une gestion correcte des dépendances entre modèles.

Contexte : Un fichier CSV utilisé comme seed contient des données de référence critiques. Le Problème : Les données ne sont pas correctement chargées ou typées. Extrait actuel : dbt seed Aucune configuration de types dans le YAML. Contraintes : Définir les types de colonnes dans le fichier schema.yml. Garantir cohérence avec le modèle cible. Livrable attendu : Proposer une configuration seed correcte assurant un chargement fiable et typé des données de référence.

Contexte : Le projet dbt est déployé en dev et prod avec des schémas différents. Le Problème : Les variables sont codées en dur dans certains modèles. Extrait actuel : from dev_schema.sales Contraintes : Utiliser des variables ou profiles.yml pour gérer les environnements. Éviter toute référence statique. Livrable attendu : Proposer une stratégie de gestion dynamique des environnements garantissant portabilité et maintenabilité.

Contexte : Une table transformée contient plusieurs centaines de millions de lignes et le build complet prend trop de temps. Le Problème : Le modèle est matérialisé en table classique et est reconstruit intégralement à chaque exécution. Contraintes : Utiliser la matérialisation incremental. Définir une clé unique pertinente. Implémenter une logique conditionnelle avec is_incremental(). Garantir l’intégrité des données. Livrable attendu : Proposer un modèle dbt incrémental permettant de charger uniquement les nouvelles données ou mises à jour.

Contexte : Les données clients évoluent dans le temps et l’équipe souhaite conserver l’historique des changements. Le Problème : Les mises à jour écrasent les anciennes valeurs sans traçabilité. Contraintes : Utiliser un snapshot dbt. Définir une stratégie timestamp ou check. Garantir la traçabilité des modifications. Livrable attendu : Proposer une configuration de snapshot permettant de conserver l’historique des changements dans une table dédiée.

Contexte : Les équipes métiers ont besoin d’une documentation claire des modèles et sources. Le Problème : La documentation actuelle est partielle et incohérente. Contraintes : Documenter modèles, sources et colonnes dans YAML. Ajouter descriptions détaillées. Générer le site via dbt docs. Livrable attendu : Proposer une structure de documentation complète permettant une meilleure gouvernance des données.

Contexte : Les tests standards (not_null, unique) ne couvrent pas toutes les règles métier. Le Problème : Certaines incohérences spécifiques ne sont pas détectées automatiquement. Contraintes : Créer un test personnalisé SQL dans le dossier tests. Implémenter une règle métier (ex : montant toujours positif). Intégrer le test dans schema.yml. Livrable attendu : Proposer un test personnalisé permettant de valider une règle métier spécifique dans dbt.

Contexte : Un modèle dbt contient de nombreuses CTE imbriquées et complexes. Le Problème : Les performances se dégradent sur le data warehouse cible. Contraintes : Identifier les sous-requêtes coûteuses. Évaluer la possibilité de matérialiser certaines étapes intermédiaires. Maintenir la lisibilité du code. Livrable attendu : Proposer une stratégie d’optimisation permettant d’améliorer les performances tout en conservant la logique métier.

Contexte : Un modèle combine plusieurs tables volumineuses pour produire un reporting consolidé. Le Problème : Les temps de build sont élevés et consomment beaucoup de ressources warehouse. Contraintes : Réduire le volume avant jointure. Introduire des filtres précoces. Évaluer une matérialisation intermédiaire. Livrable attendu : Proposer une optimisation structurelle du modèle permettant de réduire le coût et le temps d’exécution.

Contexte : Le projet dbt est utilisé en dev, staging et production avec des règles de promotion strictes. Le Problème : Les déploiements manuels entraînent des divergences entre environnements. Contraintes : Mettre en place un workflow Git structuré. Automatiser les déploiements. Séparer profils et variables par environnement. Livrable attendu : Proposer une stratégie complète de versioning et promotion des modèles dbt entre environnements garantissant cohérence et traçabilité.

Contexte : Votre organisation adopte une approche data mesh avec plusieurs équipes responsables de leurs propres domaines de données. Le Problème : Les modèles dbt sont interconnectés sans contrats formels, ce qui provoque des régressions lorsqu’un schéma change. Contraintes : Mettre en place des data contracts via schema.yml avec enforced constraints. Séparer les projets par domaine tout en conservant des dépendances maîtrisées. Garantir la rétrocompatibilité. Livrable attendu : Proposer une architecture dbt multi-domaines intégrant data contracts, gouvernance des schémas et gestion claire des dépendances inter-domaines.

Contexte : Les incidents data sont difficiles à diagnostiquer et l’impact d’un changement est mal anticipé. Le Problème : Le lineage n’est pas exploité pleinement et aucun monitoring de qualité continu n’est en place. Contraintes : Exploiter le graph dbt. Intégrer des alertes qualité. Centraliser logs et résultats de tests. Garantir traçabilité complète. Livrable attendu : Proposer une stratégie d’observabilité et de lineage avancée permettant supervision proactive et traçabilité des transformations.

Contexte : Le pipeline CI/CD exécute dbt build sur l’ensemble du projet à chaque modification. Le Problème : Les temps de déploiement sont trop longs et consomment inutilement des ressources warehouse. Extrait actuel : dbt build Sans sélection ciblée. Contraintes : Utiliser la sélection state:modified+ ou slim CI. Exploiter le fichier manifest.json. Réduire les builds inutiles. Livrable attendu : Proposer une stratégie CI optimisée permettant de ne reconstruire que les modèles impactés.

Contexte : Un modèle incrémental gère des mises à jour tardives provenant de plusieurs sources. Le Problème : Des données historiques sont écrasées ou mal fusionnées lors des exécutions successives. Extrait actuel : {{ config(materialized='incremental', unique_key='id') }} La logique ne prend pas en compte les mises à jour tardives. Contraintes : Implémenter une stratégie merge robuste. Gérer les late-arriving data. Garantir idempotence et cohérence historique. Livrable attendu : Proposer une refonte incrémentale garantissant l’intégrité des données historiques même en cas de retards de chargement.

Contexte : Le projet dbt utilise plusieurs packages internes et externes. Le Problème : Une dépendance indirecte crée une boucle lors de la compilation. Extrait logique : package_a dépend de package_b package_b dépend de package_a Contraintes : Identifier la boucle via graph. Réorganiser la structure des packages. Maintenir la modularité. Livrable attendu : Proposer une refonte des dépendances éliminant toute circularité tout en conservant l’architecture modulaire.

Contexte : L’entreprise souhaite industrialiser la qualité des données avec des règles complexes multi-colonnes. Le Problème : Les tests standards dbt ne suffisent pas pour couvrir les contraintes métier avancées. Contraintes : Développer des generic tests personnalisés réutilisables. Intégrer des macros paramétrables. Centraliser les règles dans un package interne. Livrable attendu : Proposer une structure de framework de tests personnalisés permettant une validation avancée et réutilisable des modèles dbt.

Contexte : Les équipes métier calculent des indicateurs clés différemment selon les dashboards. Le Problème : L’absence de définition centralisée entraîne des incohérences. Contraintes : Définir des métriques dans dbt. Centraliser les calculs. Assurer réutilisabilité et cohérence entre modèles. Livrable attendu : Proposer une architecture utilisant dbt metrics ou équivalent pour standardiser les indicateurs clés.

Contexte : Le data warehouse contient plusieurs milliards de lignes et les builds deviennent coûteux. Le Problème : Les modèles intermédiaires sont matérialisés en table alors qu’ils pourraient être optimisés différemment. Contraintes : Identifier les modèles à matérialiser en ephemeral, view ou incremental. Réduire la consommation compute. Maintenir la cohérence analytique. Livrable attendu : Proposer une stratégie globale d’optimisation des matérialisations pour améliorer performance et coûts.

Contexte : Certaines tables transformées contiennent des données personnelles sensibles. Le Problème : Les accès ne sont pas restreints et aucun mécanisme de masquage n’est en place. Contraintes : Implémenter des vues sécurisées ou masking policies. Séparer les schémas sensibles. Respecter les exigences réglementaires. Livrable attendu : Proposer une architecture dbt intégrant contrôle d’accès et masquage des données sensibles.