Architecture de pipeline full-stack Dagster

Le modèle centré sur les assets de Dagster est le plus utile quand le pipeline s’étend au-delà de la transformation — couvrant l’ingestion en amont, le traitement en aval et la coordination inter-systèmes dans un seul graphe de dépendances.

Le pattern full-stack typique

Un pipeline Dagster + dbt + BigQuery ressemble typiquement à ceci :

Ingestion : un capteur détecte qu’une synchronisation Fivetran ou dlt s’est terminée
Transformation : dbt s’exécute uniquement quand les données en amont sont effectivement fraîches
Traitement Python : fonctionnalités ML, agrégations personnalisées ou appels API que SQL ne peut pas gérer
Déclenchements en aval : des capteurs démarrent les rafraîchissements de dashboards BI ou les exports reverse ETL

Les quatre étapes sont des Assets Software-Définis dans le même graphe. Une seule vue de lignée montre le chemin complet depuis la source brute jusqu’au dashboard final. Quand quelque chose casse, on trace la lignée pour trouver la cause racine — que ce soit dans la couche d’extraction, de transformation ou de traitement en aval.

Sans orchestrateur unifié

Sans orchestrateur unifié, chaque outil rapporte le succès indépendamment :

Fivetran a son propre dashboard montrant l’état des synchronisations
dbt Cloud a son propre dashboard montrant les exécutions de modèles
Un script Python tourne sur un timer cron indépendamment des données en amont
Un appel API Looker rafraîchit un dashboard indépendamment du script Python

La corrélation entre systèmes est manuelle. Le mode de défaillance est silencieux : un script s’exécute, traite des données obsolètes, et écrit dans la table en aval sans que personne ne le détecte.

Dagster fournit un graphe de dépendances unique où le capteur qui surveille la complétion de Fivetran déclenche la transformation dbt, qui déclenche le traitement Python, qui déclenche le rafraîchissement BI. Chaque étape ne s’exécute que quand les données en amont sont confirmées fraîches.

Ingestion : capteurs et assets externes

La couche d’ingestion utilise typiquement des assets externes et des capteurs. Un asset externe représente des données que Dagster ne produit pas mais suit — une table gérée par Fivetran, un fichier arrivant dans GCS, ou des données provenant d’un flux partenaire :

import dagster as dg

# Asset externe : Dagster le suit mais ne le produit pas
fivetran_stripe_payments = dg.AssetSpec(
    "raw__stripe__payments",
    group_name="ingestion",
    description="Paiements Stripe synchronisés par Fivetran",
)

Un capteur surveille les changements sur les assets externes et déclenche les matérialisations en aval :

@dg.sensor(minimum_interval_seconds=300)
def fivetran_sync_sensor(context):
    if fivetran_sync_completed("stripe_payments"):
        yield dg.SensorResult(
            asset_events=[
                dg.AssetMaterialization(asset_key="raw__stripe__payments")
            ]
        )

Quand le capteur se déclenche, Dagster enregistre que raw__stripe__payments dispose de nouvelles données. Tout asset qui en dépend — les modèles base dbt, les étapes de traitement Python — devient éligible à la rematérialisation en fonction de ses conditions d’automatisation ou politiques de fraîcheur.

Pour les équipes utilisant une stratégie d’ingestion hybride avec certains connecteurs gérés (Fivetran) et certains pipelines personnalisés (dlt), Dagster unifie les deux. Les tables synchronisées par Fivetran et les tables chargées par dlt apparaissent comme des assets dans le même graphe, avec les transformations dbt en aval des deux.

Transformation : dbt comme couche intermédiaire

L’intégration dbt gère la couche de transformation. Chaque modèle dbt devient un asset dont les dépendances sont inférées à partir des appels ref(). Les tests dbt deviennent des vérifications d’assets. La couche dbt se trouve au milieu du graphe full-stack, consommant les assets d’ingestion et produisant des assets que le traitement en aval consomme.

Le bénéfice clé à cette couche est l’exécution conditionnelle. dbt ne s’exécute que quand les données en amont sont fraîches. Au lieu d’exécuter dbt build sur un timer cron à 6h00 en espérant que Fivetran a terminé avant, un capteur confirme que les données brutes sont arrivées, et seulement alors déclenche la transformation dbt. Plus d’exécutions incrémentielles vides ni de données partielles dans les tables en aval.

Traitement Python : des assets au-delà du SQL

L’étape que SQL ne peut pas gérer est là où les SDA Python comblent le manque :

@dg.asset(
    group_name="ml_features",
    deps=["mrt__marketing__campaign_performance"],
)
def ml__campaign_propensity_scores(
    context: dg.AssetExecutionContext,
    bigquery: BigQueryResource,
) -> None:
    """Scorer les campagnes avec le modèle de propension."""
    client = bigquery.get_client()
    df = client.query(
        "SELECT * FROM analytics.mrt__marketing__campaign_performance"
    ).to_dataframe()

    scores = run_propensity_model(df)

    # Réécriture dans BigQuery
    scores.to_gbq(
        "analytics.ml__campaign_propensity_scores",
        project_id="my-gcp-project",
        if_exists="replace",
    )

Cet asset vit dans le même graphe de dépendances que les modèles dbt. Il dépend du modèle mart dbt mrt__marketing__campaign_performance, et les assets en aval peuvent en dépendre. Le graphe de lignée montre la chaîne complète : synchronisation Fivetran → modèles base dbt → modèles intermédiaires dbt → modèles mart dbt → scoring ML Python → consommation en aval.

Patterns courants de traitement Python qui justifient l’approche full-stack :

Feature engineering ML nécessitant des bibliothèques Python (scikit-learn, XGBoost)
Appels API vers des services externes (géocodage, enrichissement, notifications)
Génération de fichiers (rapports PDF, exports CSV vers SFTP)
Agrégations personnalisées impliquant des algorithmes que SQL exprime mal
Reverse ETL poussant des données de BigQuery vers des outils SaaS

Déclenchements en aval

La dernière étape utilise des capteurs ou des conditions d’automatisation pour déclencher des actions quand les assets en amont sont frais :

Rafraîchir un dashboard Looker ou un cache de Semantic Layer dbt
Pousser des données vers un CRM via reverse ETL
Envoyer une notification Slack indiquant que des données fraîches sont disponibles
Déclencher un pipeline de reporting externe

Ces déclenchements en aval complètent la boucle. Le pipeline ne se contente pas de produire des données — il s’assure que les données atteignent leurs consommateurs.

Quand le full-stack n’est pas nécessaire

Si l’équipe exécute uniquement dbt build selon un calendrier sans dépendances en amont ou en aval, un Cloud Run job sur un trigger cron est plus simple et moins coûteux.

La comparaison Dagster vs dbt Cloud couvre cette décision en détail, et le cadre d’orchestration GCP positionne Dagster par rapport aux Cloud Run Jobs, Cloud Workflows et Cloud Composer.