Profondeur d'intégration dbt selon les orchestrateurs

Dagster, Airflow et Prefect ont tous des intégrations dbt. La profondeur varie entre eux. La distinction : quand un modèle dbt échoue, l’orchestrateur voit-il une tâche échouée, ou voit-il une table obsolète avec un impact en aval sur des SLA de fraîcheur spécifiques ?

dagster-dbt : Mapping d’assets de première classe

Le package dagster-dbt lit le manifest.json de votre projet et crée un asset Dagster par modèle dbt, seed et snapshot. Les dépendances issues des appels ref() et source() deviennent des arêtes dans le graphe d’assets. Les tests dbt deviennent automatiquement des checks d’assets Dagster. Les propriétaires, tags et métadonnées de colonnes se transfèrent depuis votre configuration schema.yml.

L’évaluation sur 30 critères de FreeAgent l’a bien dit : « Quelques lignes de code et vous pouvez avoir une carte complète des assets de vos modèles dbt. »

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

Cette configuration minimale vous donne le catalogue d’assets complet. Chaque modèle dbt apparaît dans l’interface Dagster avec les dépendances amont et aval visualisées, l’historique de matérialisation suivi et la fraîcheur monitorée. La note sur le mapping d’assets couvre les détails : personnalisation de DagsterDbtTranslator, gestion du manifest, filtrage et les deux chemins de configuration du projet.

La différence pratique apparaît dans les scénarios d’échec. Quand mrt__finance__monthly_revenue échoue dans Dagster, vous voyez :

• De quels modèles amont il dépend et s’ils sont frais
• Quels assets en aval sont désormais obsolètes à cause de cet échec
• Quels SLA de fraîcheur sont à risque
• Si l’échec est dans le SQL du modèle ou dans un check de qualité des données
• Le contexte complet de lignage, y compris les assets non-dbt (ingestion Python, modèles ML, rafraîchissement BI)

La moitié de tous les utilisateurs de Dagster Cloud utilisent dbt — le taux d’adoption de dbt le plus élevé de tous les orchestrateurs.

astronomer-cosmos : Wrapping de tâches Airflow

astronomer-cosmos (plus de 21 M de téléchargements mensuels, plus de 140 contributeurs) transforme les projets dbt en DAGs ou TaskGroups Airflow. Chaque modèle dbt devient une tâche Airflow individuelle avec des retries et des notifications d’erreur. La configuration est similairement concise :

from cosmos import DbtDag, ProjectConfig, ProfileConfig, ExecutionConfig

my_dbt_dag = DbtDag(
    project_config=ProjectConfig("/path/to/dbt/project"),
    profile_config=ProfileConfig(
        profile_name="my_profile",
        target_name="prod",
    ),
    execution_config=ExecutionConfig(
        dbt_executable_path="/usr/local/bin/dbt",
    ),
    schedule_interval="@daily",
    start_date=datetime(2025, 1, 1),
    dag_id="dbt_dag",
)

Cosmos fait un bon travail pour amener dbt dans le monde d’Airflow. Une dizaine de lignes de code et vous avez des modèles dbt s’exécutant comme des tâches Airflow individuelles avec l’ordonnancement des dépendances préservé. Il supporte désormais également le décorateur @asset d’Airflow 3.

Mais il encapsule dbt dans le paradigme de tâches d’Airflow plutôt que de traiter les modèles comme des objets de données de première classe. Quand un modèle échoue, vous voyez « tâche échouée » dans la vue DAG. Vous savez quel modèle a cassé, mais vous ne voyez pas automatiquement :

• Les implications de fraîcheur des données pour les consommateurs en aval
• L’impact sur le lignage inter-systèmes (cela affecte-t-il un asset Python ? une synchronisation Fivetran ?)
• L’historique de santé au niveau des assets dans le temps

Vous voyez « tâche réussie » ou « tâche échouée », pas « cette table est fraîche » ou « cette table est obsolète ». La distinction est la même différence architecturale décrite dans les philosophies architecturales des orchestrateurs : Airflow suit l’exécution des processus, Dagster suit l’état des produits de données.

