Assets Software-Définis Dagster

Un Asset Software-Défini (SDA) est le bloc de construction central de Dagster. C’est une fonction Python décorée avec @dg.asset qui produit un objet de données persistant — une table BigQuery, un fichier GCS, un DataFrame Pandas, un modèle dbt. Chaque asset a une clé unique, des dépendances en amont inférées depuis les arguments de fonction, et des métadonnées comme les propriétaires, les tags et les politiques de fraîcheur.

La partie « software-défini » signifie que la définition de l’asset (ce qu’il est, de quoi il dépend, qui le possède, quelle fraîcheur il devrait avoir) vit dans le code aux côtés de la logique qui le produit. C’est le même principe que les modèles dbt : le SQL qui crée une table et le YAML qui la décrit cohabitent dans le contrôle de version.

Le pattern de base

import dagster as dg
import pandas as pd

@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")
    )

Trois choses se passent dans cette définition :

1. Le nom de la fonction devient la clé de l’asset. mrt__finance__daily_revenue est la façon dont cet asset est identifié partout dans Dagster — l’UI, le graphe de lignée, les schedules, les capteurs.

2. Les arguments de fonction déclarent les dépendances. L’argument base__stripe__payments dit à Dagster que cet asset dépend d’un autre asset avec cette clé. Dagster construit le graphe de dépendances automatiquement — pas de définition explicite de DAG, pas de configuration depends_on. Si on ajoute un nouvel argument, le graphe se met à jour.

3. Les métadonnées sont déclaratives. group_name organise les assets dans l’UI. owners permet le filtrage par équipe. La docstring devient la description de l’asset dans le catalogue d’assets.

Cette inférence automatique des dépendances est le mécanisme qui rend le modèle centré sur les assets de Dagster pratique. On déclare ce dont chaque asset a besoin (ses arguments de fonction) et ce qu’il produit (sa valeur de retour), et l’orchestrateur résout le reste.

L’objet Definitions

L’objet Definitions est le registre de niveau supérieur qui dit à Dagster ce qui existe : tous les assets, les ressources, les schedules et les capteurs. Penser à lui comme l’équivalent de dbt_project.yml — un objet Definitions par emplacement de code, et Dagster le lit pour construire le graphe d’assets.

import dagster as dg

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

Tout ce que Dagster sait du projet provient de ce qui est enregistré dans Definitions. Les assets non listés n’apparaissent pas dans l’UI. Les ressources non listées ne peuvent pas être injectées dans les assets. C’est la source de vérité unique pour l’emplacement de code Dagster.

Pour les projets dbt, l’intégration dagster-dbt génère automatiquement des assets depuis le manifest, et ces assets générés sont enregistrés dans Definitions aux côtés de tous les assets Python définis.

Comment les SDA diffèrent des tâches Airflow

La comparaison clarifie ce que les SDA fournissent que les primitives d’orchestrateur traditionnelles n’offrent pas :

La différence clé est qu’une tâche Airflow est éphémère — elle s’exécute et produit un effet de bord. Un SDA Dagster est persistant — il représente un objet de données qui existe dans le monde réel, et Dagster suit l’état de cet objet dans le temps.

Métadonnées et configuration des assets

Les SDA supportent des métadonnées riches qui pilotent le comportement dans l’UI et la couche d’orchestration :

@dg.asset(
    group_name="marketing",
    owners=["team:growth", "adrienne@example.com"],
    tags={"priority": "high", "domain": "marketing"},
    description="Performance des campagnes agrégée quotidiennement depuis Google Ads et Meta Ads.",
    automation_condition=dg.AutomationCondition.eager(),
)
def mrt__marketing__campaign_performance(
    context: dg.AssetExecutionContext,
    int__google_ads__daily_spend: pd.DataFrame,
    int__meta_ads__daily_spend: pd.DataFrame,
) -> pd.DataFrame:
    ...

• owners apparaît dans le catalogue d’assets et les vues de lignée. Filtrer par propriétaire pour voir « quels assets possède l’équipe growth ? » Utile pour le routage des astreintes et la responsabilisation.
• tags permettent le filtrage et le regroupement. Tagger les assets par domaine, priorité ou toute dimension utile à l’équipe.
• automation_condition déclare quand l’asset doit être rematérialisé — lors d’un changement en amont, selon un calendrier cron, ou lors d’une violation de fraîcheur. Remplace les définitions explicites de schedule ou capteur pour de nombreux cas d’usage.
• group_name organise les assets visuellement. Les groupes se replient dans le graphe de lignée, gardant la vue gérable pour les grands projets.

Définitions multi-assets

Quand plusieurs assets partagent le même calcul (courant dans dbt, où dbt build produit de nombreuses tables en même temps), Dagster supporte les définitions multi-assets :

@dg.multi_asset(
    outs={
        "raw__events": dg.AssetOut(),
        "raw__users": dg.AssetOut(),
    }
)
def extract_from_api(context):
    """Extraire les événements et les utilisateurs de l'API en un seul appel."""
    data = call_api()
    return data["events"], data["users"]

Le [[fr/mapping-assets-dagster-dbt|décorateur @dbt_assets]] est une définition multi-asset sous le capot. Il lit le manifest et produit un asset par modèle dbt, depuis une seule fonction qui exécute dbt build.

SDA et modèles dbt

Pour les analytics engineers, la chose la plus importante à propos des SDA est que les modèles dbt sont déjà des SDA conceptuellement. Chaque modèle produit une table (l’asset), déclare ses dépendances via ref(), et dispose de métadonnées dans schema.yml. L’intégration dagster-dbt rend simplement cela explicite à l’orchestrateur.

Là où les SDA Python vont au-delà de dbt, c’est dans les étapes que le SQL ne peut pas gérer : appels API, feature engineering ML, traitement de fichiers, déclenchements de systèmes externes. Une architecture de pipeline full-stack peut avoir des SDA Python pour l’ingestion, des SDA dbt pour la transformation, et davantage de SDA Python pour le traitement en aval — tous dans le même graphe de dépendances.

Considérations d’apprentissage

Les SDA nécessitent d’être à l’aise avec les décorateurs Python, les annotations de type et les signatures de fonctions. Les patterns sont cohérents : @dg.asset pour les assets individuels, les arguments de fonction pour les dépendances, Definitions pour l’enregistrement. Pour les équipes qui n’écrivent que du SQL et du Jinja, se familiariser avec la structure de projet Python est la principale friction. Voir Courbe d’apprentissage Dagster pour les analytics engineers.

L’abstraction Components déplace la définition des assets vers YAML, réduisant la barrière Python au prix de la flexibilité de personnalisation.