Dagster deps 파헤치기: 자산 간 의존성 관리의 핵심

Dagster를 사용하다 보면 @dg.asset 데코레이터의 deps라는 파라미터를 심심찮게 만나게 됩니다. 겉보기엔 단순한 리스트처럼 보이지만, 이 deps는 Dagster 파이프라인의 흐름을 정의하고 관리하는 데 있어 핵심적인 역할을 수행합니다. 오늘은 이 deps의 숨겨진 힘과 그 중요성에 대해 쉽게 알아보겠습니다.

 

deps, 너는 누구냐?

@dg.asset 데코레이터 내에서 deps는 현재 정의하고 있는 자산이 어떤 다른 Dagster 자산에 의존하는지를 명시하는 파라미터입니다. 마치 레시피에서 특정 요리가 완성되기 위해 먼저 준비되어야 하는 재료와 같은 개념이라고 생각하시면 됩니다.

 

deps의 주요 역할:

1. 실행 순서의 설계자: Dagster는 deps에 정의된 의존성 정보를 바탕으로 자산들의 실행 순서를 똑똑하게 관리합니다. 특정 자산이 deps에 다른 자산을 명시하면, Dagster는 그 의존되는 자산들이 먼저 성공적으로 완료된 후에 현재 자산을 실행합니다. 데이터 파이프라인의 논리적인 흐름을 자연스럽게 코드로 표현할 수 있게 해줍니다.
2. 데이터 혈통(Lineage)의 기록자: deps는 데이터가 어떻게 생성되고 변환되는지에 대한 혈통 정보를 Dagster에게 제공합니다. Dagster UI는 이 정보를 시각적으로 표현하여 데이터의 흐름을 한눈에 파악할 수 있도록 돕습니다. 어떤 자산이 어떤 자산으로부터 만들어졌는지 명확하게 보여주어 데이터의 이해도를 높여줍니다.
3. 자동 재실행의 트리거: 만약 의존하고 있는 자산 ( deps에 명시된 자산)이 업데이트되면, Dagster는 해당 변경 사항을 감지하고 현재 자산을 자동으로 재실행하도록 스케줄링할 수 있습니다. 이는 데이터의 일관성을 유지하고 변경 사항을 파이프라인 전체에 자동으로 반영하는 데 매우 유용합니다.

예시로 이해하기: joined_data 자산

@dg.asset(
    compute_kind="duckdb",
    group_name="joins",
    deps=[sales_data, sales_reps, products],
)
def joined_data(duckdb: DuckDBResource) -> dg.MaterializeResult:
    # ... (sales_data, sales_reps, products를 조인하는 로직)
    pass

위 코드에서 joined_data 자산은 sales_data, sales_reps, products 세 개의 자산을 deps로 명시하고 있습니다. 이는 joined_data가 이 세 가지 데이터셋을 결합(join) 하여 새로운 통합된 데이터셋을 만들기 위해 이들의 결과에 의존한다는 것을 의미합니다.

 

입력 자산의 의미와 순서:

• 입력 자산을 명시하는 이유: joined_data는 판매 데이터(sales_data), 판매 담당자 정보(sales_reps), 제품 정보(products)를 논리적으로 결합하여 더 풍부한 분석이나 활용을 위한 새로운 데이터셋을 생성하기 위함입니다.
• 순서의 중요성: deps 리스트에 명시된 자산의 순서는 Dagster의 실행 순서에 직접적인 영향을 주지는 않습니다. Dagster는 의존성 그래프를 분석하여 필요한 자산이 모두 준비되면 joined_data를 실행합니다. 다만, 코드의 가독성을 위해 데이터가 생성되는 순서나 주요 조인 테이블 순서 등으로 나열하는 것이 일반적인 컨벤션입니다.

 

마무리하며:

@dg.asset의 deps 파라미터는 단순한 의존성 명시를 넘어, Dagster 파이프라인의 실행 흐름을 정의하고 데이터의 여정을 기록하며 자동 업데이트를 가능하게 하는 강력한 도구입니다. deps를 효과적으로 활용하여 더욱 체계적이고 자동화된 데이터 파이프라인을 구축해 보세요!