Les fondamentaux de Dagster pour les analytics engineers

La plupart des orchestrateurs ont été conçus pour des data engineers qui gèrent de l’infrastructure. Ils raisonnent en tâches, dépendances et tentatives de reprise. Les analytics engineers raisonnent en tables, modèles et fraîcheur des données. Cet écart est important, car choisir un orchestrateur qui ne correspond pas au mode de travail de votre équipe crée des frictions à tous les niveaux : écriture des pipelines, débogage des erreurs, intégration des nouveaux membres.

Dagster comble cet écart. Son abstraction centrale est l’asset : un objet de données persistant comme une table BigQuery ou un modèle dbt. Si vous travaillez déjà avec dbt, le modèle mental de Dagster vous semblera familier. Chaque ref() dans votre SQL devient une arête de dépendance. Chaque modèle devient un asset suivi avec lignage, historique de fraîcheur et état de santé.

Ce guide couvre ce que vous devez savoir pour évaluer et commencer à utiliser Dagster en tant qu’analytics engineer sur dbt + BigQuery + GCP.

Le modèle mental centré sur les assets

Les orchestrateurs traditionnels comme Airflow définissent quelles tâches exécuter et dans quel ordre. L’orchestrateur ne sait pas quelles données ces tâches produisent. Une exécution de tâche réussie signifie que le code s’est exécuté sans erreurs, pas que les données sont correctes ou fraîches.

Dagster inverse cette logique. Vous définissez quelles données doivent exister et comment les produire. Chaque asset est un objet de données persistant (une table BigQuery, un fichier GCS, un modèle dbt) avec une fonction Python qui le crée ou le met à jour. L’orchestrateur suit quand chaque asset a été matérialisé pour la dernière fois, s’il est frais, et si ses dépendances en amont ont changé.

Cette distinction se manifeste dans des scénarios de débogage concrets. Dans un système basé sur les tâches, “le pipeline a réussi à 8h” vous dit que les tâches se sont exécutées. Avec Dagster, vous pouvez demander : “La table mrt__finance__revenue est-elle à jour ? Quand a-t-elle été matérialisée pour la dernière fois ? Tous les assets en amont ont-ils été complétés ?” Le système connaît la réponse parce qu’il suit l’état des données, pas seulement l’état d’exécution.

Pour les analytics engineers qui raisonnent déjà en modèles dbt et dépendances ref(), c’est une correspondance naturelle. Vous définissez déjà des assets (chaque modèle produit une table). Dagster donne simplement à l’orchestrateur la connaissance de ce que vous construisez, pas seulement des commandes que vous exécutez.

Les concepts essentiels

Dagster possède plusieurs abstractions, mais les analytics engineers peuvent travailler efficacement avec seulement cinq d’entre elles.

Software-Defined Assets

La brique fondamentale. Un asset est une fonction Python décorée avec @dg.asset qui produit un objet de données persistant. Chaque asset possède une clé unique, des dépendances en amont (inférées des arguments de la fonction), et des métadonnées comme les propriétaires, les tags et les politiques de fraîcheur.

import dagster as dg

@dg.asset(
    group_name="finance",
    owners=["team:analytics"],
)
def mrt__finance__daily_revenue(
    context: dg.AssetExecutionContext,
    base__stripe__payments: pd.DataFrame,
) -> pd.DataFrame:
    """Revenu quotidien agrégé à partir des paiements Stripe."""
    return base__stripe__payments.groupby("payment_date").agg(
        total_revenue=("amount_usd", "sum")
    )

L’argument de fonction base__stripe__payments indique à Dagster que cet asset dépend d’un autre asset portant cette clé. Dagster construit automatiquement le graphe de dépendances.

Resources

Des connexions externes configurées de manière centralisée et injectées dans les assets. Un BigQueryResource, un DbtCliResource ou un client GCS sont tous des resources. Vous les définissez une fois et les interchangez entre environnements (le dev utilise un dataset de test, la prod utilise le vrai).

