간단한 DBT 실습해보기 (with Redshift) - TIL230622(2)

📚 KDT WEEK 12 DAY 4 TIL

• Data Build Tool (DBT)
• DBT 간단한 실습

 

---

 

🟥 Data Build Tool

 

 

ELT용 오픈소스 (In-warehouse data transformation)

다양한 데이터 웨어하우스를 지원(Redshift, Snowflake, Bigquery...)

 

• 데이터 변경 사항을 이해하기 쉽고 롤백도 가능
• 데이터간 리니지 확인 가능
• 데이터 품질 테스트 및 에러 보고
• 히스토리 테이블로 테이블 변경 추적

 

데이터 웨어하우스위에 DBT를 올리고, DBT를 주기적으로 실행하기 위해 Airflow를 사용하는게 일반적

 

📦 DBT 구성 컴포넌트 : 데이터 모델(models), 데이터 품질 검증(tests), 스냅샷(snapshots)

 

---

 

DBT 설치(redshift)

 

pip3 install dbt-redshift # 안되면 sudo

# 설치후
dbt init learn_dbt

 

dbt init 과정에서 redshift 연결 정보를 입력하면 된다.

 

연결 완료 후에는 dbt init 뒤에 입력한 이름으로 폴더가 하나 생성된다.

 

생성된 폴더의 내용물

 

여기에 생성된 dbt_project.yml에 환경 정보가 저장된다.

이 파일에 SQL을 통해 저장되는 데이터가 DB에 table이나 view 등으로 저장될지 설정할 수 있다.

이 부분은 아래의 Materialization 설명에서 다룬다!

 

---

 

🧱 Model

ELT 테이블을 만들기 위해 기본이 되는 빌딩 블록 (테이블, 뷰, CTE)

models 폴더안에 SQL 문을 작성하여 DB에 데이터를 적재하게 된다.

 

보통 ELT 과정은 raw -> staging -> core 형태로 진행된다.

 

Input으로 입력(raw)와 중간(staging, src) 데이터가 정의되어,

Output으로 최종(core) 데이터가 나타나는 형태로 진행된다.

 

보통 raw는 CTE, staging View, core는 Table로 저장된다.

 

⚒️ Materialization

입력 데이터(테이블)들을 연결해서 새로운 데이터(테이블)을 생성하는 것

파일이나 프로젝트 레벨에서 가능

 

Materialization 종류 : View, Table, Incremental(Table Appends), Ephemeral(CTE)

 

데이터 사용 주기와 수정 유무에 따라 종류를 결정하게 되는데, 이는 dbt_project.yml에 작성한다.

 

model의 materialized format 결정하는 방법

 

dbt_project.yml 내용 일부를 편집하면 된다.

 

ex)  example 폴더 밑에 있는 테이블들은 모두 view로 빌드

models:
  learn_dbt:
    # Config indicated by + and applies to all files under models/example/
    example:
      +materialized: view

 

ex) learn_dbt 프로젝트의 테이블들은 기본적으로 view 빌드하지만, dim 폴더 밑으로는 모두 table로 빌드

models:
  learn_dbt:
    +materialized: view
    dim:
      +materialized: talbe

 

---

 

🟦 실습

 

1. INPUT 만들기

 

dbt_project.yml 에서 필요없는 example의 +materialized 부분을 삭제하고 example 폴더도 삭제했다.

 

그리고 src로 사용할 데이터를 가져오기 위해 models/src/ 에 sql 파일을 만들어준다.

내 Redshift의 raw_data 스키마에 저장된 user_event, user_metadata, user_variant 데이터의 특정 컬럼을 가져오게된다.

 

각각의 테이블의 내용은 이렇다.

• user_event : 사용자의 행동 정보 (구매여부 등)
• user_metadata : 사용자의 정보 ( 나이, 성별 등)
• user_variant : 각 사용자의 AB 테스트 구분 (어떤 사용자가 A인지, B인지)

 

