song-ps

dbt_main

3 min read

dbt

근본적인 장점은, SQL transformation을 소프트웨어 개발처럼 관리한다는 것에 있다.

SQL 간 의존관계 / 테스트 / 재사용 / 실행범위 / 물리화 방식을 하나의 모델링 체계로 만드는 것이 목적.

  • dbt 공식 문서 기준:
    • 모델
    • 테스트
    • lineage
    • state-aware build
    • Semantic Layer

dbt 라는 추상화 레이어를 하나 두는 것으로, 아래와 같은 이득을 얻을 수 있다.

  • SQL 형상관리
  • 협업 환경
  • 가독성 개선

dbt 의 오케스트레이션을 위해 airflow 가 사용될 수 있다.

디렉터리역할실제 DB 객체 생성 여부주 사용 시점
models/실행용 SQL 보관경우에 따라
analyses/실행용이 아닌 분석 SQL 보관X임시 분석/리포트 SQL
logs/dbt 실행 로그 저장X디버깅
macros/Jinja macro/재사용 SQL 함수XSQL 템플릿화
seeds/CSV를 테이블로 적재O작은 기준정보/코드테이블
snapshots/변경 이력 추적(SCD Type 2)O원본 레코드 변경 이력
target/compile/run 결과 artifactXcompiled SQL, manifest 등
tests/custom data test SQL자체는 보통 X데이터 품질 검증
# 실제 테이블로 저장. 데이터가 자주 변경되지 않고, 쿼리 성능이 중요할 경우 사용
{{ config(materialized='table') }} 
 
# 쿼리를 뷰로 저장. 저장 공간을 절약할 수 있지만, 쿼리 성능이 떨어질 수 있음. 다만 원본 데이터가 바뀌면 바로 볼 수 있음(최신 데이터 확인 가능)
{{ config(materialized='view') }}
 
# 테이블에 새로운, 변경된 데이터만 추가함
{{ config(materialized='incremental') }}
 
# 실제로 물리화되지 않고, 다른 모델에서 참조될 때 서브 쿼리로 사용
{{ config(materialized='view') }}
  • Snowflake + dbt에서 materialized='view'라면, 그 모델이 dbt run 대상에 포함될 때마다 view 정의를 다시 적용한다.

macros

  • 서로 다른 dbt project 간에 통용되는 1개의 macro
dbt-common-macros/
├── dbt_project.yml
└── macros/
    └── date_interval_filter.sql

project-a/
├── dbt_project.yml
├── packages.yml
└── models/

project-b/
├── dbt_project.yml
├── packages.yml
└── models/
방법가능 여부권장도특징
각 프로젝트에 macro 복붙O낮음수정 시 모든 프로젝트 변경 필요
공용 Git dbt packageO높음버전 관리/재사용 용이
하나의 Snowflake SQL UDF로 구현O경우에 따라dbt compile logic에는 부적합
Snowflake stored procedureO낮음macro와 역할이 다름

Graph View