- Créer et utiliser un artefact W&B.
- Utiliser et créer des Registered Models dans W&B Registry.
- Exécuter des tâches d’entraînement sur une infrastructure dédiée à l’aide de W&B Launch.
- Utiliser le client wandb dans les ops et les assets.
wandb_resource: une ressource Dagster utilisée pour s’authentifier auprès de l’API W&B et communiquer avec elle.wandb_artifacts_io_manager: un IO Manager Dagster utilisé pour consommer des artefacts W&B.
Avant de commencer
- Clé API W&B.
- entité W&B : le nom de votre équipe W&B.
- projet W&B : le nom du projet dans lequel les W&B Runs sont stockés.
Configurer votre clé API
- Connectez-vous à W&B. Si vous utilisez W&B Server, demandez à votre administrateur le nom d’hôte de l’instance.
- Créez une clé API dans les Paramètres utilisateur. Pour un environnement de production, utilisez un compte de service comme propriétaire de cette clé.
- Définissez une variable d’environnement pour cette clé API :
export WANDB_API_KEY=<your_api_key>.
wandb_resource.
Les exemples suivants montrent où spécifier votre clé API dans votre code Dagster. Renseignez votre entité et le nom de votre projet dans le dictionnaire imbriqué wandb_config. Vous pouvez transmettre des valeurs wandb_config différentes à différentes ops ou assets si vous souhaitez utiliser un autre projet W&B. Pour plus d’informations sur les clés possibles que vous pouvez transmettre, voir la section Configuration.
- Configuration pour @job
- Configuration pour @repository avec des assets
Exemple de configuration pour
@job :Configuration
wandb_resource: ressource Dagster utilisée pour communiquer avec l’API W&B. Elle s’authentifie automatiquement à l’aide de la clé API fournie. Propriétés :api_key: (str, requis) : une clé API W&B nécessaire pour communiquer avec l’API W&B.host: (str, facultatif) : le serveur hôte de l’API que vous souhaitez utiliser. Requis uniquement si vous utilisez W&B Server. Par défaut, l’hôte Public Cloudhttps://api.wandb.aiest utilisé.
wandb_artifacts_io_manager: IO Manager Dagster permettant d’utiliser des artefacts W&B. Propriétés :base_dir: (int, facultatif) Répertoire de base utilisé pour le stockage local et la mise en cache. Les artefacts W&B et les journaux des W&B Run sont écrits et lus dans ce répertoire. Par défaut, il utilise le répertoireDAGSTER_HOME.cache_duration_in_minutes: (int, facultatif) Définit la durée de conservation des artefacts W&B et des journaux des W&B Run dans le stockage local. Le cache supprime uniquement les fichiers et répertoires qui n’ont pas été ouverts pendant cette durée. La purge du cache a lieu à la fin de l’exécution d’un IO Manager. Définissez cette valeur sur 0 pour désactiver complètement la mise en cache. La mise en cache améliore les performances lorsqu’un artefact est réutilisé entre des jobs exécutés sur la même machine. La valeur par défaut est de 30 jours.run_id: (str, facultatif) : un ID unique pour ce run, utilisé pour la reprise. Il doit être unique dans le projet, et si vous supprimez un run, vous ne pouvez pas réutiliser cet ID. Utilisez le champ name pour un nom descriptif court, ou config pour enregistrer des hyperparamètres à comparer entre les runs. L’ID ne peut pas contenir les caractères spéciaux suivants :/\#?%:..Définissez le Run ID lorsque vous effectuez le suivi des expériences dans Dagster afin de permettre à l’IO Manager de reprendre le run. Par défaut, il est défini sur le Dagster Run ID, par exemple7e4df022-1bf2-44b5-a383-bb852df4077e.run_name: (str, facultatif) Nom d’affichage court pour ce run afin de vous aider à l’identifier dans l’interface utilisateur. Par défaut, il s’agit d’une chaîne au format suivant :dagster-run-[8 premiers caractères du Dagster Run ID]. Par exemple,dagster-run-7e4df022.run_tags: (list[str], facultatif) : liste de chaînes qui alimente la liste des tags de ce run dans l’interface utilisateur. Les tags sont utiles pour regrouper des runs ou appliquer des libellés temporaires commebaselineouproduction. Vous pouvez ajouter et supprimer des tags dans l’interface utilisateur, ou filtrer les runs pour n’afficher que ceux ayant un tag spécifique. Tout W&B Run utilisé par l’intégration possède le tagdagster_wandb.
Utiliser les artefacts W&B
@op ou @asset Dagster de créer et de consommer directement des artefacts W&B. L’exemple suivant montre un @asset qui produit un artefact W&B de type jeu de données contenant une liste Python.
@op, @asset et @multi_asset avec une configuration de métadonnées pour écrire des Artifacts. De même, vous pouvez également consommer des artefacts W&B même s’ils ont été créés en dehors de Dagster.
Écrire des artefacts W&B
- Objets Python (
int,dict,list, etc.) - Objets W&B (Table, Image, Graph, etc.)
- Objets artefact W&B
@asset) :
- Objets Python
- Objet W&B
- artefact W&B
Tout ce qui peut être sérialisé avec le module pickle est sérialisé avec pickle et ajouté à un Artifact créé par l’intégration. Le contenu est désérialisé lorsque vous lisez cet Artifact dans Dagster (voir Lire les artifacts pour plus de détails).W&B prend en charge plusieurs modules de sérialisation basés sur Pickle (pickle, dill, cloudpickle, joblib). Vous pouvez également utiliser des formats de sérialisation plus avancés comme ONNX ou PMML. Pour en savoir plus, consultez la section Serialization.
Configuration
wandb_artifact_configuration pour @op, @asset et @multi_asset. Transmettez ce dictionnaire dans les arguments du décorateur en tant que métadonnées. Cette configuration est requise pour contrôler les lectures et écritures de l’IO Manager des artefacts W&B.
Pour @op, il se trouve dans les métadonnées de sortie via l’argument de métadonnées Out.
Pour @asset, il se trouve dans l’argument metadata de l’asset.
Pour @multi_asset, il se trouve dans les métadonnées de chaque sortie via les arguments de métadonnées AssetOut.
Les exemples de code ci-dessous montrent comment configurer un dictionnaire pour des calculs @op, @asset et @multi_asset :
- Exemple pour @op
- Exemple pour @asset
- Exemple pour @multi_asset
Exemple pour
@op :name: (str) nom lisible par l’humain pour cet artifact, que vous pouvez utiliser pour l’identifier dans l’UI ou y faire référence dans les appelsuse_artifact. Les noms peuvent contenir des lettres, des chiffres, des underscores, des traits d’union et des points. Le nom doit être unique à l’échelle d’un projet. Requis pour@op.type: (str) type de l’artifact, utilisé pour organiser et différencier les artifacts. Les types courants incluent les jeux de données ou les modèles, mais vous pouvez utiliser n’importe quelle chaîne contenant des lettres, des chiffres, des underscores, des traits d’union et des points. Requis lorsque la sortie n’est pas déjà un Artifact.description: (str) Texte libre qui décrit l’artifact. La description est interprétée en markdown dans l’UI, c’est donc un bon endroit pour les tableaux, les liens, etc.aliases: (list[str]) Un tableau contenant un ou plusieurs alias que vous souhaitez appliquer à l’artefact W&B. L’intégration ajoute également le tag “latest” à cette liste, qu’il soit défini ou non. Utilisez les alias pour gérer les versions des modèles et des jeux de données.add_dirs: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque répertoire local à inclure dans l’artefact W&B.add_files: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque fichier local à inclure dans l’artefact W&B.add_references: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque référence externe à inclure dans l’artefact W&B.serialization_module: (dict) Configuration du module de sérialisation à utiliser. Se référer à la section Serialization pour plus d’informations.name: (str) Nom du module de sérialisation. Valeurs acceptées :pickle,dill,cloudpickle,joblib. Le module doit être disponible localement.parameters: (dict[str, Any]) Arguments facultatifs transmis à la fonction de sérialisation. Elle accepte les mêmes paramètres que la méthodedumpde ce module. Par exemple,{"compress": 3, "protocol": 4}.
- Côté W&B : le nom et la version de l’intégration source, la version de Python utilisée, la version du protocole pickle, entre autres.
- Côté Dagster :
- ID du run Dagster
- W&B Run : ID, nom, chemin, URL
- artefact W&B : ID, nom, type, version, taille, URL
- Entité W&B
- Projet W&B




