DBT - 사용 시나리오

 

Contents

1. ELT의 미래는?
2. Database Normalization
3. dbt 소개
4. dbt 사용 시나리오
5. dbt 설치와 환경 설정
6. dbt Models: Input
7. dbt Models: Output
8. dbt Seeds
9. dbt Sources
10. dbt Snapshots
11. dbt Tests
12. dbt Documentation
13. dbt Expectations
14. 마무리

 

 

 

 

 

 

 

 

 

 

 

dbt 소개

Data Build Tool이 무엇인지 알아보자

 

 

 

 

 

dbt란 무엇인가?

 

 

 

Data Build Tool (https://www.getdbt.com/)

ELT용 오픈소스: In-warehouse data transformation
dbt Labs라는 회사가 상용화 ($4.2B valuation)
Analytics Engineer라는 말을 만들어냄

다양한 데이터 웨어하우스를 지원

Redshift, Snowflake, Bigquery, Spark

 

클라우드 버전도 존재

dbt Cloud

 

 

 

 

 

 

 

 

 

 

 

 

dbt가 서포트해주는 데이터 시스템

BigQuery
Redshift
Snowflake
Spark
…

 

 

 

 

 

 

 

 

 

 

dbt 구성 컴포넌트

 

 

 

데이터 모델 (models)

테이블들을 몇개의 티어로 관리
- 일종의 CTAS (SELECT 문들), Lineage 트래킹
Table, View, CTE 등등

 

데이터 품질 검증 (tests)

 

스냅샷 (snapshots)

 

 

 

 

 

 

 

 

 

 

 

 

dbt 사용 시나리오

dbt가 어떻게 사용될 수 있는지 가상 환경을 생각해보자

 

 

 

 

 

 

 

다음과 같은 요구조건을 달성해야한다면?

데이터 변경 사항을 이해하기 쉽고 필요하다면 롤백 가능

데이터간 리니지 확인 가능

데이터 품질 테스트 및 에러 보고

Fact 테이블의 증분 로드 (Incremental Update)

Dimension 테이블 변경 추적 (히스토리 테이블)

용이한 문서 작성

 

 

 

 

 

 

 

 

 

보통 사용하는 테크 스택

 

Redshift/Spark/Snowflake/BigQuery
dbt
Airflow

 

 

 

 

 

 

 

 

 

 

 

 

무슨 ELT 작업을 해볼까요?

 

Redshift 사용

 

AB 테스트 분석을 쉽게 하기 위한 ELT 테이블을 만들어보자

 

입력 테이블:

user_event, user_variant, user_metadata

 

생성 테이블: Variant별 사용자별 일별 요약 테이블

variant_id, user_id, datestamp, age, gender,
총 impression, 총 click, 총 purchase, 총 revenue

 

 

 

 

 

 

 

 

 

 

 

 

 

 

입력 데이터들

 

Production DB에 저장되는 정보들을 Data Warehouse로 적재했다고 가정

 

raw_data.user_event

사용자/날짜/아이템별로 impression이 있는 경우 그 정보를 기록하고 impression으로부터 클릭, 구매, 구매시 금액을 기록. 실제 환경에서는 이런 aggregate 정보를 로그 파일등의 소스(하나 이상의 소스가 될 수도 있음)로부터 만들어내는 프로세스가 필요함

 

raw_data.user_variant

사용자가 소속한 AB test variant를 기록한 파일 (control vs. test)

 

raw_data.user_metadata

사용자에 관한 메타 정보가 기록된 파일 (성별, 나이 등등)

 

 

 

 

 

 

 

 

 

입력데이터: raw_data.user_event

 

 

CREATE TABLE raw_data.user_event (
    user_id int,
    datestamp timestamp,
    item_id int,
    clicked int,
    purchased int,
    paidamount int
);

 

 

 

 

 

 

 

 

 

 

입력데이터: raw_data.user_variant

 

CREATE TABLE raw_data.user_variant (
    user_id int,
    variant_id varchar(32) -- control vs. test
);

보통은 experiment와 variant 테이블이 별도로 존재함
그리고 위의 테이블에도 언제 variant_id로 소속되었는지 타임스탬프 필드가 존재하는 것이 일반적

 

 

 

 

 

 

 

입력데이터: raw_data.user_metadata

 

CREATE TABLE raw_data.user_metadata (
    user_id int,
    age varchar(16),
    gender varchar(16)
);

사용자별 메타정보: 이를 이용해 다양한 각도에서 AB 테스트 결과를 분석해볼 수 있음

 

 

 

 

 

 

 

 

 

 

 

 

Fact 테이블과 Dimension 테이블

 

Fact 테이블: 분석의 초점이 되는 양적 정보를 포함하는 중앙 테이블

일반적으로 매출 수익, 판매량, 이익과 같은 측정 항목 포함. 비즈니스 결정에 사용
Fact 테이블은 일반적으로 외래 키를 통해 여러 Dimension 테이블과 연결됨
보통 Fact 테이블의 크기가 훨씬 더 큼

 

Dimension 테이블: Fact 테이블에 대한 상세 정보를 제공하는 테이블

고객, 제품과 같은 테이블로 Fact 테이블에 대한 상세 정보 제공
Fact 테이블의 데이터에 맥락을 제공하여 다양한 방식으로 분석 가능하게 해줌
Dimension 테이블은 primary key를 가지며, fact 테이블에서 참조 (foreign key)
보통 Dimension 테이블의 크기는 훨씬 더 작음

 

 

 

 

 

 

 

 

 

 

입력 데이터 요약

user_event, user_variant, user_metadata

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

최종 생성 데이터 (ELT 테이블)

SELECT로 표현하면 아래와 같음

 

SELECT 
    variant_id,
    ue.user_id,
    datestamp,
    age,
    gender,
    COUNT(DISTINCT item_id) num_of_items, -- 총 impression
    COUNT(DISTINCT CASE WHEN clicked THEN item_id END) num_of_clicks, -- 총 click
    SUM(purchased) num_of_purchases, -- 총 purchase
    SUM(paidamount) revenue -- 총 revenue
FROM raw_data.user_event ue 
JOIN raw_data.user_variant uv ON ue.user_id = uv.user_id
JOIN raw_data.user_metadata um ON uv.user_id = um.user_id
GROUP by 1, 2, 3, 4, 5;