defs = dg.Definitions(
    assets=[mrt__finance__daily_revenue],
    resources={
        "bigquery": BigQueryResource(project="my-gcp-project"),
        "dbt": DbtCliResource(project_dir="./transform"),
    },
)

Schedules et sensors

Les schedules déclenchent des matérialisations sur des expressions cron, comme une planification de job dbt Cloud. Les sensors déclenchent des matérialisations en réponse à des événements : un nouveau fichier arrivant dans GCS, une synchronisation Fivetran terminée, ou un asset en amont qui finit sa matérialisation.

Les sensors sont là où Dagster prend l’avantage sur les approches basées sur le cron. Au lieu d’exécuter dbt selon un planning fixe en espérant que les données en amont sont arrivées, un sensor peut surveiller l’événement réel d’arrivée des données et déclencher la transformation uniquement quand il y a quelque chose de nouveau à traiter.

L’objet Definitions

Le registre de niveau supérieur qui indique à Dagster ce qui existe : tous vos assets, resources, schedules et sensors. Considérez-le comme l’équivalent du dbt_project.yml. Un objet Definitions par code location, et Dagster le lit pour construire le graphe d’assets.

Components

L’abstraction majeure la plus récente, atteignant la GA dans le cycle Dagster 1.12 (2025). Les components sont des objets YAML ou Python légers qui génèrent des assets, des checks et des schedules. Le DbtProjectComponent est l’exemple phare : pointez-le vers un projet dbt, et il génère automatiquement tous les assets depuis votre manifest.

Les components abaissent la barrière d’entrée pour les praticiens SQL-first qui préfèrent écrire du YAML plutôt que des décorateurs Python.

L’intégration dbt

Le package dagster-dbt traite les modèles dbt comme des assets de première classe, allant plus loin que l’intégration dbt de tout autre orchestrateur. 50 % des utilisateurs de Dagster Cloud utilisent dbt, le taux d’adoption le plus élevé du marché.

Comment ça fonctionne

Chaque modèle dbt, seed et snapshot devient un asset Dagster individuel. Les dépendances sont dérivées des appels ref() et source() dans votre SQL. La fonction de calcul exécute dbt build en arrière-plan. En code :

from dagster_dbt import DbtCliResource, DbtProject, dbt_assets
from pathlib import Path

my_project = DbtProject(project_dir=Path("./transform"))
my_project.prepare_if_dev()

@dbt_assets(manifest=my_project.manifest_path)
def my_dbt_assets(context, dbt: DbtCliResource):
    yield from dbt.cli(["build"], context=context).stream()

prepare_if_dev() génère le manifest.json pendant le développement local en exécutant dbt parse. En production, dagster-dbt project prepare-and-package construit le manifest au moment du déploiement.

Les tests dbt deviennent des asset checks

Depuis Dagster 1.7, les tests dbt sont automatiquement importés comme des asset checks Dagster par défaut. Chaque test de schéma et test de données apparaît dans l’interface Dagster comme un contrôle qualité attaché à l’asset concerné. Les tags de ressource dbt correspondent aux tags d’asset Dagster, et les propriétaires de groupe dbt correspondent aux propriétaires Dagster. Aucune configuration supplémentaire nécessaire.

Cela vous donne une interface unique pour l’exécution et la qualité. Au lieu de vérifier dbt Cloud pour les résultats de tests et un outil de monitoring séparé pour la santé du pipeline, tout est centralisé au même endroit.

L’approche Components

Pour les nouveaux projets en 2025+, le chemin recommandé utilise le CLI dg pour scaffolder un DbtProjectComponent :

dg scaffold defs dagster_dbt.DbtProjectComponent transform \
  --project-path ./transform

Cela crée un defs.yaml qui gère automatiquement la compilation du manifest, la mise en cache et la génération d’assets. Moins de code Python et une configuration plus déclarative.

Au-delà de dbt : le pipeline full-stack

