- 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。
始める前に
APIキーを設定する
- W&Bにログインします。W&B Server を使用している場合は、インスタンスのホスト名を管理者に確認してください。
- User Settings でAPIキーを作成します。本番環境では、そのキーの所有にサービスアカウントを使用してください。
- そのAPIキー用の環境変数を設定します:
export WANDB_API_KEY=<your_api_key>。
wandb_resource の読み込み時に環境からAPIキーを読み取れるようになります。
以下の例では、Dagster のコード内でAPIキーを指定する場所を示します。wandb_config のネストされた辞書内に、entity とproject名を指定してください。別の W&B project を使用したい場合は、異なる op や アセット に異なる wandb_config の値を渡せます。指定できるキーの詳細については、設定セクションを参照してください。
- @job の設定
- アセット を使用した @repository の設定
@job の設定例:設定
wandb_resource: W&B API との通信に使用する Dagster resource です。指定された 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 です。これは 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]形式の string です。たとえばdagster-run-7e4df022です。run_tags: (list[str], optional): UI でこの run のタグ一覧に表示される strings のリストです。タグは、runs をまとめて整理したり、baselineやproductionのような一時的なラベルを付けたりするのに便利です。UI でタグを追加または削除したり、特定のタグを持つ runs に絞ってフィルターしたりできます。このインテグレーションで使用されるすべての W&B Run にはdagster_wandbタグが付きます。
W&B Artifacts を使用する
@op または @asset で W&B Artifacts を直接作成したり利用したりできます。以下の例では、Python の list を含む dataset タイプの 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 を読み取ると、内容はアンピクルされます (詳細は 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 の場合、これは アセット の metadata 引数に指定します。
@multi_asset の場合、これは AssetOut の metadata 引数を介して各出力の metadata に指定します。
以下のコード例は、@op、@asset、@multi_asset の計算に対して辞書を設定する方法を示しています。
- @op の例
- @asset の例
- @multi_asset の例
@op の例:name: (str) この Artifact の人間が読める名前です。UI でこの Artifact を識別したり、use_artifact呼び出しで参照したりするために使います。名前には、英字、数字、アンダースコア、ハイフン、ドットを使用できます。名前はproject内で一意である必要があります。@opでは必須です。type: (str) Artifact のタイプです。Artifacts を整理して区別するために使用します。一般的なタイプにはデータセットやモデルがありますが、英字、数字、アンダースコア、ハイフン、ドットを含む任意の文字列を使用できます。出力がすでに Artifact でない場合は必須です。description: (str) Artifact の説明を記述する自由形式のテキストです。説明は UI で markdown として表示されるため、表やリンクなどを記載するのに適しています。aliases: (list[str]) Artifact に適用する 1 つ以上の alias を含む配列です。インテグレーションは、設定の有無にかかわらず、このリストに “latest” タグも追加します。aliases を使用して、モデルやデータセットのバージョン管理を行います。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 method と同じパラメーターを受け付けます。たとえば、{"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 のような静的型チェッカーを使用している場合は、次のように設定の型定義オブジェクトをインポートします。
パーティションを使用する
DailyPartitionsDefinition を使用したパーティション分割の例です。
my_daily_partitioned_asset.2023-01-01、my_daily_partitioned_asset.2023-01-02、my_daily_partitioned_asset.2023-01-03 です。複数のディメンションにまたがってパーティション化されたアセットでは、各ディメンションがドット区切り形式で表示されます。たとえば、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を使用します:
- コンテンツをローカルにダウンロードした状態で、アーティファクト オブジェクト全体を取得するには:
get: (str) artifact の相対名で指定された W&B オブジェクトを取得します。get_path: (str) artifact の相対名で指定されたファイルへのパスを取得します。
シリアライズ設定
yieldを含む関数を pickle 化しようとするとエラーになります。
W&B は、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設定を使用して、そのファイルを含む custom Artifact を build します。
パーティションの使用
このインテグレーションは、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 をその alias で取得できます。
ワイルドカード設定
"*" は、設定されていないすべてのパーティションを表します。これにより、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 エージェントを実行する。
- Dagster インスタンス内でローカルの Launch ジョブを実行する。
- オンプレミスまたはクラウドでリモートの Launch ジョブを実行する。
Launch エージェント
run_launch_agent という @op が提供されています。これにより Launch エージェントが起動し、手動で停止するまで長時間実行されるプロセスとして動作します。
エージェントは、Launch キューをポーリングし、ジョブを順番に実行するプロセスです (または、外部サービスにディスパッチして実行します) 。
Launch ページを参照してください。
また、Launchpad では、すべてのプロパティの説明を確認できます。

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

ベストプラクティス
IO Manager を使用して Artifacts を読み書きしてください
Artifact.download() や Run.log_artifact() を直接使用することは避けてください。これらの method はインテグレーションによって処理されます。代わりに、Artifact に保存したいデータを返し、残りの処理はインテグレーションに任せてください。この方法により、Artifact のリネージがより適切になります。
複雑なユースケースでのみ、自分で Artifact object を build してください
ファイル、ディレクトリ、外部参照はメタデータ経由で Artifacts に追加してください。
wandb_artifact_configuration object を使用して、任意のファイル、ディレクトリ、または外部参照 (Amazon S3、GCS、HTTP…) を追加します。詳細については、Artifact 設定セクション の高度な例を参照してください。
