데이터 분석가 데브코스 15주차(4)

dbt - Data Build Tool

 

 

Data Normalization

 

데이터베이스를 좀 더 조직적이고 일관된 방법으로 디자인하려는 방법

 

Normalization에 사용되는 개념

1.Primary key

2.Composite Key

3.Foreign key

 

 

단계

 

1NF(First Normal Form)

• 한 셀에는 하나의 값만 있어야 함(원자성)
• Primary Key가 있어야함
• 중복된 키나 레코드들이 없어야 함

2NF

 

• 1NF를 만족해야하며,Primary Key를 중심으로 의존결과를 알 수 있어야 한다.
• 부분적인 의존도가 없어야 한다.
  • 즉 모든 부가 속성들은 Primary Key를 가지고 찾을 수 있어야 한다.

 

3NF

• 2NF를 만족해야하며,전이적 부분 종속성이 없어야 한다.

 

Slowly Changing Dimensions

 

DW나 DL에서는 모든 테이블들의 히스토리를 유지하는 것이 중요하다.

• 보통 두 개의 timestamp필드를 갖는 것이 좋다.
  • created_at(생성시간으로 한번 만들어지면 고정)
  • updated_at(꼭 필요,마지막 수정 시간을 나타낸다.)

컬럼의 성격에 따라 SCD Type 0~4라는 유지 방법이 있다.

 

 

SCD Type 0

• 한번 쓰고 나면 바꿀 이유가 없는 경우들

SCD Type 1

• 데이터가 새로 생기면 덮어쓰면 되는 컬럼들
• 처음 레코드 생성시에는 존재하지 않았지만 나중에 생기면서 채우는 경우

SCD Type 2

• 특정 entity에 대한 데이터가 새로운 레코드로 추가되어야 하는 경우

 

SCD Type 3

• 2의 대안으로 특정 entity데이터가 컬럼이 추가되는 경우

SCD Type 4

• 특정 entity에 대한 데이터를 새로운 Dimension테이블에 저장하는 경우
• 2의 변종

 

 

 

 

OLTP(Online Transaction Processing)에서 OLAP(Online Analytical Processing)으로 데이터를 복사하는 이유

 

 

1.성능 최적화

 

2.목적의 차이

 

3.데이터의 구조 차이

 

4.트랜잭션 처리vs 분석 처리

 

5.데이터 보존 기간

 

6.백업 및 복구

 

 

 

dbt사용 해보기

 

 

구성 컴포넌트

 

데이터 모델

 

데이터 품질 검증

 

스냅샷

 

 

보통 테크 스택

 

Airflow->dbt<->RedShift

 

Airflow에서 데이터 수집 및 로드  -> dbt에서 데이터 변환 및 모델링  ->  Redshift에서 결과 로드 및 업데이트

또는 Redshift로부터 데이터를 읽어 dbt에서 데이터 변환 및 모델링

 

 

 

Fact테이블과 Dimension테이블

 

Fact 테이블

• 분석의 초점이 되는 양적 정보를 포함하는 중앙 테이블
• 일반적으로 매출 수익,판매량,이익과 같은 측정 항목 포함.비즈니스 결정에 사용
• Fact 테이블은 일반적으로 외래 키를 통해 여러 Dimension테이블과 연결된다.
• 보통 Fact테이블의 크기가 훨씬 더 크다.

Dimension테이블

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

 

 

로컬에서 dbt 실습하기

 

pip3 install dbt-redshift

 

dbt 파일

 

dbt_project.yml

models

seeds

tests

snapshots

macros

analyses

README.md

 

 

Model

 

• ELT 테이블을 만듬에 있어 기본이 되는 빌딩블록
  • 테이블이나 뷰나 CTE형태로 존재
• 입력,중간,최종 테이블을 정의하는 곳

 

• Input
  • 입력과 중간 데이터 정의
• Output
  • 최종 데이터 정의
• 모두 models 폴더 밑에 sql파일로 존재

 

 

View

 

• select 결과를 기반으로 만들어진 가상 테이블

장점

 

• 데이터의 추상화
• 데이터의 보안
• 복잡한 쿼리의 간소화

단점

 

• 매번 쿼리가 실행되므로 시간이 걸릴 수 있다.
• 원본 데이터의 변경을 모르면 실행이 실패한다.

 

 

데이터 빌딩 프로세스

 

Raw Data => (models\src\폴더 밑에 .sql파일로 저장) Staging(기본 품질 체크)=>DAG

 

Model Input

 

C:\users\사용자\dbt init learn_dbt

 

.dbt안에 profiles.yml을 만들고, learn_dbt안에 

다음과 같이 만들 수 있다.  

 

그리고  models\src\안에 

을 만들고,

dbt run을 실행하여 Model 빌딩을 한다.

 

Model Output

 

Materialization

 

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

• 보통 여기서 추가 transforamtion이나 데이터 클린업 수행
• 4가지의 내장 materialization이 제공됨
• 역시 dbt run으로 수행

 

4가지 종류

1.View

 

2.Table

 

3.Incremental(Table Appends)

 

4.Ephemeral(CTE)

 

데이터 빌딩 프로세스

 

**Jinja탬플릿이란

 

파이썬이 제공해주는 템플릿 엔진으로 Flask에서 많이 사용

 

 

models 밑에 core테이블을 위한 폴더 생성

 

dim폴더,fact폴더 생성

 

 

---

 

 

Seeds

 

많은 dimension 테이블들은 크기가 작고 많이 변하지 않음

Seeds는 이를 파일 형태로 데이터 웨어하우스로 로드하는 방법

 

 

Staging

 

models 밑의 .sql 파일들을 일일이 찾아 바꿔주어야 하는 불편함을 해결하기 위한 Sources

• 입력 테이블에 별칭을 주고 별칭을 staging테이블에서 사용

 Source 테이블들에 새 레코드가 있는지 체크해주는 기능도 제공

 

 

source 실습

 

 

 

 

Sources 최신성

• 특정 데이터가 소스와 비교해서 얼마나 최신성이 떨어지는지 체크하는 기능
• dbt source freshness 명령으로 수행
• 이를 하려면 models/source.yml의 해당 테이블 밑에 추가

 

 

 

 

최신성 실습

 

 

 

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

 

• Dimension테이블은 성격에 따라 변경이 자주 생김
• dbt에서는 테이블의 변화를 계속적으로 기록함으로써 과거 어느 시점이건 다시 돌아가서 테이블의 내용을 볼 수 있는 기능을 이야기함
  • 이를 통해 테이블에 문제가 있을 경우 과거 데이터로 롤백 가능
  • 다양한 데이터 관련 문제 디버깅도 쉬워짐

 

dbt tests

 

데이터 품질을 테스트 하는 방법

 

1.내장 일반 테스트(Generic)

• models 폴더에
•  

2.커스텀 테스트(Singular)

• tests폴더에
• 기본적으로 SELECT로 간단하며 결과가 리턴되면 실패로 간주

 

dbt Documentation

 

기본 철학은 문서와 소스 코드를 최대한 가깝게 배치하자.

1.기존 .yml파일에 문서화 추가

2.독립적인 markdown파일 생성

 

이를 경량 웹서버로 서빙

 

 

dbt Expectations

 

dbt확장판

 

설치 후 packages.yml에 등록

 

 

dbt 시각화