L’intégration dagster-dbt lit le manifest.json d’un projet dbt et mappe chaque modèle vers un asset Dagster tracé avec lineage automatique, surveillance de la fraîcheur, checks de qualité et prévisualisations CI/CD par branche. Ce hub relie les notes individuelles qui couvrent l’intégration en profondeur.
Le mapping de base
Mapping des assets Dagster-dbt couvre les fondamentaux : comment le manifest.json devient un graphe d’assets Dagster, le décorateur @dbt_assets, la personnalisation avec DagsterDbtTranslator (clés, groupes, tags, métadonnées de propriété depuis meta de dbt), le filtrage des modèles qui deviennent des assets, et les deux approches de configuration du projet (Components vs traditionnel).
Le mapping est le prérequis de tout le reste de l’intégration.
Surveillance de la qualité
Asset Checks Dagster depuis les tests dbt explique comment Dagster 1.7+ convertit automatiquement chaque test dbt (not_null, unique, accepted_values, tests personnalisés, dbt-expectations) en un asset check. Le mapping de sévérité (error = bloquant, warn = non bloquant) est repris depuis la configuration dbt. Le résultat est une seule UI pour l’exécution et la qualité.
Cela se connecte aux notes plus larges sur la taxonomie des tests dbt et Elementary for dbt — Dagster expose toutes ces couches de test dans une vue unifiée.
Planification et fraîcheur
Politiques de fraîcheur et planification Dagster couvre le suivi de la fraîcheur au niveau des assets (pas seulement les timestamps d’exécution), la construction de schedules depuis la syntaxe de sélection dbt, les sensors event-driven pour la coordination cross-système, et les automation conditions. C’est là que Dagster se différencie le plus des orchestrateurs plus simples comme Cloud Run Jobs ou Cloud Workflows.
CI/CD et déploiement
Dagster Branch Deployments pour dbt décrit les environnements de prévisualisation éphémères sur les PR, la sélection basée sur l’état (comportement state:modified), l’exécution par partitions avec les modèles incrémentaux dbt, et les matérialisations sélectives pour les opérations ad hoc. Les branch deployments fournissent un diff visuel du graphe qui va au-delà de la revue de code au niveau du source.
La décision
Dagster vs dbt Cloud fournit la comparaison : ce que dbt Cloud ne peut pas faire (orchestration non-dbt, dépendances cross-système, exécution par partitions, lineage full-stack), le calcul des coûts ($10-100/mois Dagster+ vs $100-300/mois dbt Cloud pour les petites équipes), et l’argument d’indépendance vis-à-vis du vendeur après la fusion Fivetran-dbt Labs d’octobre 2025.
Rapport avec l’orchestration GCP
Le cadre de décision pour l’orchestration dbt sur GCP couvre les options natives GCP (Cloud Run Jobs, Cloud Workflows, Cloud Composer). Dagster est un axe séparé dans le paysage de l’orchestration — il n’est pas natif GCP, mais il fournit des capacités (fraîcheur au niveau des assets, lineage cross-système, orchestration Python-first) que les outils natifs GCP n’offrent pas. Les équipes exécutant dbt sur GCP peuvent utiliser :
- Cloud Run Jobs pour une exécution dbt déclenchée par cron simple (le moins cher, le plus simple)
- Dagster pour une orchestration asset-aware avec des dépendances cross-système (coût intermédiaire, le plus de capacités pour dbt spécifiquement)
- Cloud Composer pour une orchestration Airflow d’entreprise (coût le plus élevé, écosystème le plus large)
Le choix dépend de si les besoins d’orchestration vont au-delà de « exécuter dbt selon un planning ».