- W&B Artifact を作成して使用する。
- W&B Registry で Registered Models を使用および作成する。
- W&B Launch を使用して、専用のコンピュート環境でトレーニングジョブを実行する。
- ops と assets で wandb クライアントを使用する。
wandb_resource: W&B API への認証と通信に使用する Dagster リソース。wandb_artifacts_io_manager: W&B Artifacts を利用するための Dagster IO Manager。
始める前に
- W&B APIキー。
- W&B entity (ユーザーまたはチーム) : entity とは、W&B Runs と Artifacts の送信先となるユーザー名またはチーム名です。run をログする前に、W&B App UI でアカウントまたはチーム entity を必ず作成してください。entity を指定しない場合、run はデフォルトの entity (通常はユーザー名) に送信されます。デフォルトの entity は、Settings の Project Defaults で変更してください。
- W&B project: W&B Runs が保存される project の名です。
APIキーを設定する
- W&B にログインします。注: W&B Server を使用している場合は、インスタンスのホスト名を管理者に確認してください。
- User Settings でAPIキーを作成します。本番環境では、そのキーの所有者としてサービスアカウントを使用することを推奨します。
- そのAPIキー用の環境変数を設定します:
export WANDB_API_KEY=YOUR_KEY。
wandb_config のネストされた辞書内に、entity と project 名を必ず指定してください。別の W&B Project を使用する場合は、ops や assets ごとに異なる wandb_config の値を渡せます。渡せるキーの詳細については、以下の Configuration セクションを参照してください。
- @job の設定
- assets を使用する @repository の設定
例:
@job の設定設定
wandb_resource: W&B API との通信に使用する Dagster の リソース です。指定された APIキーを使用して自動的に認証されます。プロパティ:api_key: (str, required): W&B API と通信するために必要な W&B APIキーです。host: (str, optional): 使用する API ホストサーバーです。W&B Server を使用している場合にのみ必要です。デフォルトでは、Public Cloud ホストhttps://api.wandb.aiが使用されます。
wandb_artifacts_io_manager: W&B Artifacts を利用するための Dagster の IO Manager です。プロパティ:base_dir: (int, optional) ローカルストレージおよびキャッシュに使用するベースディレクトリーです。W&B Artifacts と W&B Run のログは、このディレクトリーに書き込まれ、ここから読み取られます。デフォルトではDAGSTER_HOMEディレクトリーが使用されます。cache_duration_in_minutes: (int, optional) W&B Artifacts と W&B Run のログをローカルストレージに保持する時間を定義します。その時間のあいだ開かれていないファイルとディレクトリーのみがキャッシュから削除されます。キャッシュの削除は、IO Manager の実行終了時に行われます。キャッシュを完全に無効にしたい場合は、0 に設定できます。同じマシン上で実行されるジョブ間で artifact が再利用される場合、キャッシュにより速度が向上します。デフォルトは 30 日です。run_id: (str, optional): 再開に使用する、この run の一意の ID です。この ID は project 内で一意である必要があり、run を削除すると同じ ID を再利用することはできません。短い説明的な名前には name フィールドを使用し、runs 間で比較するためにハイパーパラメーターを保存するには config を使用します。ID には次の特殊文字を含めることはできません:/\\#?%:..Dagster 内で実験管理を行う場合は、IO Manager が run を再開できるように Run ID を設定する必要があります。デフォルトでは Dagster Run ID (例:7e4df022-1bf2-44b5-a383-bb852df4077e) に設定されます。run_name: (str, optional) UI でこの run を識別しやすくするための短い表示名です。デフォルトでは、dagster-run-[8 first characters of the Dagster Run ID]形式の文字列になります。たとえばdagster-run-7e4df022です。run_tags: (list[str], optional): UI でこの run の tags の一覧に表示される文字列のリストです。tags は、runs をまとめて整理したり、baselineやproductionのような一時的なラベルを付けたりするのに役立ちます。UI では tags の追加や削除を簡単に行えるほか、特定の tag を持つ runs のみにフィルターすることもできます。インテグレーションで使用されるすべての W&B Run には、dagster_wandbtag が付きます。
W&B Artifacts を使用する
@op または @asset で W&B Artifacts をネイティブに作成し、利用できます。以下は、Python の list を含む、データセット タイプの W&B Artifact を生成する @asset のシンプルな例です。
@op、@asset、@multi_asset にメタデータ設定のアノテーションを追加することで、Artifacts に書き込めます。同様に、Dagster の外部で作成された W&B Artifacts も利用できます。
W&B Artifacts を書き込む
- Python オブジェクト (int、dict、list…)
- W&B オブジェクト (Table、Image、Graph…)
- W&B Artifact オブジェクト
@asset) を使って W&B Artifacts に書き込む方法を示します。
- Python オブジェクト
- W&B オブジェクト
- W&B Artifact
pickle モジュールでシリアライズできるものはすべて pickle 化され、インテグレーションによって作成された Artifact に追加されます。Dagster 内でその Artifact を読み取る際には、内容は unpickle 化されます (詳細は Read artifacts を参照してください) 。W&B は複数の Pickle ベースのシリアライズモジュール (pickle、dill、cloudpickle、joblib) をサポートしています。ONNX や PMML などの、より高度なシリアライズ方式を使用することもできます。詳細は Serialization セクションを参照してください。
設定
wandb_artifact_configuration という設定辞書は、@op、@asset、@multi_asset に設定できます。この辞書は、デコレータの引数で metadata として渡す必要があります。この設定は、W&B Artifacts に対する IO Manager の読み取りと書き込みを制御するために必須です。
@op の場合は、Out の metadata 引数を通じて出力 metadata に指定します。
@asset の場合は、asset の metadata 引数に指定します。
@multi_asset の場合は、各出力の metadata に AssetOut の metadata 引数を通じて指定します。
以下のコード例は、@op、@asset、@multi_asset の各計算で辞書を設定する方法を示しています。
- @op の例
- @asset の例
- @multi_asset の例
@op の例:name: (str) この artifact の人が読みやすい名前です。UI でこの artifact を識別したり、use_artifact呼び出しで参照したりするために使用します。名前には、文字、数字、アンダースコア、ハイフン、ドットを使用できます。名前は project 全体で一意である必要があります。@opでは必須です。type: (str) artifact のタイプです。artifact を整理し、区別するために使用します。一般的なタイプには dataset や model がありますが、文字、数字、アンダースコア、ハイフン、ドットを含む任意の文字列を使用できます。出力がまだ Artifact でない場合は必須です。description: (str) artifact の説明を記述する自由形式のテキストです。説明は UI で Markdown としてレンダリングされるため、表やリンクなどを配置するのに適しています。aliases: (list[str]) Artifact に適用する 1 つ以上のエイリアスを含む配列です。インテグレーションは、設定の有無にかかわらず、そのリストに “latest” タグも追加します。これは、モデルやデータセットのバージョン管理に効果的な方法です。add_dirs: (list[dict[str, Any]]) :Artifact に含める各ローカルディレクトリの設定を含む配列です。add_files: (list[dict[str, Any]]) :Artifact に含める各ローカルファイルの設定を含む配列です。add_references: (list[dict[str, Any]]) :Artifact に含める各外部参照の設定を含む配列です。serialization_module: (dict) 使用するシリアライズモジュールの設定です。詳細については、Serialization セクションを参照してください。name: (str) シリアライズモジュールの名前です。指定可能な値はpickle、dill、cloudpickle、joblibです。このモジュールはローカル環境で利用可能である必要があります。parameters: (dict[str, Any]) シリアライズ関数に渡す任意の引数です。そのモジュールの dump メソッドと同じパラメーターを指定できます。たとえば、{"compress": 3, "protocol": 4}です。
- W&B 側: ソース インテグレーションの名前とバージョン、使用された Python のバージョン、pickle プロトコルのバージョンなど。
- Dagster 側:
- Dagster Run ID
- W&B Run: ID、名、パス、URL
- W&B Artifact: ID、名、タイプ、バージョン、サイズ、URL
- W&B Entity
- W&B Project




