Skip to main content
Dagster と W&B を併用して、MLOps パイプラインをオーケストレーションし、ML アセットを管理できます。既存の Dagster ワークフロー内で、Experiments をトラッキングし、データを管理し、トレーニングジョブを実行できます。W&B インテグレーションは、次のタスクをサポートします。
  • W&B Artifact を作成して使用する。
  • W&B Registry で Registered Models を作成して使用する。
  • W&B Launch を使用して、専用のコンピュートでトレーニングジョブを実行する。
  • ops と assets で wandb クライアントを使用する。
W&B Dagster インテグレーションでは、W&B 専用の Dagster リソースと IO Manager を提供します。
  • wandb_resource: W&B API への認証と通信に使用する Dagster リソース。
  • wandb_artifacts_io_manager: W&B Artifacts を利用するための Dagster IO Manager。
このガイドは、すでに Dagster を使用していて、W&B の tracking と artifact 管理を追加したい ML 実務者およびプラットフォーム エンジニア向けです。Dagster の設定方法、ops と assets で W&B Artifacts を作成して使用する方法、W&B Launch の使い方、ベストプラクティスの適用方法を学べます。

始める前に

W&B で Dagster を使用するには、次のリソースが必要です。
  • W&B APIキー
  • W&B entity: あなたの W&B Team の名です。
  • W&B project: W&B Runs が保存されるprojectの名です。
W&B entity は、W&B でチームのプロフィールページを確認すると見つけられます。W&B project は既存のものを使用することも、新しく作成することもできます。新しいprojectは、W&B のホームページまたはチームのプロフィールページで作成できます。projectが存在しない場合は、最初に使用したときに自動的に作成されます。

APIキーを設定する

このインテグレーションはAPIキーを使用して W&B に対して認証を行います。このキーは、環境変数として Dagster から利用できるようにする必要があります。
  1. W&Bにログインします。W&B Server を使用している場合は、インスタンスのホスト名を管理者に確認してください。
  2. User Settings でAPIキーを作成します。本番環境では、そのキーの所有にサービスアカウントを使用してください。
  3. そのAPIキー用の環境変数を設定します: export WANDB_API_KEY=<your_api_key>
これらのステップを完了すると、Dagster は wandb_resource の読み込み時に環境からAPIキーを読み取れるようになります。 以下の例では、Dagster のコード内でAPIキーを指定する場所を示します。wandb_config のネストされた辞書内に、entity とproject名を指定してください。別の W&B project を使用したい場合は、異なる op や アセット に異なる wandb_config の値を渡せます。指定できるキーの詳細については、設定セクションを参照してください。
@job の設定例:

設定

このインテグレーションは、以下の設定オプションを持つ W&B 固有の Dagster リソースと IO Manager を提供します。
  • 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 をまとめて整理したり、baselineproduction のような一時的なラベルを付けたりするのに便利です。UI でタグを追加または削除したり、特定のタグを持つ runs に絞ってフィルターしたりできます。このインテグレーションで使用されるすべての W&B Run には dagster_wandb タグが付きます。

W&B Artifacts を使用する

このセクションでは、このインテグレーションが Dagster の IO Manager を使用して、W&B Artifacts と Dagster の op およびアセットを橋渡しする方法を説明します。 W&B Artifact とのインテグレーションは、Dagster の IO Manager に依存しています。 IO Managers はユーザーが提供するオブジェクトで、アセット または op の出力を保存し、それを下流の アセット または op への入力として読み込む役割を持ちます。たとえば、IO Manager はファイルシステム上のファイルにオブジェクトを保存し、そこから読み込むことがあります。 このインテグレーションでは、W&B Artifacts 用の IO Manager を提供しています。これにより、任意の Dagster @op または @asset で W&B Artifacts を直接作成したり利用したりできます。以下の例では、Python の list を含む dataset タイプの W&B Artifact を生成する @asset を示します。
@op@asset@multi_asset には、Artifacts に書き込むためのメタデータ設定を付与できます。同様に、Dagster の外部で作成された W&B Artifacts も利用できます。

W&B Artifacts に書き込む

