- W&B Artifact를 생성하고 사용할 수 있습니다.
- W&B Registry에서 Registered Models를 사용하고 생성할 수 있습니다.
- W&B Launch를 사용해 전용 컴퓨팅 리소스에서 트레이닝 작업을 실행할 수 있습니다.
- ops와 asset에서 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 프로젝트: W&B Runs가 저장되는 프로젝트 이름입니다.
API 키 설정
- W&B에 로그인합니다. 참고: W&B Server를 사용하는 경우 관리자에게 인스턴스 호스트 이름을 문의하세요.
- User Settings에서 API 키를 생성합니다. 프로덕션 환경에서는 해당 키를 service account에서 소유하도록 설정하는 것을 권장합니다.
- 해당 API 키에 대한 환경 변수를 설정합니다:
export WANDB_API_KEY=YOUR_KEY.
wandb_config 중첩 딕셔너리 안에 entity와 프로젝트 이름을 반드시 지정하세요. 다른 W&B 프로젝트를 사용하려면 op/asset마다 서로 다른 wandb_config 값을 전달할 수 있습니다. 전달할 수 있는 키에 대한 자세한 내용은 아래 설정 섹션을 참조하세요.
- `@job`용 설정
- assets를 사용하는 `@repository`용 설정
예:
@job용 설정설정
wandb_resource: W&B API와 통신하는 데 사용하는 Dagster resource입니다. 제공된 API 키로 자동 인증됩니다. 속성:api_key: (str, 필수): W&B API와 통신하는 데 필요한 W&B API 키입니다.host: (str, 선택): 사용할 API 호스트 서버입니다. W&B Server를 사용하는 경우에만 필요합니다. 기본값은 Public Cloud 호스트인https://api.wandb.ai입니다.
wandb_artifacts_io_manager: W&B Artifacts를 사용하기 위한 Dagster IO Manager입니다. 속성:base_dir: (int, 선택) 로컬 저장소와 캐싱에 사용하는 기본 디렉터리입니다. W&B Artifacts와 W&B Run 로그는 해당 디렉터리에 기록되고, 해당 디렉터리에서 읽어 옵니다. 기본적으로DAGSTER_HOME디렉터리를 사용합니다.cache_duration_in_minutes: (int, 선택) W&B Artifacts와 W&B Run 로그를 로컬 저장소에 유지할 시간을 정의합니다. 해당 시간 동안 열리지 않은 파일과 디렉터리만 캐시에서 제거됩니다. 캐시 정리는 IO Manager 실행이 끝날 때 수행됩니다. 캐싱을 완전히 끄려면 0으로 설정할 수 있습니다. 캐싱은 동일한 머신에서 실행되는 작업 간에 Artifact를 재사용할 때 속도를 높여 줍니다. 기본값은 30일입니다.run_id: (str, 선택): 재개에 사용하는 이 run의 고유 ID입니다. 프로젝트 내에서 고유해야 하며, run을 삭제하면 해당 ID를 다시 사용할 수 없습니다. 짧은 설명용 이름에는 name 필드를 사용하고, runs 간 비교를 위해 하이퍼파라미터를 저장하려면 config를 사용하세요. ID에는 다음 특수 문자를 포함할 수 없습니다:/\#?%:..Dagster 내에서 실험 추적을 수행할 때는 IO Manager가 run을 재개할 수 있도록 Run ID를 설정해야 합니다. 기본적으로 Dagster Run ID(예:7e4df022-1bf2-44b5-a383-bb852df4077e)로 설정됩니다.run_name: (str, 선택) UI에서 이 run을 쉽게 파악할 수 있도록 지정하는 짧은 표시 이름입니다. 기본적으로 다음 형식의 문자열입니다:dagster-run-[8 first characters of the Dagster Run ID]. 예:dagster-run-7e4df022.run_tags: (list[str], 선택): UI에서 이 run의 태그 목록을 채우는 문자열 목록입니다. 태그는 runs를 함께 구성하거나baseline또는production같은 임시 레이블을 적용하는 데 유용합니다. UI에서 태그를 쉽게 추가하거나 제거할 수 있고, 특정 태그가 있는 runs만 필터링할 수도 있습니다. 인테그레이션에서 사용하는 모든 W&B Run에는dagster_wandb태그가 포함됩니다.
W&B Artifacts 사용
@op 또는 @asset에서 W&B Artifacts를 기본적으로 생성하고 사용할 수 있습니다. 다음은 Python 목록을 포함하는 데이터셋 유형의 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 모듈로 직렬화할 수 있는 모든 항목은 피클링되어 인테그레이션이 생성한 Artifact에 추가됩니다. Dagster 내에서 해당 Artifact를 조회하면 콘텐츠가 언피클링됩니다(자세한 내용은 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의 경우 AssetOut의 metadata 인자를 통해 각 출력 metadata에 위치합니다.
다음 코드 예제는 @op, @asset, @multi_asset 컴퓨팅에 딕셔너리를 설정하는 방법을 보여줍니다.
- @op 예제
- @asset 예제
- @multi_asset 예제
@op 예제:name: (str) 이 artifact를 사람이 읽기 쉬운 이름으로, UI에서 이 artifact를 식별하거나use_artifactcalls에서 참조할 때 사용합니다. 이름에는 문자, 숫자, 밑줄, 하이픈, 점을 포함할 수 있습니다. 이름은 프로젝트 전체에서 고유해야 합니다.@op에 필요합니다.type: (str) artifact를 구성하고 구분하는 데 사용하는 artifact의 유형입니다. 일반적인 유형으로는 dataset 또는 model이 있지만, 문자, 숫자, 밑줄, 하이픈, 점을 포함하는 임의의 문자열을 사용할 수 있습니다. 출력이 이미 Artifact가 아닌 경우 필요합니다.description: (str) artifact에 대한 설명을 제공하는 자유 텍스트입니다. 설명은 UI에서 마크다운으로 렌더링되므로 표, 링크 등을 넣기에 적합합니다.aliases: (list[str]) Artifact에 적용할 하나 이상의 alias를 포함하는 배열입니다. 설정 여부와 관계없이 인테그레이션은 이 목록에 “latest” 태그도 추가합니다. 이는 모델과 데이터셋의 versioning을 관리하는 효과적인 방법입니다.add_dirs: (list[dict[str, Any]]): Artifact에 포함할 각 로컬 디렉터리에 대한 설정을 담은 배열입니다.add_files: (list[dict[str, Any]]): Artifact에 포함할 각 로컬 파일에 대한 설정을 담은 배열입니다.add_references: (list[dict[str, Any]]): Artifact에 포함할 각 외부 Reference에 대한 설정을 담은 배열입니다.serialization_module: (dict) 사용할 직렬화 모듈의 설정입니다. 자세한 내용은 Serialization 섹션을 참고하세요.name: (str) 직렬화 모듈의 이름입니다. 허용되는 값:pickle,dill,cloudpickle,joblib. 이 모듈은 로컬에서 사용할 수 있어야 합니다.parameters: (dict[str, Any]) 직렬화 함수에 전달되는 선택 인수입니다. 이 모듈의 dump method와 동일한 parameters를 받습니다. 예를 들어{"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 프로젝트




mypy와 같은 정적 유형 검사기를 사용하는 경우, 설정 유형 정의 객체를 다음과 같이 임포트하세요:
파티션 사용
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 argument를 통해 입력 메타데이터에 설정합니다. Artifact 이름을
명시적으로 전달해야 합니다.
@asset의 경우 Asset In metadata argument를 통해 입력 메타데이터에 설정합니다. 상위 asset의 이름이 Artifact 이름과 일치해야 하므로 Artifact 이름을 전달하면 안 됩니다.
인테그레이션 외부에서 생성된 Artifact에 대한 종속성을 두려면 SourceAsset을 사용해야 합니다. 이 경우 항상 해당 asset의 최신 버전을 조회합니다.
다음 예제에서는 여러 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하려고 하면 오류가 발생합니다.
추가적인 Pickle 기반 직렬화 모듈(dill, cloudpickle, joblib)도 지원합니다. 직렬화된 문자열을 반환하거나 Artifact를 직접 생성해 ONNX나 PMML 같은 더 고급 직렬화 방식도 사용할 수 있습니다. 어떤 방식을 선택할지는 사용 사례에 따라 다르므로, 이 주제에 관한 관련 문헌을 참고하세요.
Pickle 기반 직렬화 모듈
wandb_artifact_configuration의 serialization_module 딕셔너리를 통해 사용할 직렬화 방식을 설정할 수 있습니다. 해당 모듈을 Dagster를 실행하는 머신에서 사용할 수 있는지 반드시 확인하세요.
이 인테그레이션은 해당 Artifact를 조회할 때 어떤 직렬화 모듈을 사용해야 하는지 자동으로 판단합니다.
현재 지원되는 모듈은 pickle, dill, cloudpickle, joblib입니다.
다음은 joblib으로 직렬화한 “모델”을 만든 다음 이를 Inference에 사용하는 간단한 예시입니다.
고급 직렬화 형식(ONNX, PMML)
- 모델을 선택한 형식으로 변환한 다음, 일반적인 Python 객체인 것처럼 해당 형식의 문자열 표현을 반환합니다. 그러면 인테그레이션이 해당 문자열을 pickle합니다. 그런 다음 그 문자열을 사용해 모델을 다시 구성할 수 있습니다.
- 직렬화된 모델이 들어 있는 새 로컬 파일을 만든 다음, add_file 설정을 사용해 해당 파일로 맞춤형 Artifact를 생성합니다.
파티션 사용
- 모든 파티션 조회
- 특정 파티션 조회
업스트림
@asset의 모든 파티션을 조회하며, 이는 딕셔너리 형태로 제공됩니다. 이 딕셔너리에서 키와 값은 각각 파티션 키와 Artifact 콘텐츠에 해당합니다.metadata는 프로젝트에서 W&B가 서로 다른 artifact 파티션과 상호작용하는 방식을 정의합니다.
metadata 객체에는 wandb_artifact_configuration라는 키가 있으며, 그 안에 중첩된 partitions 객체가 들어 있습니다.
partitions 객체는 각 파티션 이름을 해당 설정에 매핑합니다. 각 파티션의 설정에서는 해당 파티션에서 데이터를 어떻게 조회할지 지정할 수 있습니다. 이러한 설정에는 각 파티션의 요구 사항에 따라 get, version, alias 등의 키가 포함될 수 있습니다.
설정 키
get:get키는 데이터를 가져올 W&B 객체(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 인스턴스에서 하나 이상의 Launch 에이전트를 실행합니다.
- Dagster 인스턴스 내에서 로컬 Launch 작업을 실행합니다.
- 온프레미스 또는 클라우드에서 원격 Launch 작업을 실행합니다.
Launch 에이전트
@op인 run_launch_agent를 제공합니다. 이 @op는 Launch 에이전트를 시작하고, 수동으로 중지할 때까지 장기 실행 프로세스로 실행합니다.
에이전트는 Launch 큐를 폴링하며, 작업을 순서대로 실행하는 프로세스입니다(또는 외부 서비스가 실행하도록 작업을 디스패치합니다).
Launch 페이지를 참고하세요.
Launchpad에서는 모든 속성에 대한 유용한 설명도 확인할 수 있습니다.

Launch 작업
run_launch_job이라는 임포트할 수 있는 @op를 제공합니다. 이 @op는 Launch 작업을 실행합니다.
Launch 작업을 실행하려면 큐에 할당되어 있어야 합니다. 큐를 생성하거나 기본 큐를 사용할 수 있습니다. 해당 큐를 모니터링하는 활성 에이전트가 있는지 확인하세요. Dagster 인스턴스 내에서 에이전트를 실행할 수 있으며, Kubernetes에 배포 가능한 agent를 사용하는 방법도 고려할 수 있습니다.
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에 파일, 디렉터리, 외부 참조를 추가하세요.
파일, 디렉터리 또는 외부 참조(Amazon S3, GCS, HTTP…)를 추가하려면 인테그레이션
wandb_artifact_configuration객체를 사용하세요. 자세한 내용은 Artifact configuration section의 고급 예제를 참조하세요. - 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 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 객체의 경우 사용 사례에 맞게 피클링 모듈을 조정하세요. 기본적으로 W&B 인테그레이션은 표준 pickle 모듈을 사용합니다. 하지만 일부 객체는 이 모듈과 호환되지 않습니다. 예를 들어, yield를 사용하는 함수는 pickle하려고 하면 오류가 발생합니다. W&B는 다른 Pickle 기반 직렬화 모듈(dill, cloudpickle, joblib)도 지원합니다.