mypy などの静的型チェッカーを使用する場合は、次のように設定タイプ定義オブジェクトを import してください。
パーティションを使用する
DailyPartitionsDefinition を使用したパーティションの例です。
my_daily_partitioned_asset.2023-01-01、my_daily_partitioned_asset.2023-01-02、my_daily_partitioned_asset.2023-01-03 です。複数の次元にまたがってパーティション化された asset では、各次元がドット区切り形式で表示されます。たとえば、my_asset.car.blue です。
高度な使い方
W&B Artifacts を読み取る
wandb_artifact_configuration という設定ディクショナリを @op または @asset に設定できます。唯一の違いは、出力ではなく入力に対して設定する必要があることです。
@op の場合、これは In の metadata 引数を通じて入力メタデータに指定します。Artifact の名を
明示的に渡す必要があります。
@asset の場合、これは Asset In metadata 引数を通じて入力メタデータに指定します。親アセット の名がそれと一致するはずなので、Artifact 名は渡さないでください。
インテグレーションの外部で作成された Artifact に依存させたい場合は、SourceAsset を使用する必要があります。これは常にそのアセット の最新バージョンを読み取ります。
以下の例は、さまざまな op から Artifact を読み取る方法を示しています。
- @op から
- 別の @asset によって作成
- Dagster の外部で作成された Artifact
@op から artifact を読み取る設定
- Artifact 内に含まれる名前付きオブジェクトを取得するには、get を使用します:
- Artifact に含まれるダウンロード済みファイルのローカルパスを取得するには、get_path を使用してください:
- 内容がローカルにダウンロードされた Artifact オブジェクト全体を取得するには:
get: (str) artifact の相対名で指定された場所にある W&B オブジェクトを取得します。get_path: (str) artifact の相対名で指定された場所にあるファイルのパスを取得します。
シリアル化の設定
yield を含む関数を pickle 化しようとすると、エラーが発生します。
dill、cloudpickle、joblib など、他の Pickle ベースのシリアル化モジュールもサポートしています。また、シリアル化済みの文字列を返すか、Artifact を直接作成することで、ONNX や PMML などの、より高度なシリアル化方式を使用することもできます。適切な選択はユースケースによって異なるため、このトピックに関する関連文献を参照してください。
Pickle ベースのシリアル化モジュール
wandb_artifact_configuration 内の serialization_module 辞書で設定できます。Dagster を実行しているマシンで、そのモジュールが利用可能であることを確認してください。
その Artifact を読み取る際、どのシリアル化モジュールを使用するかは、インテグレーションが自動的に判断します。
現在サポートされているモジュールは、pickle、dill、cloudpickle、joblib です。
以下は、joblib でシリアライズした「モデル」を作成し、それを推論に使用する簡略化した例です。
高度なシリアル化形式 (ONNX、PMML)
- モデルを選択した形式に変換し、その形式の文字列表現を通常の Python オブジェクトであるかのように返します。インテグレーションはその文字列を pickle 化します。後でその文字列を使ってモデルを再構築できます。
- シリアライズしたモデルを含む新しいローカルファイルを作成し、
add_file設定を使用して、そのファイルを含むカスタム Artifact を作成します。
パーティションの使用
このインテグレーションは、Dagster partitions をネイティブにサポートしています。 アセット の 1 つ、複数、またはすべてのパーティションを選択して読み取ることができます。 すべてのパーティションは辞書として提供され、キーと値はそれぞれパーティションキーと Artifact の内容を表します。- すべてのパーティションを読み取る
- 特定のパーティションを読み取る
上流の
@asset のすべてのパーティションを読み取り、それらは辞書として渡されます。この辞書では、キーと値がそれぞれパーティションキーと Artifact の内容に対応します。metadata は、W&B が project 内の異なる Artifact パーティションとどのようにやり取りするかを定義します。
オブジェクト metadata には wandb_artifact_configuration というキーがあり、その中にネストされた partitions オブジェクトが含まれています。
partitions オブジェクトは、各パーティションの名をその設定に対応付けます。各パーティションの設定では、そこからデータを取得する方法を指定できます。これらの設定には、各パーティションの要件に応じて、get、version、alias などのキーを含めることができます。
設定キー
get:getキーは、データの取得元となる W&B Object (Table、Image など) の名を指定します。version:versionキーは、Artifact の特定のバージョンを取得したい場合に使用します。alias:aliasキーを使用すると、Artifact をそのエイリアスで取得できます。
"*" は、設定されていないすべてのパーティションを表します。これにより、partitions オブジェクトで明示的に指定されていないパーティションに対するデフォルト設定を指定できます。
例えば、
default_table_name という名前の表からデータを取得します。
特定のパーティションの設定
各パーティションのキーを使って個別の設定を指定することで、特定のパーティションではワイルドカード設定を上書きできます。
たとえば、
yellow という名前のパーティションのデータは、ワイルドカード設定を上書きして、custom_table_name という名前の表から取得されます。
バージョン管理とエイリアス
バージョン管理やエイリアス指定のために、設定で version キーおよび alias キーを個別に指定できます。
バージョンについては、
orange Artifact パーティションの v0 バージョンからデータを取得します。
エイリアスについては、
special_alias が付いた Artifact パーティションの表 default_table_name からデータを取得します (設定内では blue として参照されます) 。
高度な使い方
インテグレーションの高度な使い方については、以下のコード全体の例を参照してください。W&B Launchを使う
- Dagster インスタンス内で 1 つまたは複数の Launch agent を実行する。
- Dagster インスタンス内でローカルの Launch ジョブを実行する。
- オンプレミスまたはクラウドでリモートの Launch ジョブを実行する。
Launch エージェント
@op である run_launch_agent を提供します。これにより Launch エージェントを起動し、手動で停止するまで長時間実行プロセスとして動作させます。
エージェントは、Launch キュー をポーリングし、ジョブを順に実行するプロセスです (または、実行のために外部サービスへディスパッチします) 。
詳しくは、Launch ページを参照してください。
また、Launchpad ではすべてのプロパティについて役立つ説明を確認できます。