以下のセクションでは、サポートされる戻り値のタイプや生成される Artifact の設定方法を含め、Dagster の op とアセットから W&B Artifacts を生成する方法について説明します。 先に進む前に、W&B Artifacts の使い方を理解していることを確認してください。Artifacts ガイドを参照してください。 W&B Artifact に書き込むには、Python 関数からオブジェクトを返します。W&B では、次のオブジェクトがサポートされます。
  • Python オブジェクト (intdictlist など)
  • W&B オブジェクト (TableImageGraph など)
  • W&B Artifact オブジェクト
以下の例は、Dagster アセット (@asset) を使用して W&B Artifacts に書き込む方法を示しています。
pickle モジュールでシリアライズ可能なものはすべて pickle 化され、インテグレーションによって作成された Artifact に追加されます。Dagster 内でその Artifact を読み取ると、内容はアンピクルされます (詳細は Artifactsを読み取る を参照してください) 。
W&B は複数の pickle ベースのシリアライズモジュール (pickledillcloudpicklejoblib) をサポートします。ONNXPMML のような、より高度なシリアライズを使用することもできます。詳細は 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 の例:
以下のプロパティがサポートされます:
  • 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
次の画像は、インテグレーションが Dagster アセット に追加する W&B のメタデータを示しています。インテグレーションはこの情報を Dagster に伝播します。
W&B メタデータが付加された アセット 詳細ビューを含む Dagster の UI。W&B project と run への参照を含みます
次の画像は、指定した設定が W&B Artifact 上でどのようにメタデータで拡張されるかを示しています。この情報は、再現性とメンテナンスに役立ちます。インテグレーションがなければ利用できません。
Dagster から拡張された設定メタデータを含む W&B Artifact ページ
Dagster 由来の追加の設定詳細を含む W&B Artifact のメタデータパネル
Dagster によってさらに拡張された設定メタデータフィールドを含む W&B Artifactビュー
mypy のような静的型チェッカーを使用している場合は、次のように設定の型定義オブジェクトをインポートします。

パーティションを使用する

このインテグレーションは、Dagster partitions を直接サポートします。 以下は、DailyPartitionsDefinition を使用したパーティション分割の例です。
このコードは、パーティションごとに 1 つの W&B Artifact を生成します。Artifact パネル (UI) では、パーティションキーが末尾に付いたアセット名の下に Artifact が表示されます。たとえば、my_daily_partitioned_asset.2023-01-01my_daily_partitioned_asset.2023-01-02my_daily_partitioned_asset.2023-01-03 です。複数のディメンションにまたがってパーティション化されたアセットでは、各ディメンションがドット区切り形式で表示されます。たとえば、my_asset.car.blue です。
このインテグレーションでは、1 つの run 内で複数のパーティションをマテリアライズできません。アセットをマテリアライズするには、複数の run を実行する必要があります。これは、アセットのマテリアライズ時に Dagit で実行できます。
パーティション化されたアセットに対して複数の run がある Dagster UI。各パーティションは個別の run として表示されます

高度な使い方

高度な使い方については、次の例を参照してください。

W&B Artifacts を読み込む

Dagster から Artifacts を書き込めるようになったので、以下のセクションでは、それらを後続の op や アセット への入力として使用する方法を説明します。 W&B Artifacts の読み込みは、書き込みと似ています。wandb_artifact_configuration という設定用の辞書を @op または @asset に設定できます。唯一の違いは、出力ではなく入力に設定する必要があることです。 @op の場合、これは In の metadata 引数を通じて入力メタデータ内にあります。Artifact の名を 明示的に渡す必要があります。 @asset の場合、これは Asset In metadata 引数を通じて入力メタデータ内にあります。親 アセット の名がそれと一致するはずなので、Artifact の名は渡さないでください。 インテグレーションの外部で作成された Artifact に依存させたい場合は、SourceAsset を使用する必要があります。これにより、その アセット の最新バージョンが常に読み込まれます。 以下の例は、さまざまな op から Artifact を読み込む方法を示しています。
@op から artifact を読み込む

設定

以下の設定は、IO Manager が収集し、デコレートされた関数への入力として渡す内容を指定します。以下の読み取りパターンがサポートされます。
  • Artifact 内の名前付きオブジェクトを取得するには、get を使用します。
  • Artifact に含まれるダウンロード済みファイルのローカルパスを取得するには、get_path を使用します:
  • コンテンツをローカルにダウンロードした状態で、アーティファクト オブジェクト全体を取得するには:
以下のプロパティがサポートされています:
  • get: (str) artifact の相対名で指定された W&B オブジェクトを取得します。
  • get_path: (str) artifact の相対名で指定されたファイルへのパスを取得します。

シリアライズ設定

デフォルトでは、このインテグレーションは標準のpickleモジュールを使用しますが、互換性のないオブジェクトもあります。たとえば、yieldを含む関数を pickle 化しようとするとエラーになります。 W&B は、dillcloudpicklejoblib など、他の Pickle ベースのシリアライズモジュールもサポートしています。また、シリアライズ済みの文字列を返すか、Artifact を直接作成することで、ONNXPMML のような、より高度なシリアライズ方式を使用することもできます。どの方法が適しているかはユースケースによって異なります。このテーマに関する関連文献を参照してください。

Pickle ベースのシリアライズモジュール

Pickle は安全ではないことが知られています。セキュリティが重要な場合は、W&B オブジェクトのみを使用してください。データに署名し、ハッシュキーはご自身のシステムに保存してください。より複雑なユースケースについては、W&B Support にお問い合わせください。
使用するシリアライズは、wandb_artifact_configurationserialization_module 辞書で設定できます。Dagster を実行しているマシンで、そのモジュールが利用可能であることを確認してください。 その Artifact を読み込む際、どのシリアライズモジュールを使うかはインテグレーションが自動的に判別します。 サポートされるモジュールは、pickledillcloudpicklejoblib です。 以下は、joblib でシリアライズした「モデル」を作成し、それを推論に使用する簡略化した例です。

高度なシリアライズ形式 (ONNX、PMML)

ONNX や PMML のような交換用ファイル形式は一般的です。インテグレーションはこれらの形式をサポートしていますが、Pickle ベースのシリアライズよりも少し手間がかかります。 これらの形式は、次のいずれかの方法で使用できます。
  • モデルを選択した形式に変換し、その形式の文字列表現を通常の Python オブジェクトであるかのように返します。インテグレーションはその文字列を pickle 化します。後でその文字列を使ってモデルを再構築できます。
  • シリアライズしたモデルを含む新しいローカルファイルを作成し、add_file 設定を使用して、そのファイルを含む custom Artifact を build します。
以下は、Scikit-learn モデルを ONNX を使用してシリアライズする例です。

パーティションの使用

このインテグレーションは、Dagster partitions を直接サポートしています。 アセット の 1 つ、複数、またはすべてのパーティションを選択して読み取ることができます。 すべてのパーティションは辞書として提供され、キーと値はそれぞれパーティションキーと Artifact の内容を表します。
アップストリームの @asset のすべてのパーティションを読み取ります。これらは辞書として渡されます。この辞書では、キーと値がそれぞれパーティションキーと Artifact の内容に対応します。
設定オブジェクト metadata は、W&B がproject内の異なる artifact パーティションとどのようにやり取りするかを設定します。 オブジェクト metadata には wandb_artifact_configuration というキーが含まれており、その中にネストされた partitions オブジェクトがあります。 partitions オブジェクトは、各パーティションの名をその設定にマッピングします。各パーティションの設定では、そのパーティションからデータをどのように取得するかを指定できます。これらの設定には、各パーティションの要件に応じて getversionalias などのキーを含めることができます。

設定キー

以下の設定キーがサポートされています。
  • 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 インテグレーションと W&B Launch を組み合わせて、ローカルまたはリモートで専用の計算環境上でトレーニング ジョブを実行する方法について説明します。
現在も開発中のベータ版プロダクトです。 Launch にご関心がある場合は、W&B Launch のカスタマーパイロットプログラムへの参加について、担当のアカウントチームにお問い合わせください。 ベータプログラムの対象となるには、パイロット顧客は AWS EKS または SageMaker を使用する必要があります。追加のプラットフォームも予定されています。
続行する前に、W&B Launch の使い方を理解していることを確認してください。Launch ガイドをご覧ください。 Dagster インテグレーションは、次のことに役立ちます。
  • Dagster インスタンスで 1 つ以上の Launch エージェントを実行する。
  • Dagster インスタンス内でローカルの Launch ジョブを実行する。
  • オンプレミスまたはクラウドでリモートの Launch ジョブを実行する。