CTE를 통해 SQL 문을 구축했다.

 

그리고 dbt 루트 폴더에서 dbt run 명령어를 실행시켜보면,

3개의 모델을 찾아 SQL을 실행하고 VIEW를 만들었다는 결과를 확인할 수 있다.

 

dbt run 실행 결과

 

이로써 세 개의 INPUT을 만들게 된 것이다.

 

2. OUTPUT 만들기

 

models 폴더에 dim, fact 폴더를 각각 생성하고, 안에 SQL 파일을 넣는다.

dim에는 Dimension 테이블이, fact에는 Fact 테이블이 생성되는 SQL파일이 들어가게 될 것이다.

 

• Fact 테이블 : 매출 수익, 판매량, 사용자의 행동 정보같은 분석에 필요한 메인 데이터 테이블
• Dimension 테이블 : Fact 테이블에 대한 상세 정보를 제공하는 테이블 ( ex. 사용자의 나이 등)

내 테이블의 경우 사용자의 행동을 담고있는 user_event 가 Fact 테이블이되고, 나머지가 Dimension 테이블이 된다.

 

Dimension 테이블의 경우 src때와 비슷하게 작성한다.

WITH 절에 사용한 ref(테이블이름)은 내 DB에 있는 해당 테이블을 가져와서 읽어올 수 있다.

 

user_variant

 

fact 테이블에 해당하는 user_event의 경우 Incremental (데이터 매번 갱신이 아닌 계속 삽입)하게 만들었다.

이를 CTE 위에 템플릿 형식에다 config를 사용한다.

on_schema_change는 해당 테이블의 스키마가 바뀌었을 때 어떻게 처리할지 설정한다.

'fail'의 경우 깔끔하게 실패하는 방법이다.

 

그리고 Incremental하게 동작하기 위해 WHERE문을 통해 datestamp가 가장 최근인 데이터에 한해서만 Insert를 수행하도록 작성했다.

 

그리고 글을 작성할 때는 WHERE을 포함하지 않고 한번 실행했다가 WHERE절을 넣고 실행했는데,

내 생각에 WHERE절이 포함된 상태로 처음 실행하면 fact_user_event 테이블에 내용이 안담길것같다..

그러니 최초 실행할 때는 WHERE절없이 한번 실행해야 되지 않을까?

 

fact_user_event의 경우 조금 다르다.

 

그리고 dbt_project.yml 파일에서 기본 생성형을 다음과 같이 바꿔주었다.

이로써 기본 생성형은 view, dim 폴더 밑으로는 table로 생성하게 된다.

 

 

참고로 위 이미지처럼 주석으로 한글을 달아두면 dbt compile할 때 인코딩 오류가 발생한다ㅠ

그래서 이미지만 생성하고 주석은 바로 지웠다ㅠ

 

dbt_project.yml 편집까지 끝나면 dbt run을 실행해보자.

fact와 dim은 table로, src에서는 view로 생성되었다. (incremental도 table)

 

밑줄친 곳을 보면, fact_user_event가 incremental 처리되었다

 

잘 생성되었는지 Colab에서 확인해보니, 생성된 view와 table을 확인할 수 있었다.

 

테이블들을 확인해보니 잘 넘어왔다.

 

3. analytics 해보기

 

dim의 두 테이블을 조인한 user 테이블을 만들어보자.

사실 JOIN만 들어갔을 뿐, 아까 dim 폴더의 SQL을 만드는 과정과 똑같다.

 

dim_user.sql

 

이외의 analytics는 위에서 작성한 것처럼 자유롭게 저장한 테이블을 불러와서 SQL문을 작성하기만 하면 된다!

 

++ 고칠부분

src 폴더의 SQL의 경우 꼭 View일 필요없이 CTE로 충분하다고 한다.

dbt_project.yml을 간단히 수정하기만 하면 되는 일이다!