dagster-expert

Concepts fondamentaux de Dagster

Brèves définitions uniquement (voir les fichiers de référence pour des exemples détaillés) :

• Asset : Objet persistant (table, fichier, modèle) produit par votre pipeline
• Component : Bloc de construction réutilisable qui génère des définitions (assets, schedules, sensors, jobs, etc.) pertinentes pour un domaine particulier.

Workflow d'intégration

Lors de l'intégration avec N'IMPORTE QUEL outil ou service externe, lisez l'index des bibliothèques d'intégration. Cet index contient des informations sur les bibliothèques d'intégration existantes et des références sur la façon de créer de nouvelles intégrations personnalisées pour les outils qui ne disposent pas de bibliothèque publiée.

Accès programmatique : CLI dg et serveur MCP Dagster Plus

Il y a deux façons d'interagir avec Dagster de manière programmatique. Choisissez selon l'endroit où le travail s'effectue :

• Le CLI dg — tout dans le projet local : ajouter des définitions, scaffolding, valider, explorer la structure du projet, et lancer les exécutions localement. Installé dans le cadre du package dagster-dg-cli. Si une commande CLI pertinente pour une tâche locale existe, tentez toujours de l'utiliser.
• Le serveur MCP Dagster Plus — interroger et gérer une organisation Dagster Plus déployée : exécutions, assets, déploiements, emplacements de code, politiques d'alerte, Issues, et métriques d'insights. Lorsqu'il est connecté, préférez ses outils aux commandes dg api équivalentes.

dg api couvre les mêmes ressources déployées que le serveur MCP depuis la ligne de commande, et reste le moyen d'accéder aux parties que le serveur n'expose pas. Avant de faire quelque chose contre un environnement Dagster Plus déployé, lisez Dagster Plus API : General — cela couvre comment choisir entre les deux et comment revenir en arrière de manière sûre.

EXPLOREZ UNIQUEMENT la structure du projet existant si c'est strictement nécessaire pour accomplir l'objectif de l'utilisateur. Dans de nombreux cas, les outils CLI existants auront une compréhension suffisante de la structure du projet, ce qui signifie que lister et lire des fichiers existants est un gaspillage et inutile.

Presque toutes les commandes dg qui retournent des informations ont un flag --json qui peut être utilisé pour obtenir les informations dans un format lisible par machine. Cela devrait être préféré à la sortie par défaut sous forme de tableau, sauf si vous montrez directement les informations à l'utilisateur.

Compatibilité UV

Les projets utilisent généralement uv pour la gestion des dépendances, et il est recommandé de l'utiliser pour les commandes dg si possible :

uv run dg list defs
uv run dg launch --assets my_asset

CRITIQUE : Toujours lire les fichiers de référence avant de répondre

NE RÉPONDEZ JAMAIS de mémoire ou en devinant les commandes CLI, les APIs, ou la syntaxe. TOUJOURS lire les fichiers de référence pertinents à partir de l'index de référence ci-dessous avant de répondre.

Pour chaque question, identifiez le ou les fichiers de référence pertinents à l'aide des descriptions de l'index, lisez-les, puis répondez en vous basant sur ce que vous avez lu.

Index de référence

<!-- BEGIN GENERATED INDEX -->

• Asset Selection Syntax — filtrer les assets par tag, group, kind, upstream, ou downstream ; AssetSelection en Python, barre de recherche UI, ou CLI
• Environment Variables — configurer les variables d'environnement dans différents environnements
• Asset Patterns — définir les assets, les dépendances, les métadonnées, les partitions, ou les définitions multi-asset
• Choosing an Automation Approach — décider entre schedules, sensors, et automation déclarative
• Schedules — automation basée sur le temps avec expressions cron
• Declarative Automation — automation centrée sur les assets basée sur les conditions utilisant AutomationCondition
• Asset Sensors — déclencher sur les événements de matérialisation d'assets
• Basic Sensors — automation pilotée par les événements avec observation de fichiers ou polling personnalisé
• Run Status Sensors — réagir au succès, l'échec, ou d'autres changements de statut d'exécution
• dg check — valider la configuration du projet ou les définitions
• create-dagster — créer un nouveau projet Dagster à partir de zéro
• dg dev — démarrer une instance Dagster de développement locale
• dg launch — matérialiser les assets ou exécuter les jobs localement
• dg list components — voir les types de composants disponibles pour le scaffolding
• dg list defs — lister ou filtrer les définitions enregistrées
• Dagster Plus API — dg api ou serveur MCP Dagster Plus, interroger ou gérer programmatiquement les ressources Dagster Plus (assets, exécutions, déploiements, emplacements de code, schedules, sensors, secrets, issues, politiques d'alerte, etc.) ; crédits Dagster, coûts de calcul ou d'entrepôt, usage, et autres métriques d'insights pour un asset, un job, ou un déploiement ; réessayer ou réexécuter une exécution échouée ou backfill ; terminer une exécution
• dg list — explorer la structure du projet (arborescence des composants, variables d'environnement, projets workspace)
• Dagster Plus CLI — dg plus, authentification Dagster Plus, configuration, et déploiement ; se connecter, définir la configuration, créer des tokens d'API, déployer du code, récupérer des variables d'environnement, gérer les manifestes dbt
• dg scaffold component — créer un type de composant personnalisé et réutilisable
• dg scaffold defs — ajouter de nouvelles définitions (assets, schedules, sensors, components) à un projet
• dg utilities — dg utils, inspecter les types de composants, rafraîchir le cache des composants state-backed
• Creating Components — construire un nouveau composant personnalisé à partir de zéro
• Designing Component Integrations — concevoir un composant qui enveloppe un service ou outil externe ; intégrations personnalisées
• Resolved Framework — définir des types de schémas YAML personnalisés utilisant Resolver, Model, ou Resolvable
• Subclassing Components — étendre un composant existant via l'héritage ; personnaliser la composante d'intégration dagster
• Template Variables — utiliser les variables de template Jinja2 dans le YAML des composants (env, dg, context, ou scopes personnalisés)
• Creating State-Backed Components — construire un composant qui récupère et met en cache l'état externe
• Using State-Backed Components — gérer les composants state-backed en production, CI/CD, ou rafraîchir l'état
• Deployment Configuration Files — build.yaml, container_context.yaml, dagster_cloud.yaml ; configuration du déploiement Dagster Plus ; configurer le registre Docker, le contexte du conteneur, la queue d'agents ; fichiers de déploiement Hybrid
• Integration libraries index for 40+ tools and technologies (dbt, Fivetran, Snowflake, AWS, etc.). — intégration, outil externe, dagster-* ; dbt, fivetran, airbyte, snowflake, bigquery, sling, aws, gcp
• Migration Guides — migration des sensors vers l'automation déclarative, migration des sensors vers automation condition

<!-- END GENERATED INDEX -->