Launch エージェント

このインテグレーションでは、インポートして使える run_launch_agent という @op が提供されています。これにより Launch エージェントが起動し、手動で停止するまで長時間実行されるプロセスとして動作します。 エージェントは、Launch キューをポーリングし、ジョブを順番に実行するプロセスです (または、外部サービスにディスパッチして実行します) 。 Launch ページを参照してください。 また、Launchpad では、すべてのプロパティの説明を確認できます。
Dagster インテグレーション向けのエージェント設定オプションと説明が表示された W&B Launchpad インターフェース
例:

Launch ジョブ

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

ベストプラクティス

以下の推奨事項は、インテグレーションがエンドツーエンドで動作するようになった後、その機能を最大限に活用するのに役立ちます。

IO Manager を使用して Artifacts を読み書きしてください

Artifact.download()Run.log_artifact() を直接使用することは避けてください。これらの method はインテグレーションによって処理されます。代わりに、Artifact に保存したいデータを返し、残りの処理はインテグレーションに任せてください。この方法により、Artifact のリネージがより適切になります。

複雑なユースケースでのみ、自分で Artifact object を build してください

Python オブジェクト と W&B オブジェクト は、ops と asset から返してください。Artifact のバンドルはインテグレーションが処理します。 複雑なユースケースでは、Dagster ジョブ内で直接 Artifact を build できます。ソース インテグレーション名とバージョン、使用した Python バージョン、pickle protocol バージョンなどのメタデータを拡充するため、Artifact オブジェクト をインテグレーションに渡してください。

ファイル、ディレクトリ、外部参照はメタデータ経由で Artifacts に追加してください。

インテグレーションの wandb_artifact_configuration object を使用して、任意のファイル、ディレクトリ、または外部参照 (Amazon S3、GCS、HTTP…) を追加します。詳細については、Artifact 設定セクション の高度な例を参照してください。

Artifact が生成される場合は、@op ではなく @asset を使用してください。

Artifacts は asset です。Dagster がその asset を管理する場合は、asset を使用してください。これにより、Dagit Asset Catalog での可観測性が向上します。

Dagster の外部で作成された Artifact を利用するには SourceAsset を使用してください

これにより、インテグレーションを活用して外部で作成された Artifacts を読み取れます。そうしない場合は、インテグレーションによって作成された Artifacts しか使用できません。

大規模モデルのトレーニングを専用の計算環境でオーケストレーションするには W&B Launch を使用してください

小規模なモデルは Dagster cluster 内でトレーニングでき、GPU ノードを備えた Kubernetes cluster 上で Dagster を実行することもできます。大規模なモデル トレーニングには W&B Launch を使用してください。これにより、インスタンスの過負荷を防ぎ、より適切な計算環境を利用できます。

Dagster 内で実験管理を行う場合は、W&B Run ID を Dagster Run ID の値に設定してください

Run を再開可能にし、W&B Run ID を Dagster Run ID または任意の文字列に設定することを推奨します。この推奨に従うことで、Dagster 内でモデルをトレーニングするときに、W&B メトリクスと W&B Artifacts が同じ W&B Run に保存されるようになります。 または、W&B Run ID を Dagster Run ID に設定してください:
または、任意の W&B Run ID を選択し、IO Manager の設定に渡してください:

大規模な W&B Artifacts では、get または get_path を使って必要なデータだけを取得してください。

デフォルトでは、このインテグレーションは Artifact 全体をダウンロードします。大きな Artifact を使用している場合は、必要な特定のファイルやオブジェクトだけを取得するとよいでしょう。これにより、速度とリソース利用効率が向上します。

Python オブジェクトでは、ユースケースに合わせて pickling モジュールを使い分けてください。

デフォルトでは、W&B インテグレーションは標準の pickle モジュールを使用します。ただし、一部のオブジェクトはこれに対応していません。たとえば、yield を含む関数は pickle 化しようとするとエラーになります。W&B は、他の Pickle ベースのシリアライズモジュール (dillcloudpicklejoblib) もサポートしています。 また、シリアライズ済みの文字列を返す、または Artifact を直接作成することで、ONNXPMML のような、より高度なシリアライズを使用することもできます。どれを選ぶべきかはユースケースによって異なります。このテーマに関する関連文献を参照してください。