L’UI web Dagster se lance via dagster dev sur localhost:3000 pour le développement local, ou est hébergée sur Dagster+ pour la production. Elle traduit le modèle centré sur les assets — santé des assets, fraîcheur, lignée — en surfaces visuelles et cliquables. Cette note couvre les principales sections de l’UI et ce qu’elles signifient pour les workflows dbt + BigQuery.
Catalogue d’assets
Une liste de chaque asset dans le projet, recherchable et filtrable. C’est le point d’entrée pour la plupart des opérations quotidiennes.
Ce qu’on voit pour chaque asset :
- Historique de matérialisation (dernière exécution, durée)
- Métadonnées (description, propriétaires, tags, groupe)
- Statut de santé (matérialisé, obsolète, en échec, frais)
- Résultats des vérifications d’assets (réussi, échoué, avertissement)
- Dépendances en amont et en aval
Comment les analytics engineers l’utilisent :
- Filtrer par
group_namepour voir tous les modèles finance, tous les modèles marketing, etc. - Filtrer par
ownerspour voir les assets appartenant à l’équipe — utile pour les scénarios d’astreinte - Filtrer par tags pour voir tous les modèles tagués
dailyou tous les assets de prioritécritical - Vérifier si les données d’un modèle spécifique sont à jour avant de partager un dashboard
Pour les équipes avec des modèles dbt mappés en assets Dagster, chaque modèle du manifest.json apparaît ici avec ses métadonnées dbt (tags, propriétaires depuis meta.dagster.owners, descriptions depuis schema.yml). La documentation dbt existante sert doublement de métadonnées du catalogue Dagster.
Lignée globale des assets
Le graphe de dépendances complet de tous les assets — pas seulement les modèles dbt, mais les assets Python, les sources externes et tout autre donnée gérée par Dagster. C’est la vue de graphe qui rend visibles les dépendances cross-système.
Fonctionnalités clés :
- Superposition de facettes. Basculer entre les vues : propriétaires, statut de santé, conditions d’automatisation, type de calcul. « Quels assets appartenant à l’équipe finance sont actuellement obsolètes ? » se fait en un seul filtre.
- Visibilité cross-système. Le graphe montre les tables synchronisées par Fivetran aux côtés des modèles dbt et des assets Python. Une architecture de pipeline full-stack est visible de bout en bout.
- Repliement de groupes. Les grands projets peuvent replier les groupes d’assets pour garder le graphe gérable. Développer le groupe
financepour voir ses dépendances internes ; repliermarketingpour le traiter comme un seul nœud. - Matérialisation sélective. Cliquer sur un asset, sélectionner « Matérialiser », et optionnellement inclure ses assets en aval. C’est le pattern « corriger un modèle et cascader le rafraîchissement » que dbt Cloud supporte mais que les orchestrateurs plus simples ne permettent pas.
La vue de lignée est particulièrement puissante pour déboguer les problèmes de qualité des données. Si un dashboard en aval affiche des chiffres inattendus, on trace la lignée depuis le modèle mart à travers les intermédiaires jusqu’aux modèles base et aux sources brutes, en vérifiant les badges de santé à chaque niveau. Le problème devient visible sous forme de badge rouge ou obsolète sur l’asset spécifique où le problème est survenu.
Détails d’exécution
Quand on clique sur une exécution spécifique (une matérialisation, un job planifié ou une exécution manuelle), la page Détails d’exécution affiche :
- Diagramme de Gantt. Timing d’exécution pour chaque asset dans l’exécution. On voit le parallélisme et identifie les goulots d’étranglement. Si
int__google_ads__daily_spendprend 12 minutes tandis que tout le reste prend 30 secondes, le diagramme de Gantt le rend évident. - Journaux d’événements structurés. Chaque événement — démarrage de matérialisation, complétion, résultat de vérification, émission de métadonnées — dans l’ordre chronologique avec des données structurées. Plus riche que les journaux en texte brut car les événements sont typés et filtrables.
- Journaux de calcul. Le stdout/stderr brut de l’exécution de chaque asset. Pour les assets dbt, c’est la sortie
dbt buildavec les détails de compilation et d’exécution au niveau du modèle.
La gestion des exécutions en échec est là où l’UI se différencie des outils plus simples. Une exécution en échec montre exactement quel asset a échoué et pourquoi. La ré-exécution en un clic de seulement les assets en échec et leurs avals évite de relancer tout le pipeline. Comparer avec les Cloud Run Jobs, où un dbt build en échec signifie soit relancer tout, soit construire manuellement une commande dbt run --select.
Indicateurs de santé
Des badges colorés sur chaque asset fournissent un état de santé en un coup d’œil :
| Badge | Signification |
|---|---|
| Vert (Matérialisé) | L’asset a été matérialisé et toutes les vérifications ont réussi |
| Jaune (Obsolète) | Les dépendances en amont de l’asset ont changé depuis la dernière matérialisation |
| Rouge (En échec) | La dernière matérialisation ou vérification a échoué |
| Bleu (Frais) | L’asset respecte sa politique de fraîcheur |
| Gris (Jamais matérialisé) | L’asset existe dans le code mais n’a jamais été matérialisé |
Le système de santé est la manifestation pratique de l’orchestration centrée sur les assets. Au lieu de consulter les journaux pour déterminer si les données sont à jour, on regarde les couleurs des badges. Un dashboard avec des badges tous verts signifie que les données sont à jour et passent les vérifications de qualité. Un badge jaune sur un modèle mart signifie que les données en amont ont changé et que le mart nécessite un rafraîchissement.
Pour les analytics engineers habitués à l’interface de dbt Cloud, les badges de santé sont l’équivalent le plus proche du « statut de la dernière exécution » de dbt Cloud — mais plus riche, car ils suivent la fraîcheur et l’état des données, pas seulement le succès d’exécution.
Fonctionnalités Dagster+ Pro
L’offre Dagster+ gérée (niveau Pro) ajoute des fonctionnalités pertinentes pour les équipes d’analytics engineering sur BigQuery :
Suivi des coûts BigQuery par asset. Répond à « quels modèles coûtent le plus cher à exécuter ? » en suivant l’utilisation des slots BigQuery et les octets traités par asset. Pour les équipes pratiquant un ordonnancement conscient des coûts sur BigQuery, ce sont les données nécessaires pour identifier les modèles coûteux et les optimiser.
Lignée au niveau des colonnes. Va au-delà des dépendances au niveau des tables pour montrer quelles colonnes passent à travers quelles transformations. Si mrt__finance__revenue.total_amount semble incorrect, la lignée au niveau des colonnes montre exactement quelles colonnes en amont y contribuent et à travers quelles transformations.
Mode catalogue. Une UI simplifiée conçue pour les parties prenantes moins techniques qui ont besoin de visibilité sans l’interface d’ingénierie complète. Les chefs de produit, les analystes et les consommateurs de données peuvent parcourir le catalogue d’assets, vérifier la fraîcheur et voir les descriptions de données sans rencontrer de code Python ni de détails d’orchestration. Cela adresse le manque d’« observabilité pour les non-ingénieurs » avec lequel de nombreuses plateformes de données peinent.
Alertes. Configurer des notifications vers Slack, PagerDuty ou email quand des assets échouent, deviennent obsolètes ou violent les politiques de fraîcheur. Les alertes sont au niveau de l’asset, pas du pipeline — on est notifié à propos de l’asset spécifique qui nécessite attention, pas seulement « le job de 6h00 a échoué ».
Développement local vs production
Pendant le développement local, dagster dev lance l’UI complète sur localhost:3000 avec les assets du projet. C’est utile pour :
- Vérifier que les nouveaux modèles dbt apparaissent correctement dans le graphe d’assets
- Tester les matérialisations avant de déployer en production
- Déboguer les exécutions en échec avec accès aux journaux de calcul
- Vérifier que les vérifications d’assets depuis les tests dbt sont correctement configurées
L’UI locale est fonctionnellement identique à l’UI de production. Ce qu’on voit en local est ce qu’on verra dans Dagster+ après déploiement, moins les fonctionnalités du niveau Pro. Cela rend la boucle de feedback de développement serrée : écrire du code, lancer dagster dev, vérifier l’UI, itérer.