La vraie valeur de Dagster par rapport à des approches d’orchestration plus simples se révèle quand votre pipeline s’étend au-delà de la transformation.

Un pipeline typique Dagster + dbt + BigQuery :

Ingestion : Un sensor détecte qu’une synchronisation Fivetran ou dlt est terminée
Transformation : dbt s’exécute uniquement quand les données en amont sont réellement fraîches
Traitement Python : Features ML, agrégations personnalisées ou appels API que le SQL ne peut pas gérer
Déclenchements en aval : Des sensors lancent le rafraîchissement de dashboards BI ou des exports reverse ETL

Tous ces éléments participent au même graphe de dépendances. Une seule vue de lignage des assets montre le chemin complet de la source brute au dashboard final.

Si votre équipe se contente d’exécuter dbt build selon un planning sans dépendances en amont ou en aval, un job Cloud Run sur un déclencheur cron est plus simple et moins cher. Dagster justifie sa place quand plusieurs systèmes doivent se coordonner.

L’interface Dagster

L’interface web (lancée via dagster dev sur localhost:3000) est là où Dagster se distingue le plus clairement pour les analytics engineers.

Asset Catalog : Une liste consultable et filtrable de chaque asset de votre projet. Filtrez par groupe, code location, tags ou propriétaires. Chaque asset affiche son historique de matérialisation, ses métadonnées et son état de santé.

Global Asset Lineage : Le graphe de dépendances complet à travers tous les assets, pas seulement les modèles dbt. Vous pouvez superposer des facettes (propriétaires, état de santé, conditions d’automatisation) pour répondre à des questions comme “quels assets appartenant à l’équipe finance sont actuellement obsolètes ?”

Run Details : Des diagrammes de Gantt montrant le timing d’exécution, des logs d’événements structurés et des logs de calcul. Les exécutions échouées montrent exactement quel asset a échoué et pourquoi, avec une ré-exécution en un clic des seuls assets échoués et de leurs dépendances en aval.

Indicateurs de santé : Des badges colorés (matérialisé, obsolète, échoué, frais) sur chaque asset. En un coup d’oeil, vous pouvez savoir si vos données sont à jour sans lire les logs.

Dagster+ Pro ajoute le suivi des coûts BigQuery par asset (répondant à “quels modèles coûtent le plus cher à exécuter ?”), le lignage au niveau des colonnes, et un mode catalogue conçu pour les parties prenantes moins techniques qui ont besoin de visibilité sans l’interface complète d’ingénierie.

Tarification et déploiement GCP

Le modèle de crédits

La tarification Dagster+ fonctionne par crédits, où 1 crédit équivaut à 1 matérialisation d’asset ou 1 exécution d’op :

Plan	Prix	Crédits/mois	Utilisateurs
Solo	10 $/mois	7 500	1
Starter	100 $/mois	30 000	Jusqu’à 3
Pro	Contacter les ventes	Personnalisé	Personnalisé

Le dépassement au-delà des crédits du plan coûte 0,03 $ par crédit. Le calcul serverless ajoute 0,005 $ par minute de calcul sur Solo/Starter.

Pour donner du contexte, un projet dbt avec 100 modèles exécutés quotidiennement utilise environ 3 000 crédits par mois (100 modèles x 30 jours). Le tier Solo à 10 $/mois gère cela avec de la marge. Comparez cela au dbt Cloud Starter à 100 $/utilisateur/mois ou Cloud Composer 3 démarrant autour de 377 $/mois même au repos.

La version open-source gratuite (Apache 2.0) fonctionne pour l’auto-hébergement mais ne dispose pas du RBAC, des déploiements de branches, des alertes vers des services externes, ni de la recherche dans le catalogue.

Déploiement sur GCP

Deux modes de déploiement :

Serverless : Entièrement géré par Dagster. Idéal pour les charges de travail qui orchestrent des services externes (dbt, Fivetran, BigQuery) plutôt que d’exécuter du calcul lourd. Limité à 4 CPUs par noeud.