Si vous utilisez un vérificateur de types statique comme mypy, importez l’objet de définition du type de configuration comme suit :
Utiliser les partitions
DailyPartitionsDefinition :
my_daily_partitioned_asset.2023-01-01, my_daily_partitioned_asset.2023-01-02 ou my_daily_partitioned_asset.2023-01-03. Les assets partitionnés sur plusieurs dimensions affichent chaque dimension dans un format délimité par des points. Par exemple, my_asset.car.blue.
Utilisation avancée
- job partitionné
- asset partitionné simple
- asset partitionné multi-dimensionnel
- Utilisation avancée du partitionnement
Lire Artifacts W&B
wandb_artifact_configuration peut être défini sur un @op ou un @asset. La seule différence est que la configuration doit être définie sur l’entrée plutôt que sur la sortie.
Pour @op, elle se trouve dans les métadonnées d’entrée via l’argument de métadonnées In. Vous devez
indiquer explicitement le nom de l’artefact W&B.
Pour @asset, elle se trouve dans les métadonnées d’entrée via l’argument de métadonnées Asset In. Vous ne devez pas transmettre de nom d’artefact W&B, car le nom de l’asset parent doit correspondre.
Si vous souhaitez créer une dépendance sur un Artifact créé en dehors de l’intégration, vous devrez utiliser SourceAsset. Il lira toujours la dernière version de cet asset.
Les exemples suivants montrent comment lire un Artifact à partir de différents ops.
- Depuis un @op
- Créé par un autre @asset
- Artifact créé en dehors de Dagster
Lecture d’un artifact à partir d’un
@opConfiguration
- Pour obtenir un objet nommé contenu dans un Artifact, utilisez
get:
- Pour obtenir le chemin local d’un fichier téléchargé présent dans un Artifact, utilisez
get_path:
- Pour obtenir l’objet Artifact dans son intégralité (avec le contenu téléchargé localement) :
get: (str) Obtient l’objet W&B correspondant au nom relatif de l’artifact.get_path: (str) Obtient le chemin du fichier correspondant au nom relatif de l’artifact.
Configuration de la sérialisation
yield génèrent une erreur si vous essayez de les sérialiser avec pickle.
W&B prend également en charge d’autres modules de sérialisation basés sur Pickle (dill, cloudpickle, joblib). Vous pouvez aussi utiliser des méthodes de sérialisation plus avancées comme ONNX ou PMML, en renvoyant une chaîne sérialisée ou en créant directement un Artifact. Le choix le plus adapté dépend de votre cas d’usage. Veuillez vous référer à la documentation disponible sur ce sujet.
Modules de sérialisation basés sur pickle
serialization_module dans wandb_artifact_configuration. Assurez-vous que le module est disponible sur la machine exécutant Dagster.
L’intégration détecte automatiquement quel module de sérialisation utiliser lorsque vous lirez cet Artifact.
Les modules pris en charge sont pickle, dill, cloudpickle et joblib.
Voici un exemple simplifié qui crée un « modèle » sérialisé avec joblib, puis l’utilise pour l’inférence.
Formats de sérialisation avancés (ONNX, PMML)
- Convertissez votre modèle dans le format sélectionné, puis renvoyez sa représentation sous forme de chaîne comme s’il s’agissait d’un objet Python ordinaire. L’intégration sérialise cette chaîne avec pickle. Vous pourrez ensuite reconstruire votre modèle à partir de cette chaîne.
- Créez un nouveau fichier local contenant votre modèle sérialisé, puis créez un Artifact personnalisé avec ce fichier à l’aide de la configuration
add_file.
Utiliser des partitions
L’intégration prend directement en charge les partitions Dagster. Vous pouvez lire une, plusieurs ou toutes les partitions d’un asset de manière sélective. Toutes les partitions sont fournies dans un dictionnaire, où la clé et la valeur représentent respectivement la clé de partition et le contenu de l’Artifact.- Lire toutes les partitions
- Lire des partitions spécifiques
Cet exemple lit toutes les partitions de l’
@asset amont, fournies sous forme de dictionnaire. Dans ce dictionnaire, la clé et la valeur correspondent respectivement à la clé de partition et au contenu de l’Artifact.metadata détermine comment W&B interagit avec les différentes partitions d’artefact W&B dans votre projet.
L’objet metadata contient une clé nommée wandb_artifact_configuration, qui contient elle-même un objet imbriqué partitions.
L’objet partitions associe le nom de chaque partition à sa configuration. La configuration de chaque partition peut préciser comment récupérer ses données. Ces configurations peuvent contenir différentes clés, à savoir get, version et alias, selon les exigences de chaque partition.
Clés de configuration
get: La clégetspécifie le nom de l’objet W&B (Table, Image, etc.) à partir duquel récupérer les données.version: Utilisez la cléversionlorsque vous souhaitez récupérer une version spécifique de l’Artifact.alias: La cléaliasvous permet d’obtenir l’Artifact à l’aide de son alias.
Configuration générique
"*" désigne toutes les partitions non configurées. Il fournit une configuration par défaut pour les partitions qui ne sont pas explicitement mentionnées dans l’objet partitions.
Par exemple :
default_table_name.
Configuration spécifique de partition
yellow, les données sont récupérées depuis le tableau nommé custom_table_name, ce qui remplace la configuration générique.
Gestion des versions et des alias
version et alias spécifiques dans votre configuration.
Pour les versions :
orange en version v0.
Pour les alias :
default_table_name de la partition Artifact avec l’alias special_alias (désigné par blue dans la configuration).
Utilisation avancée
Pour consulter des cas d’utilisation avancée de l’intégration, se référer aux exemples de code complets suivants :- Exemple d’utilisation avancée pour les assets
- Exemple de job partitionné
- Associer un modèle au registre de modèles
Utiliser W&B Launch
- Exécuter un ou plusieurs agents Launch dans votre instance Dagster.
- Exécuter des jobs Launch locaux dans votre instance Dagster.
- Exécuter des jobs Launch à distance, sur site ou dans le cloud.
agent Launch
@op importable appelé run_launch_agent. Il démarre un agent Launch et l’exécute comme un processus de longue durée jusqu’à ce qu’il soit arrêté manuellement.
Les agents sont des processus qui interrogent les files d’attente de Launch et exécutent les jobs dans l’ordre (ou les transmettent à des services externes pour exécution).
Référez-vous à la page Launch.
Vous pouvez également consulter les descriptions de toutes les propriétés dans Launchpad.

