Dagster est un orchestrateur centré sur les assets construit autour du concept d’assets software-définis — des objets de données qui existent dans le monde réel, suivis dans le temps avec des métadonnées de lignée et de fraîcheur. Ce hub connecte les notes individuelles couvrant les concepts de base de Dagster, son déploiement et les considérations d’adoption pour les analytics engineers sur dbt + BigQuery + GCP.
Le modèle de base
Orchestration centrée sur les assets explique le changement de paradigme : passer d’une orchestration basée sur les tâches (quoi exécuter) à une orchestration basée sur les assets (quelles données doivent exister). C’est le concept fondateur. Si on ne lit qu’une seule note, c’est celle-ci — tout le reste dans Dagster est construit sur cette distinction.
Assets Software-Définis Dagster couvre le bloc de construction central : le décorateur @dg.asset, l’inférence automatique des dépendances à partir des arguments de fonction, l’objet Definitions, et comment les SDA se comparent aux tâches Airflow. Les modèles dbt sont déjà des SDA conceptuellement ; Dagster le rend explicite.
Configuration et abstractions
Ressources Dagster couvre les connexions externes centralisées (BigQueryResource, DbtCliResource, clients GCS) et le pattern d’injection de dépendances qui permet de changer d’environnement sans modifier le code des assets.
Composants Dagster couvre la dernière abstraction majeure : des objets configurés en YAML qui génèrent des assets, des vérifications et des schedules. Le DbtProjectComponent est l’exemple phare, et les Composants sont le chemin recommandé pour les nouveaux projets en 2025+.
L’intégration dbt
Le Hub intégration Dagster + dbt couvre l’intégration spécifique à dbt en profondeur :
- Mapping d’assets Dagster-dbt — comment
manifest.jsondevient des assets - Vérifications d’assets Dagster issues des tests dbt — surveillance automatique de la qualité
- Politiques de fraîcheur et ordonnancement Dagster — schedules, capteurs, conditions d’automatisation
- Déploiements de branches Dagster pour dbt — CI/CD avec aperçus de branches
Au-delà de dbt
Architecture de pipeline full-stack Dagster couvre le pattern qui justifie Dagster par rapport aux outils plus simples : unifier l’ingestion, la transformation, le traitement Python et les déclenchements en aval dans un seul graphe d’assets. C’est là que la valeur de Dagster se montre le plus clairement.
L’interface
UI Dagster pour les analytics engineers parcourt l’UI web : Catalogue d’assets, Lignée globale des assets, Détails d’exécution, indicateurs de santé, et les fonctionnalités Dagster+ Pro (suivi des coûts BigQuery, lignée au niveau des colonnes, mode catalogue).
Déploiement et coût
Tarification Dagster+ et modèle de crédits explique le modèle de crédits (1 crédit = 1 matérialisation), les niveaux de plans, les coûts de dépassement, et les comparaisons avec dbt Cloud et Cloud Composer.
Déploiement GCP Dagster couvre les modes Serverless vs Hybrid, GKE avec Helm, l’authentification Workload Identity, Cloud SQL pour le stockage, et l’option Cloud Run communautaire.
Adoption
Courbe d’apprentissage Dagster pour les analytics engineers couvre les points de friction : maîtrise de Python, surcharge conceptuelle, gestion du manifest, surprises tarifaires, et le meilleur chemin d’onboarding via Dagster University.
Dagster vs orchestration dbt Cloud fournit la comparaison pour les équipes qui décident entre Dagster et le planificateur intégré de dbt Cloud.
Facteurs de décision
Dagster convient aux équipes centrées sur dbt dont les pipelines s’étendent au-delà de la transformation et qui ont besoin d’une lignée au niveau des assets sur toute la stack. Alternatives :
- Exécuter uniquement dbt selon un calendrier → Cloud Run Jobs
- Écosystème d’intégrations le plus large → Airflow
- Surcharge de configuration minimale → Prefect
Le cadre de décision d’orchestration GCP couvre l’ensemble du paysage.