Hybride : Dagster héberge le plan de contrôle. L’exécution se fait dans votre infrastructure via un agent Kubernetes sur GKE, utilisant le chart Helm de Dagster. L’authentification fonctionne via Workload Identity. Le stockage des exécutions et des événements va dans Cloud SQL PostgreSQL, avec GCS pour la persistance de l’I/O manager.

Pour les équipes natives GCP, le modèle Hybride sur GKE s’intègre naturellement dans une architecture de plateforme data GCP existante. Un package communautaire dagster-contrib-gcp permet également d’exécuter des runs en tant que jobs Cloud Run pour les équipes qui préfèrent le calcul serverless.

La courbe d’apprentissage

Les évaluateurs G2 signalent régulièrement une courbe d’apprentissage raide, et cette réputation est méritée. Pour les analytics engineers venant de workflows dbt purement SQL, les frictions apparaissent à des endroits spécifiques :

Maîtrise de Python requise. Vous devez être à l’aise avec les décorateurs, les type hints et la structure de projet Python. Si votre équipe n’écrit que du SQL et du Jinja, il y a une période de montée en compétence.

Surcharge conceptuelle. Le passage de “j’écris des modèles SQL” à “je définis des software-defined assets avec des resources, des I/O managers et des configs” prend du temps à intérioriser. Assets, resources, definitions, ops, jobs : le vocabulaire est vaste.

Gestion du manifest. Comprendre comment le manifest.json est généré, mis en cache et utilisé à travers les environnements déstabilise les débutants. L’approche Components réduit cette friction, mais elle existe toujours.

Surprises tarifaires. Chaque matérialisation d’asset ET chaque exécution d’op compte comme un crédit. Des matérialisations à haute fréquence ou de grands projets dbt avec beaucoup de modèles peuvent consommer des crédits plus vite que prévu. Surveillez votre consommation dès le début.

Le meilleur parcours d’intégration : Dagster University propose des cours gratuits couvrant les essentiels de Dagster, Dagster & dbt, les tests et l’ingestion de données. L’étude de cas Erewhon est encourageante : une équipe data d’une seule personne avec un profil non technique a construit une plateforme data complète en utilisant Dagster University, YouTube et ChatGPT. La courbe d’apprentissage est raide mais pas insurmontable.

Est-ce adapté à votre équipe ?

Dagster convient le mieux quand votre équipe est centrée sur dbt, que votre pipeline s’étend au-delà de la transformation (ingestion, traitement Python, rafraîchissement BI), et que vous avez besoin d’un lignage au niveau des assets sur l’ensemble de la stack. Les équipes de 2 à 15 analytics engineers en tirent le plus de valeur.

Envisagez des alternatives quand :

Vous ne faites qu’exécuter dbt selon un planning sans dépendances en amont ou en aval. Un déclencheur cron sur Cloud Run coûte 0-3 $/mois et ne nécessite aucun nouvel outillage.
Vous avez besoin de l’écosystème d’intégrations le plus large. Les 90+ packages de providers d’Airflow couvrent plus de services que toute alternative.
La rapidité de mise en place compte le plus. Prefect permet d’orchestrer des fonctions Python avec moins de surcharge framework, bien que son intégration dbt soit plus opérationnelle que sémantique.
Votre organisation utilise déjà Airflow à grande échelle. Airflow 3.0 a ajouté son propre décorateur @asset, et le package astronomer-cosmos fournit une intégration dbt solide. La migration peut ne pas être justifiée.

Le bon moment pour adopter Dagster est quand vous avez 5+ sources de données interconnectées, des besoins de collaboration inter-équipes, des engagements SLA sur la fraîcheur des données, ou des exigences de planification événementielle. En dessous de ce seuil, des approches plus simples fonctionnent bien et vous permettent d’investir votre budget de complexité ailleurs. Pour une vue d’ensemble de la position de Dagster sur le marché actuel, consultez mon panorama de l’orchestration en 2026.