DBT Snapshots

 

 

 

 

 

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 Snapshots

dbt Snapshots이란 무엇인가?

 

 

 

 

 

 

 

데이터베이스에서 스냅샷이란?

 

Dimension 테이블은 성격에 따라 변경이 자주 생길 수 있음

 

dbt에서는 테이블의 변화를 계속적으로 기록함으로써 과거 어느 시점이건 다시 돌아가서 테이블의 내용을 볼 수 있는 기능을 이야기함

이를 통해 테이블에 문제가 있을 경우 과거 데이터로 롤백 가능
다양한 데이터 관련 문제 디버깅도 쉬워짐

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SCD Type 2와 dbt (1)

 

Dimension 테이블에서 특정 entity에 대한 데이터가 변경되는 경우

 

예) employee_jobs 테이블

특정 employee_id의 job_code가 바뀌는 경우 
변경시간도 같이 추가되어야함

 

 

 

 

 

 

 

 

 

 

 

 

SCD Type 2와 dbt (2)

 

Dimension 테이블에서 특정 entity에 대한 데이터가 변경되는 경우

 

새로운 Dimension 테이블을 생성 (history/snapshot 테이블)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

dbt의 스냅샷 처리 방법

 

먼저 snapshots 폴더에 환경설정이 됨

 

snapshots을 하려면 데이터 소스가 일정 조건을 만족해야함

Primary key가 존재해야함
레코드의 변경시간을 나타내는 타임스탬프 필요 (updated_at, modified_at 등등)

 

변경 감지 기준

Primary key 기준으로 변경시간이 현재 DW에 있는 시간보다 미래인 경우

 

Snapshots 테이블에는 총 4개의 타임스탬프가 존재

dbt_scd_id, dbt_updated_at
valid_from, valid_to

 

 

 

 

 

 

 

 

 

 

 

dbt snapshot 적용해보기

snapshots/scd_user_metadata.sql 편집

{% snapshot scd_user_metadata %}

{{
    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 snapshot 실행

dbt snapshot

 

 

 

 

 

 

 

 

 

 

 

 

keeyong.scd_user_metadata 확인해보기

 

 

 

 

 

 

 

 

 

 

 

 

raw_data.user_metadata 업데이트 실습 개요

 

소스 테이블의 기존 레코드 하나의 age 그룹을 변경

 

그리고 dbt snapshot 실행

 

keeyong.scd_user_metadata에 레코드 추가되었는지 확인

 

 

 

 

 

 

 

 

 

raw_data.user_metadata 업데이트 실습 (1)

소스 테이블의 기존 레코드 하나의 age 그룹을 변경

 

SELECT *
FROM raw_data.user_metadata
WHERE user_id = 99;

 

 

UPDATE raw_data.user_metadata
SET age = '20-29', updated_at = GETDATE()
WHERE user_id = 99;

 

 

 

 

 

 

 

 

 

raw_data.user_metadata 업데이트 실습 (2)

dbt snapshot 실행

 

 

 

 

 

 

 

 

 

 

raw_data.user_metadata 업데이트 실습 (3)

keeyong.scd_user_metadata에 레코드 추가되었는지 확인

SELECT * FROM keeyong.scd_user_metadata WHERE user_id = 99;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

실습

 

learn_dbt/snapshots에 scd_user_metadata.sql 파일을 생성한 다음

 

{% snapshot scd_user_metadata %}

{{
    config(
    target_schema='각자 스키마 이름',
    unique_key='user_id',
    strategy='timestamp',
    updated_at='updated_at',
    invalidate_hard_deletes=True
    )
}}

SELECT * FROM {{ source('각자 스키마 이름', 'metadata') }}

{% endsnapshot %}

 

아까 본 슬라이드와 같이 작성합니다.

 

SELECT * FROM {{ source('각자 스키마 이름', 'metadata') }}의 결과를 {{ config... 이하 조건에 맞춰 읽어내어 '각자 스키마 이름' 스키마 밑에 scd_user_metadata라는 이름의 테이블로 만들고 그 곳에 계속 기록합니다.

 

즉, dbt snapshot 명령이 실행될 때마다 {{ confi... 의 조건에 맞춰 꺼낸 레코드들을 (각자 스키마 이름).scd_user_metadata 테이블에 계속 append 합니다.

 

 

 

 

 

 

 

root 폴더에서 dbt snapshot을 실행합니다.

dbt 명령어는 가급적이면 root 폴더에서 실행하는 것을 권장합니다. temporary 파일이 실행한 폴더에 생성되어 추후에 명령을 실행할 때 문제가 발생할 가능성이 있기 때문입니다.

 

PS D:\Dev_KDT\dbt\learn_dbt> dbt snapshot

 

테이블 크기에 따라 처음 snapshot을 실행할 때 시간이 다소 소요될 수 있습니다.

 

 

 

 

 

 

 

 

postico에서 (각자의 스키마).scd_user_metadata 테이블을 확인하면

 

레코드가 들어간 것을 볼 수 있습니다.

 

현재는 dbt_valid_to는 NULL입니다. 아직은 새로 Update된 레코드가 없기 때문입니다.

 

 

 

 

 

 

 

 

확인을 위해 레코드 하나를 업데이트하겠습니다.

 

SELECT *
FROM raw_data.user_metadata
WHERE user_id = 99;

 

현재 99번은 위와 같습니다.

 

 

 

 

SELECT *
FROM (각자 스키마).scd_user_metadata
WHERE user_id = 99;

 

같은 record를 이번에는 우리가 조금 전 history 테이블로 잡은 (각자 스키마).scd_user_metadata에서 조회한다면

dbt_valid_to만 NULL인 위와 같은 결과가 나옵니다.

 

 

 

 

 

UPDATE raw_data.user_metadata
SET age = '20-29', updated_at = GETDATE()
WHERE user_id = 99;

 

그리고 99번 user의 나이가 한살 늘어 0-19에서 20-29가 되었다고 가정하고 위와 같이 업데이트합니다.

지금은 실습을 위해 직접 update를 진행했지만 보통은 ETL 프로세스가 레코드들을 업데이트 해줍니다.

 

 

 

 

 

 

 

다시 터미널에서 dbt snapshot을 실행합니다.

 

 

 

 

 

 

다시 postico에서 히스토리 테이블이 어떻게 조회되는지 확인하겠습니다.

 

이제는 age가 0-19일 때 dbt_valid_to가 NULL에서 현재 시간으로 기입되어 있고 20-29는 최신 레코드이므로 NULL인 것을 볼 수 있습니다.