Seeds 소개
dimension 테이블을 파일의 형태로(csv 등) 데이터 웨어하우스에 적재하는 방법이다.
Seeds 사용 방법
-
seeds 폴더 밑에 적당히 .csv 파일을 하나 생성
-
dbt seed 명령어 실행
-
실행 결과 확인
dbt Sources
Sources : 입력 테이블에 별칭을 주고 별칭을 staging테이블에 적용하는 용도
만약 Staging 테이블을 만들 때 입력 테이블들이 자주 바뀐다면
models 밑의 .sql 파일들을 하나하나 찾아서 바꿔주어야 한다.
이 번거로움을 해결하기 위한 것이 Sources
테이블 이름들에 별칭(alias)을 주는 것이다.
dbt Snapshots
데이터베이스에서 스냅샷이란?
깃허브와 비슷한 성격!
Dimension 테이블은 성격에 따라 변경이 자주 생길 수 있음
dbt에서는 테이블의 변화를 계속적으로 기록함으로써 과거 어느
시점이건 다시 돌아가서 테이블의 내용을 볼 수 있는 기능을 이야기함
● 이를 통해 테이블에 문제가 있을 경우 과거 데이터로 롤백 가능
● 다양한 데이터 관련 문제 디버깅도 쉬워짐
SCD Type 2와 dbt (1)
Dimension 테이블에서 특정 entity에 대한 데이터가 변경되는 경우
예) employee_jobs 테이블
● 특정 employee_id의 job_code가 바뀌는 경우
● 변경시간도 같이 추가되어야함
dbt의 스냅샷 처리 방법
기존 테이블을 읽어다가 히스토리 테이블을 따로 만드는 개념.
- 먼저 snapshots 폴더에 환경설정이 됨
- snapshots을 하려면 데이터 소스가 일정 조건을 만족해야함
- Primary key가 존재해야함
- 레코드의 변경시간을 나타내는 타임스탬프 필요 (updated_at, modified_at 등등)
- 변경 감지 기준
- Primary key 기준으로 변경시간이 현재 DW에 있는 시간보다 미래인 경우
- Snapshots 테이블에는 총 4개의 타임스탬프가 존재
- dbt_scd_id, dbt_updated_at
- valid_from, valid_to
- snapshots/scd_user_metadata.sql 편집 예시
{% snapshot scd_user_metadata %} #Snapshot을 잡는 코드
{{#Snapshot을 잡는 기준
config(
target_schema='keeyong',
unique_key='user_id',
strategy='timestamp',
updated_at='updated_at',
invalidate_hard_deletes=True
)
}}
SELECT * FROM {{ source('keeyong', 'metadata') }}
{% endsnapshot %}- 결과
dbt_valid_to 컬럼이 생성 된 모습
이 곳에 히스토리 타임스템프가 들어가는 개념
테스트
user_id 99번인 여성의 나이가 변화 되었을 때 스냅샷이 어떻게 변화되는지 확인해보자.
스냅샷 진행시 업데이트 후 레이블과
변경 타임스템프가 입력된 모습 모습.
dbt Tests
Tests 소개
데이터 품질을 테스트하는 방법
두 가지가 존재한다.
- 내장 일반 테스트 (“Generic”)
- unique, not_null, accepted_values, relationships 등의 테스트 지원
- models 폴더
- 커스텀 테스트 (“Singular”)
- 기본적으로 SELECT로 간단하며 결과가 리턴되면 “실패”로 간주
- tests 폴더
LV. 1