Pour les équipes qui utilisent déjà Airflow pour des workloads non-dbt, cosmos est le chemin d’intégration naturel — il amène dbt dans un modèle opérationnel existant sans nécessiter une nouvelle plateforme.

prefect-dbt : Exécution opérationnelle

prefect-dbt fournit DbtCoreOperation pour exécuter des commandes CLI dbt et DbtCloudJob pour déclencher des exécutions dbt Cloud. Il génère des artefacts Markdown dans l’interface Prefect avec des liens vers les artefacts dbt.

from prefect import flow
from prefect_dbt.cli.commands import DbtCoreOperation

@flow
def run_dbt():
    result = DbtCoreOperation(
        commands=["dbt build"],
        project_dir="/path/to/dbt/project",
        profiles_dir="/path/to/profiles",
    )
    result.run()

L’intégration est opérationnelle : elle exécute bien les commandes dbt. Les retries, la journalisation et la capture d’artefacts fonctionnent comme prévu. Mais elle ne mappe pas les modèles dbt dans le modèle interne de Prefect de la même façon que dagster-dbt avec les assets. Prefect suit qu’un flow s’est exécuté et si ses tâches ont réussi ou échoué. Il ne sait pas automatiquement que mrt__finance__monthly_revenue est un produit de données avec des exigences de fraîcheur.

La force de Prefect réside dans l’orchestration des workflows environnants. Quand dbt n’est qu’une étape dans un pipeline plus large centré sur Python — extraction via API, transformations dbt, livraison en aval — le modèle orienté fonctions de Prefect gère la composition complète. La profondeur d’intégration dbt importe moins quand dbt n’est qu’une petite partie d’un flow plus large.

Le spectre de profondeur d’intégration

Les trois intégrations se situent sur un spectre allant de l’opérationnel au sémantique :

Quand la profondeur d’intégration est importante

L’écart de profondeur apparaît dans des scénarios opérationnels spécifiques :

Triage d’incidents. Un stakeholder signale qu’un tableau de bord affiche des données obsolètes. Dans Dagster, vous ouvrez le catalogue d’assets, trouvez le modèle de mart et voyez son statut de fraîcheur, sa dernière heure de matérialisation et la santé amont dans une vue. Dans Airflow, vous trouvez le DAG, vérifiez l’historique des tâches, puis remontez manuellement les DAGs amont pour trouver la cause racine. Dans Prefect, vous cherchez dans les logs du flow.

Analyse d’impact. Vous devez modifier un modèle intermédiaire partagé. Dans Dagster, le graphe d’assets montre chaque asset en aval qui en dépend, y compris les assets non-dbt. Dans Airflow, vous voyez les tâches en aval dans le même DAG mais pouvez manquer les dépendances inter-DAGs. Dans Prefect, les dépendances inter-flows ne sont pas suivies.

Monitoring de la fraîcheur. Un modèle de mart ne doit pas avoir plus de 6 heures. Dans Dagster, vous définissez une politique de fraîcheur sur l’asset et recevez des alertes en cas de violation. Dans Airflow ou Prefect, vous implémentez une logique de monitoring personnalisée en dehors de l’orchestrateur.

Pour les équipes dont le workload principal est constitué de transformations dbt, vous ressentirez cet écart chaque fois que quelque chose casse. Si dbt n’est qu’une petite partie d’un pipeline plus large centré sur Python, la profondeur d’intégration devient moins déterminante — la valeur de l’orchestrateur réside dans la coordination du workflow complet, pas dans une connaissance approfondie de dbt.

Convergence

Le décorateur @asset d’Airflow 3.0 et le support de cosmos pour celui-ci indiquent un mouvement vers la conscience des données dans les outils orientés tâches. Si cela atteint la parité avec la profondeur de dagster-dbt est une question ouverte — la différence architecturale (les assets comme abstraction fondamentale versus les assets ajoutés comme couche) peut contraindre jusqu’où Airflow peut aller sans une rearchitecture plus profonde.

Pour les équipes qui choisissent aujourd’hui : si le pipeline est composé à 80 % de transformations dbt, la profondeur de dagster-dbt est pertinente. Si dbt représente 20 % d’un pipeline hétérogène, les capacités plus larges de l’orchestrateur l’emportent sur la profondeur spécifique à dbt.