[데이터 엔지니어링 데브코스 2기] TIL-12주차 DBT 소개, 데이터 디스커버리, 툴 학습 (1)

1. Airflow 로그 파일 삭제하기

---

Airflow 로그 파일은 용량이 크기 때문에 주기적으로 삭제 및 백업을 해야 함.

로그 위치.

• base_log_folder와 child_process_log_directory 라는 두 개의 폴더에 로그 파일이 저장됨.
• docker compose의 경우, 호스트 볼륨으로 존재. (ARIFLOW_PROJ_DIR)

2. Airflow 메타데이터 백업하기

---

airflow metadata database를 airflow 밖의 db에서 실행하는 것이 가장 좋음. RDS.

• 하지만 airflow의 서버 내에서 메타 데이터 디비가 있다면, DAG 등을 이용해 주기적인 백업을 실행해야 함(ex, S3로 저장하기.).

Airflow의 대안?

• Prefect, Dagster, Airbyte, Five Tran 등이 있으나 Airflow가 가장 좋음.

3. dbt

---

데이터 품질의 중요성.

• 입출력 체크.
• 리니지 체크.
• 데이터 히스토리 파악.
• 데이터 품질 유지 -> 비용 절감.
• 이를 위한 툴이 dbt(Data Build Tool)임.

Data Nomralization.

• 데이터베이스를 일관적으로 디자인하는 방법.
• 주요 개념 : Primary Key, Foreign Key, Composite Key.
• 여러 Normal Form이 존재함.

1NF.

• atomic 해야 함.
• Primary Key 존재.
• 중복된 레코드나 키가 존재하면 안 됨.

2NF.

• 1NF를 만족함.
• Star Schema 만족.

3NF.

• 2NF를 만족함.
• 전이적 부분 종속성이 없어야 함.

SCD (Slowly Changing Dimenstion).

• created_at, updated_at과 같은 히스토리를 갖고 있음.
• OLTP(Production DB) -> OLAP(Data Warehouse)의 과정 중, 일부 데이터는 속성이 변하는데 이를 DW에 어떻게 반영할지? -> dbt가 SCD를 보장해 줌. -> 특정 테이블의 히스토리가 알아서 쌓임.

SCD type 0.

• 한 번 정해지면 갱신되지 않고 고정되는 필드들.
• 예) 회원 등록일, 제품 첫 구매일.

SCD type 1.

• 처음 레코드 생성 시에는 데이터가 없지만 나중에 생기면서 한 번만 갱신하는 필드.
• 예) 연간 소득.

SCD type 2.

• 특정 엔터티에 대한 데이터가 새로운 레코드로 갱신되어야 하는 경우.
• 예) 고객 등급.
• 변경 시간도 같이 추가되어야 함.
• 값의 변경을 tracking할 수 있음.

SCD type 3.

• SCD 2와 상황은 유사함.
• 레코드를 변경하는 대신 별도의 칼럼 생성.

SCD type 4.

• 별도의 dimension 테이블에 값의 변경을 따로 저장.
• 대표 테이블은 현재의 값만 저장.
• 가장 보편적인 방법..
• dbt가 히스토리 형태로 만들어 줌.

dbt 구성 컴포넌트.

• dbt를 사용하면 여러 폴더가 생성됨.
• 데이터 모델(models) : 테이블을 티어별로 정리(raw -> staging -> core). 일종의 CTAS.
• 데이터 품질 검증(tests)
• 스냅샷(snapshots)

dbt의 장점.

• 데이터 변경 사항 파악 가능.
• 롤백 가능.
• 데이터 간 리니지 확인 가능.
• 데이터 품질 테스트 및 에러 보고.
• Incremental Update 가능.
• 히스토리 테이블.
• 문서화 용이.
• airflow -> dbt <-> DW.

Fact 테이블, Dimension 테이블.

• Fact table : 분석의 초점이 되는 정보 테이블. 중앙 테이블.
• Dimension table : 메타 정보를 포함하는 테이블. 히스토리를 갖는 테이블. fact table에 대한 상세 정보 제공.
• fact-dimension 테이블 간에는 composite되어 있음. Primary Key-Foriegn Key.

dbt 실습.

• 크게 직접 설치 방식과 클라우드 방식이 있음.
• 설치 -> 환경 설정 -> connector 설정(redshift, spark, ..) -> 데이터 모델링(티어, raw -> staging -> core) -> 테스크 코드, snapshot 설정
• pip3 install dbt-redshift
• dbt init learn_dbt

dbt Model이란,

• ELT 테이블을 만드는 데 기본이 되는 빌딩 블록.
• 테이블, 뷰, CTE 등의 형태로 존재.
• raw tier -> staging tier -> core(fact, dimension) tier의 세 단계의 테이블을 정의하는 곳.

View란,

• SELECT 결과를 기반으로 만들어진 가상 테이블.
• CREATED VIEW name AS SELECT ...
• 데이터 추상화, 데이터 보안, 복잡한 쿼리를 단순화 가능 등의 장점이 있음.
• 매번 쿼리가 실행되므로 시간이 걸리며, 원본 데이터의 변경으로 인해 실행이 실패할 수 있다는 단점이 있음.

CTE(common table expression)란,

• WITH temp1 AS (SELECT ...), temps2 AS (...) SELECT* FROM temp1, temp2처럼 임시로 테이블을 만들어서 사용.
• dbt에서 자주 사용됨.

데이터 빌딩 프로세스.

• raw data -> staging(데이터 검사) -> core(정제된 데이터).

Model의 구성 요소.

• Input : 입력(raw by CTE)과 중간(staging, src by View) 데이터 정의.
• Output : 최종(core by Table) 데이터 정의.
• 위 파일들 모두, models 폴더 밑에 .sql 파일로 저장.
• 기본적으로 SELECT + Jinja 템플릿으로 사용 가능.

Materialization이란?,

• 입력 테이블들을 연결해서 새로운 테이블을 생성하는 것.(ELT)
• 4가지 내장 materialization이 제공됨. (View, Table, Incremental, Ephemeral(CTE))
• 파일이나 프로젝트 레벨에서 가능.
• dbt run 명령어로 실행.