Jobs Launch
@op importable appelé run_launch_job. Il exécute votre job Launch.
Pour être exécuté, un job Launch doit être assigné à une file d’attente. Vous pouvez créer une file d’attente ou utiliser celle par défaut. Assurez-vous qu’un agent actif écoute cette file d’attente. Vous pouvez exécuter un agent dans votre instance Dagster, ou envisager d’utiliser un agent déployable sur Kubernetes.
Consultez la page Launch.
Vous pouvez également consulter dans Launchpad des descriptions pour toutes les propriétés.

Bonnes pratiques
Utilisez l’IO Manager pour lire et écrire des Artifacts
Artifact.download() ou Run.log_artifact(). Ces méthodes sont prises en charge par l’intégration. Renvoyez plutôt les données que vous souhaitez stocker dans l’Artifact et laissez l’intégration faire le reste. Cette approche offre une meilleure traçabilité pour l’Artifact.
Ne créez vous-même un objet Artifact que pour des cas d’usage complexes
Ajoutez des fichiers, des répertoires et des références externes à vos Artifacts via les métadonnées
wandb_artifact_configuration pour ajouter des fichiers, des répertoires ou des références externes (Amazon S3, GCS, HTTP, etc.). Voir l’exemple avancé dans la section de configuration de l’Artifact pour plus d’informations.