Launch ジョブ
@op である run_launch_job を提供します。これを使用して Launch ジョブを実行できます。
Launch ジョブを実行するには、キューに割り当てる必要があります。キューは新しく作成することも、デフォルトのものを使用することもできます。そのキューをリッスンしているアクティブなエージェントが存在することを確認してください。Dagster インスタンス内でエージェントを実行することもできますが、Kubernetes 上でデプロイ可能なエージェントの使用も検討してください。
Launch ページを参照してください。
Launchpad では、すべてのプロパティについて役立つ説明も確認できます。

ベスト プラクティス
-
IO Manager を使用して Artifacts を読み書きしてください。
Artifact.download()やRun.log_artifact()を直接使用することは避けてください。これらのメソッドはインテグレーションによって処理されます。代わりに、Artifact に保存したいデータを返し、残りの処理はインテグレーションに任せてください。この方法により、Artifact のリネージをより適切に取得できます。 - 複雑なユース ケースでのみ、Artifact オブジェクトを自分で構築してください。 Python オブジェクトと W&B オブジェクトは、ops/assets から返すようにしてください。Artifact のバンドルはインテグレーションが処理します。 複雑なユース ケースでは、Dagster ジョブ内で直接 Artifact を構築できます。ソース インテグレーション名とバージョン、使用した Python バージョン、pickle プロトコルのバージョンなどのメタデータをより充実させるため、Artifact オブジェクトをインテグレーションに渡すことをお勧めします。
-
ファイル、ディレクトリ、外部参照は、メタデータを通じて Artifacts に追加してください。
インテグレーションの
wandb_artifact_configurationオブジェクトを使用して、任意のファイル、ディレクトリ、または外部参照 (Amazon S3、GCS、HTTP…) を追加してください。詳細は、Artifact configuration section の高度な例を参照してください。 - Artifact が生成される場合は、@op ではなく @asset を使用してください。 Artifacts はアセットです。Dagster がそのアセットを管理する場合は、アセット を使用することをお勧めします。これにより、Dagit Asset Catalog での可観測性が向上します。
- Dagster の外部で作成された Artifact を利用するには、SourceAsset を使用してください。 これにより、外部で作成された Artifacts を読み取る際にもインテグレーションを活用できます。そうでない場合は、インテグレーションによって作成された Artifacts しか使用できません。
- 大規模モデルのトレーニングを専用コンピュートでオーケストレーションするには、W&B Launch を使用してください。 小規模なモデルであれば Dagster クラスター内でトレーニングでき、GPU ノードを備えた Kubernetes クラスターで Dagster を実行することもできます。大規模モデルのトレーニングには W&B Launch を使用することをお勧めします。これにより、インスタンスの過負荷を防ぎ、より適切なコンピュートを利用できます。
- Dagster 内で実験管理を行う場合は、W&B Run ID を Dagster Run ID の値に設定してください。 Run resumable にすることと、W&B Run ID を Dagster Run ID または任意の文字列に設定することの両方をお勧めします。この推奨に従うことで、Dagster 内でモデルをトレーニングする際、W&B メトリクスと W&B Artifacts が同じ W&B Run に保存されます。
-
大きな W&B Artifacts では、
getまたはget_pathを使って必要なデータだけを取得してください。 デフォルトでは、このインテグレーションは Artifact 全体をダウンロードします。非常に大きな artifact を使用している場合は、必要な特定のファイルやオブジェクトだけを取得するとよいでしょう。これにより、速度とリソース使用率が向上します。 -
Python オブジェクトでは、ユースケースに合わせて pickling モジュールを使い分けてください。
デフォルトでは、W&B インテグレーションは標準の pickle モジュールを使用します。ただし、一部のオブジェクトはこれに対応していません。たとえば、
yieldを含む関数は pickle 化しようとするとエラーになります。W&B は、その他の Pickle ベースのシリアル化モジュール (dill、cloudpickle、joblib) もサポートしています。
