Dagster Components

Les Components constituent la nouvelle abstraction majeure de Dagster, disponible en GA depuis le cycle 1.12 (2025). Ce sont des objets configurés en YAML ou en Python léger qui génèrent des assets, des checks et des schedules. L’objectif est de réduire le boilerplate Python pour les patterns courants, notamment l’intégration dbt.

Pour les équipes d’analytics engineering qui préfèrent YAML à Python, les Components constituent le chemin de démarrage recommandé pour les nouveaux projets Dagster en 2025+.

Le problème que résolvent les Components

La configuration Dagster traditionnelle pour un projet dbt nécessite d’écrire du Python :

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()

Ce n’est pas beaucoup de code, mais cela nécessite de comprendre les décorateurs Python, les générateurs (yield from), l’injection de ressources et le cycle de vie DbtProject/manifest. Pour un analytics engineer dont la compétence principale est SQL, chacun de ces concepts représente un obstacle.

Les Components remplacent tout cela par un fichier YAML :

type: dagster_dbt.DbtProjectComponent
params:
  project_dir: ./transform

Même résultat — chaque modèle dbt devient un asset Dagster tracé avec lineage automatique, politiques de fraîcheur et checks de qualité. Mais le point d’entrée est un fichier de configuration, pas un module Python.

Scaffolding avec le CLI dg

Le CLI dg est l’outil complémentaire des Components. Il structure le projet et crée le fichier defs.yaml qui définit les components :

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

Cette commande crée :

1. Un defs.yaml dans le répertoire transform/ avec la configuration du component.
2. La compilation et le cache automatiques du manifest — le component gère prepare_if_dev() en interne.
3. La génération d’assets à partir du manifest dbt, identique à ce que produit le décorateur @dbt_assets.

Pour les nouveaux projets démarrant en 2025+, c’est le chemin de configuration recommandé. Le mapping dbt-vers-Dagster complet est obtenu avec moins de friction.

DbtProjectComponent en détail

Le DbtProjectComponent est le component phare et celui que la plupart des analytics engineers rencontreront en premier. Il encapsule l’ensemble de l’intégration dbt :

type: dagster_dbt.DbtProjectComponent
params:
  project_dir: ./transform
  dbt:
    target: prod
    profiles_dir: ./transform
  asset_attributes:
    group_name: dbt_models
  schedule:
    cron: "0 6 * * *"
    selection: "tag:daily"

Ce bloc YAML unique :

• Pointe sur le répertoire du projet dbt
• Configure le DbtCliResource avec les paramètres de target et de profil
• Définit un nom de groupe par défaut pour tous les assets générés
• Crée un schedule qui exécute les modèles tagués daily à 6h du matin

Le code Python équivalent s’étendrait sur 20 à 30 lignes dans plusieurs fichiers. Pour les équipes qui souhaitent le mapping sans personnalisation approfondie, l’approche YAML est plus rapide à mettre en place et plus facile à maintenir.

Au-delà de dbt

Les Components ne se limitent pas à dbt. L’architecture est extensible — tout pattern courant qui génère des assets à partir de la configuration peut devenir un component :

• Les syncs Fivetran comme components générant un asset par connecteur
• Les pipelines dlt comme components générant des assets à partir des définitions de pipeline
• Les scripts Python comme components légers avec des entrées et sorties définies en YAML

Le modèle de components suit la même philosophie que dbt lui-même : convention plutôt que configuration, YAML pour le cas courant, retour au code quand la personnalisation est nécessaire. Si le pipeline est suffisamment standard pour être décrit en YAML, les Components évitent d’écrire du Python. Quand une logique personnalisée est nécessaire — une surcharge de DagsterDbtTranslator, un sensor complexe, une étape de traitement Python — on redescend vers l’approche traditionnelle basée sur les décorateurs décrite dans la note sur les SDAs.

Components vs configuration traditionnelle

Le compromis est entre flexibilité et simplicité. Les Components sont intentionnellement opiniâtres — ils rendent le cas courant facile et le cas particulier plus difficile. Si des filtres sur les modèles devenant des assets sont nécessaires, si la façon dont les clés d’asset sont dérivées des noms de modèles doit être personnalisée, ou si des métadonnées personnalisées issues de la config meta de dbt doivent être injectées, l’approche Python traditionnelle donne un contrôle total.

Chemin recommandé

Pour les nouveaux projets :

1. Commencer avec les Components — dg scaffold permet d’avoir un projet fonctionnel avec un minimum de code.
2. Ajouter de la personnalisation Python quand les paramètres YAML des Components ne couvrent pas le besoin. Les deux approches coexistent : les components dbt définis en YAML et les assets personnalisés définis en Python peuvent partager le même objet Definitions.
3. Utiliser la configuration traditionnelle si une personnalisation approfondie est nécessaire dès le départ (translators personnalisés, filtrage complexe, configurations multi-projets).

La courbe d’apprentissage est plus progressive avec cette progression car la complexité Python est abordée de façon incrémentale.