Vérifications d'assets Dagster issues des tests dbt

Depuis Dagster 1.7, les tests dbt sont automatiquement importés comme vérifications d’assets. Chaque not_null, unique, accepted_values et test de données personnalisé apparaît dans l’UI Dagster comme une vérification de qualité attachée à l’asset concerné. Aucune configuration supplémentaire n’est nécessaire au-delà du mapping dagster-dbt standard.

C’est significatif car cela signifie que la suite de tests dbt existante — celle déjà maintenue dans les fichiers schema.yml — devient automatiquement la couche de surveillance de qualité Dagster. Il n’est plus nécessaire de définir les vérifications de qualité à deux endroits.

Comment cela fonctionne en pratique

Quand on matérialise un modèle dbt via Dagster, ses tests s’exécutent dans le cadre de la commande dbt build. Dans l’UI Dagster, chaque asset affiche un badge de santé :

• Vert signifie que l’asset a été matérialisé et que toutes les vérifications ont réussi.
• Rouge signifie qu’une vérification a échoué. On peut cliquer pour voir exactement quel test a échoué et pourquoi.

La boucle de feedback est immédiate : matérialisation, test, rapport — tout en une seule opération, visible dans une seule UI.

Tests de schéma vs tests de données

Les tests de schéma et les tests de données se comportent légèrement différemment dans la façon dont ils s’attachent aux assets.

Les tests de schéma — comme not_null sur une colonne ou unique sur une clé primaire — s’attachent au modèle spécifique qu’ils testent. C’est simple : un test not_null sur mrt__finance__orders.order_id devient une vérification sur l’asset mrt__finance__orders.

Les tests de données génériques qui référencent plusieurs modèles s’attachent au modèle principal. Si on a un test relationships validant que mrt__finance__orders.customer_id référence mrt__core__customers.customer_id, la vérification s’attache à mrt__finance__orders (le modèle où le test est déclaré).

Pour les équipes utilisant des tests génériques personnalisés ou des tests provenant de packages comme dbt-utils et dbt-expectations, le même mapping s’applique. Tout test que dbt reconnaît dans manifest.json devient une vérification d’asset Dagster.

Mapping des niveaux de sévérité

On peut configurer la sévérité des vérifications via la configuration severity existante de dbt, qui correspond directement au comportement de vérification Dagster :

• Un test avec severity: error correspond à une vérification bloquante dans Dagster. En cas d’échec, les matérialisations en aval sont bloquées. C’est le comportement par défaut.
• Un test avec severity: warn correspond à une vérification non bloquante. L’avertissement apparaît dans l’UI, mais les assets en aval peuvent toujours être matérialisés.

models:
  - name: mrt__marketing__daily_spend
    columns:
      - name: spend_amount
        data_tests:
          - not_null:
              severity: error    # Bloque l'aval si une dépense NULL est trouvée
          - dbt_expectations.expect_column_values_to_be_between:
              min_value: 0
              max_value: 1000000
              severity: warn     # Avertit mais ne bloque pas

Cela correspond à la distinction vérification bloquante vs non bloquante de Dagster, donc la configuration de test dbt existante est transposée sans modifications.

Ce que cela remplace

Pour les équipes utilisant déjà des stratégies de test dbt, l’intégration Dagster signifie une seule UI pour l’exécution et la qualité. Plus besoin de vérifier dbt Cloud pour les résultats de tests et un outil séparé pour la santé du pipeline. Plus besoin de corréler les horodatages entre différents systèmes pour déterminer si un échec de test s’est produit avant ou après une matérialisation particulière.

Le modèle de vérification d’asset change également la façon de penser les échecs de tests. Dans dbt standalone, un échec de test est journalisé dans la sortie CLI et peut-être rapporté sur un canal Slack. Dans Dagster, un échec de test est visible sur l’asset lui-même, dans le contexte de sa lignée. On voit d’un coup d’œil quels assets en aval sont affectés par une vérification en échec, et si l’échec est bloquant ou simplement un avertissement.

La stack de qualité en couches

Les vérifications d’assets issues des tests dbt forment une couche d’une approche de surveillance de qualité plus large :

Dagster se trouve au sommet de cette stack comme la vue unifiée. Il ne remplace pas la détection d’anomalies d’Elementary ni le framework de tests dbt — il les fait tous remonter au même endroit avec un seul modèle d’exécution.

Considérations pratiques

Surcharge d’exécution des tests

Comme les tests s’exécutent dans le cadre de dbt build, ils s’ajoutent à la durée totale de matérialisation. Pour les modèles avec de nombreux tests (10+ par modèle), cela peut allonger significativement la durée de construction. L’approche standard : garder les tests de sévérité erreur légers (clés primaires, not-null sur les colonnes critiques) et utiliser la sévérité warn pour les tests statistiques coûteux qui n’ont pas besoin de bloquer le traitement en aval.

Les tests unitaires sont différents

Les tests unitaires dbt (dbt 1.8+) valident la logique de transformation avec des entrées simulées. Ils ne correspondent pas aux vérifications d’assets car ils ne s’exécutent pas contre des données réelles — ils s’exécutent contre des fixtures simulées. Exclure les tests unitaires des exécutions en production (dbt build --exclude-resource-type unit_test). Ils appartiennent à la CI et au développement local, pas à l’exécution en production Dagster.

Vérifications d’assets personnalisées au-delà de dbt

Dagster prend également en charge la définition de vérifications d’assets en Python, indépendamment de dbt. C’est utile pour des vérifications de qualité qui couvrent plusieurs modèles dbt ou impliquent une logique difficile à exprimer en SQL. Par exemple, vérifier que le nombre de lignes dans un modèle mart est dans une plage attendue par rapport à son modèle intermédiaire en amont, ou valider que deux modèles — un généré par Python et un dbt — s’accordent sur les valeurs agrégées.

from dagster import asset_check, AssetCheckResult

@asset_check(asset=my_dbt_assets)
def check_row_count_reasonable(context):
    # Logique de validation personnalisée en Python
    row_count = get_row_count("mrt__finance__orders")
    return AssetCheckResult(
        passed=row_count > 0,
        metadata={"row_count": row_count},
    )

Ces vérifications définies en Python apparaissent aux côtés des vérifications originaires de dbt dans la même UI, donnant un tableau de bord de qualité unique quelle que soit la localisation de la logique de vérification.

Pour les équipes migrant de dbt Cloud vers Dagster, la suite de tests existante — unique et not_null sur les clés primaires, tests relationships sur les clés étrangères, vérifications de plages dbt-expectations — se transfère sans modification. Les résultats de tests qui vivaient auparavant dans les journaux dbt, les rapports Elementary et la sortie CI apparaissent comme des métadonnées de première classe sur les assets eux-mêmes. Le seul changement est l’endroit où les résultats sont consultés.