Lineage — 모든 숫자 어디서 왔는지 알기

모든 임원이 결국 묻는 질문

"왜 이 숫자 바뀌었어?" 가 성공한 데이터 팀을 신뢰받는 데이터 팀으로 바꾸는 질문. 답하는 데 lineage 필요 — 모든 출력의 모든 column 이 upstream source 에서 어떻게 흘렀는지 보여주는 그래프. 테이블 수준 ("이 대시보드는 이 mart 에서 읽음"), column 수준 ("대시보드의 revenue 가 fct_orders 의 amount_usd 에서 옴"), 이상적으론 row 수준 ("이 row 의 값은 2026-04-30 03:14 UTC run 에서 설정됨").

오늘 lineage 주는 것

dbt 의 docs 사이트 가 모든 model 에 대해 lineage 그래프 렌더. Model 클릭, 뭐가 feed 하고 뭐가 의존하는지 봄.
Dagster 가 lineage 를 orchestration 으로 모델링. 모든 asset 의 upstream + downstream 이 first-class.
OpenLineage 가 어떤 파이프라인 framework 에서든 lineage 이벤트 emit 하는 emerging open 표준. Airflow, Dagster, Spark, Flink 다 OpenLineage 통합 있음.
Marquez / DataHub / OpenMetadata 가 OpenLineage 통해 emit 된 lineage 저장 + 시각화 하는 오픈소스 platform.

도구 아니라 규율

도구가 그래프 줘; 규율은 그래프가 의미 있게 transformation 구조화 하는 거. 모든 mart 가 staging layer 에 의존하고 모든 staging layer 가 source 에 의존하는 dbt 프로젝트는 깔끔한 lineage 생산. 모든 거 한 거대 CTE chain 에서 하는 dbt 프로젝트는 사실이지만 쓸모없는 lineage 그래프 생산.

Code

구조에 의한 lineage — staging → intermediate → marts 가 작동 패턴·text

models/
├── staging/                 # source 테이블과 1:1, 가벼운 rename + cast
│   └── stg_orders.sql       #     SELECT FROM {{ source('raw', 'orders') }}
├── intermediate/             # join, derive, 재사용되는 비즈니스 로직
│   └── int_orders__joined.sql
└── marts/                    # consumer-facing 테이블 (비즈니스 영역당 폴더)
    ├── core/
    │   ├── dim_customers.sql
    │   └── fct_orders.sql
    └── revenue/
        └── monthly_revenue.sql

# 이 구조가 dbt lineage 그래프에 깔끔한 left-to-right flow 로 나타남.
# Layer 건너뛰면 그래프가 아무도 디버깅 못 하는 hairball 됨.

Lineage — 모든 숫자 어디서 왔는지 알기

모든 임원이 결국 묻는 질문

오늘 lineage 주는 것

도구 아니라 규율

Code

External links

Exercise

Progress

댓글 0