데이터 엔지니어링 54일차 TIL

학습 내용

프로덕션 사용을 위한 Airflow 환경 설정
- Airflow.cfg 는 /var/lib/airflow/airflow.cfg 에 위치해야한다
        - webserver와 scheduler가 재시작될 때 변경사항이 반영됨
        - [core]섹션의 dags_folder가 DAG들이 있는 디렉토리가 되어야한다.
        - dag_dir_list_interval: dags_folder를 airflow가 얼마나 자주 스캔하는지 명시해야한다(초 단위)
- Arirflow Database upgrade
        - 기본은 SQLite 이며 Postgres 또는 MySQL로 변경
        - sql_alchemy_conn 이 Core section of airflow.cfg 안에 있어야한다.
        => 기본의 SequentialExecutor 에서 LocalExecutor 또는 CeleryExecutor로 변경해야한다.
- Enable Authentication
        - 가능하면 Authentication을 킨다(2.0부터 자동으로 켜짐)
- Strong password 사용
        - 되도록이면 VPN뒤에 위치시킨다.
- Log 폴더 관리
        - /dev/airflow/logs (Core section of airflow.cfg)
        - base_log_folder, child_process_log_directory 에 로그 파일이 생성되며 용량이 작지 않기 때문에 주기적으로 s3에 백업하고 삭제 해야한다.
- 성능 향상시에 Scale Up으로 사양을 높이다가 Scale Out을 한다.
- metadata 를 백업해둔다.
        - Admin의 variables와 connetions를 백업한다
- health-check monitoring을 추가하여 건강 체크
        - 규모가 커진다면 DagaDog, Grafana등을 사용(DevOps팀과 협업)

Airflow의 로그
- 두 군데에 별도의 로그가 기록된다. 
        - [logging] : base_log_folder = /var/lib/airflow/logs
        - [scheduler] : child_process_log_directory = /var/lib/airflow/logs/scheduler
- docker compose로 실행된 경우 logs 폴더가 host volume의 형태로 유지된다.

Airflow 이외의 다른 데이터 파이프라인 프레임워크
- Prefect : 오픈소스이며 airflow와 상당히 흡사하지만 조금 더 경량화 되었으며, 데이터 파이프라인을 동적으로 생성할 수 있는 강점이 있다.
- Dagster : 데이터 파이프라인과 데이터를 동시에 관리한다.
- Airbyte : 코딩 툴이라기 보다는 Low_code 툴에 가깝다.

DBT(Data Build Tool)
: 데이터 품질의 중요성이 증대하면서 떠오르는 ELT 툴이다.

Data Normalization
: 데이터베이스를 좀 더 조직적이고 일관된 방법으로 디자인하려는 방법
        - 데이터 베이스의 정합성을 쉽게 유지하고 레코드들을 수정/적재/삭제를 용이하게 하는 것.
- Normalization에 사용되는 개념
        - Primary Key(기본키) : 후보키들 중에서 하나를 선택한 키로 최소성과 유일성을 만족하는 키이다. (Null값과 중복된 값을 가질 수 없으며 테이블에서 1개만을 지정 가능)
        - Composite Key(복합키) : 2개 이상의 속성을 사용하는 키
        - Foreign Key(외래키) : 참조되는 테이블의 기본키와 동일한 키 속성을 가진다. (어떤 테이블간의 기본키를 참조하는 속성, 테이블들 간의 관계를 나타내기 위해 사용)

1NF(First Normal Form)
- 한 셀에는 하나의 값만 있어야한다.(atomicity)
- Primary Key(기본키)가 있어야한다.
- 중복된 키나 레코드들이 없어야한다.
=> 목표 : 중복을 제거하고 atomicity(원자성)를 갖는것

2NF(Second Normal Form)
- 1NF의 조건을 모두 만족해야한다.
- 다음으로 Primary Key를 중심으로 의존결과를 알 수 있어야한다.
- 부분적인 의존도가 없어야한다.
        - 모든 부가 속성들은 Primary Key를 가지고 찾을 수 있어야한다.
=> 목표 : 중복을 제거하고 원자성을 갖는것

3NF(Third Noraml Form)
- 2NF의 조건을 모두 만족해야한다.
- 전이적 부분 종속성이 없어야한다.

Slowly Changing Dimensions(속성들의 변화)
- DW나 DL에서는 모든 테이블들의 히스토리를 유지하는 것이 중요하다.
        - 보통 두 개의 timestamp 필드를 갖는 것이 좋다
                - created_at(생성시간)
                - updated_at(마지막 수정시간)
- SCD Type 0 : 한번 정해지면 갱신되지 않고 고정되는 필드들
- SCD Type 1 : 데이터가 새로 생기면 덮어쓰면 되는 컬럼들
- SCD Type 2 : 특정 entity에 대한 데이터가 새로운 레코드로 추가되어야 하는 경우
- SCD Type 3 : SCD Type 2의 대안으로 특정 entity데이터가 새로운 컬럼으로 추가되는 경우
- SCD Type 4 : SCD Type 2의 변종으로 특정 entity에 대한 데이터를 새로운 Dimension 테이블에 저장하는 경우

DBT 구성 컴포넌트
- 데이터 모델(models)
        - 테이블들을 몇개의 티어로 관리
                - 일종의 CTAS(SELECT 문들), Lineage 트래킹
        - Table, View, CTE 등등
- 데이터 품질 검증(tests)
- 스냅 샷(snapshots)

dbt기능
- 데이터 변경 사항을 이해하기 쉽고 필요하다면 롤백 가능
- 데이터간 리니지 확인 가능
- 데이터 품질 테스트 및 에러 보고
- Fact 테이블의 증분 로드(Incremental Update)
- Deimension 테이블 변경 추적(히스토리 테이블)
- 용이한 문서 작성

Fact테이블 : 분석의 초점이 되는 양적 정보를 포함하는 중앙 테이블
- 일반적으로 외래 키를 통해 여러 Dimension테이블과 연결됨
Dimension 테이블 : Fact 테이블에 대한 상세 정보를 제공하는 테이블
- primary key를 가지며, fact 테이블에서 참조한다 (foreign key)
크기 : Face테이블 >>>> Dimension테이블

dbt_project.yml 설명

-- 마지막 models : 밑의 값을 변경함으로써 테이블, 뷰 등 어떤타입으로 저장할지 설정 가능하다

dbt에서 model이란?
- ELT 테이블을 만듦에 있어 기본이 되는 빌딩블록
        - 테이블이나 뷰나 CTE의 형태로 존재
- 입력, 중간, 최종 테이블을 정의 하는곳
        - 티어 (raw, staging, core 등)
        - raw => staging(src) => core

dbt에서 model의 구성요소
- Input : 입력(raw)과 중간(staging, src) 데이터를 정의한다
        - raw 는 CTE로 정의
        - staging은 View로 정의
- Output : 최종(core) 데이터를 정의 한다
        - core는 Table로 정의
=> 이 모두는 models 폴더 밑에 sql 파일로 존재
        - 기본적으로 SELECT + Jinja 템플릿과 매크로
        - 다른 테이블들을 사용 가능하다(reference) : 이를 통해 리니지(계보)를 파악

dbt에서 view란 무엇인가?
- SELECT 결과를 기반으로 만들어진 가상 테이블
        - 기존 테이블의 일부 혹은 여러 테이블들을 조인한 결과를 제공한다.
        - CREATE VIEW 이름 AS SELECT...
- View의 장점
        - 데이터의 추상화 : 사용자는 View를 통해 필요 데이터에 직접 접근한다, 원본데이터를 알 필요가 없다.
        - 데이터 보안 : View를 통해 사용자에게 필요한 데이터만 제공한다, 원본 데이터 접근이 불필요하다.
        - 복잡한 쿼리의 간소화 : SQL(View)를 사용하면 복잡한 쿼리를 단순화 한다.
- View의 단점
        - 매번 쿼리가 실행되므로 시간이 걸린다.
        - 원본 데이터의 변경을 모르면 실행이 실패한다.

CTE(Common Table Expression) 사용법
: WITH temp1 AS( SELECT ...)

View 와 CTE의 차이점
- 영속성 : 뷰는 데이터베이스에 영구적으로 저장되지만, CTE는 쿼리 실행 시 일시적으로 생성된다.
- 사용 범위 : 뷰는 여러 쿼리에서 재사용 가능하지만, CTE는 정의된 쿼리 내에서만 사용된다.
- 복잡성 처리 : 뷰는 데이터베이스 객체로 여러 쿼리에서 일관된 데이터를 제공하는 반면, CTE는 주로 복잡한 쿼리의 일부분을 단순화하기 위해 사용된다.
- 보안 : VIEW는 데이터 접근 제어와 데이터 숨기기를 통해 보안을 강화하며, 민감한 정보에 대한 접근을 제한할 수 있지만, CTE는 일시적으로 존재하여 별도의 권한 관리가 불가능하며, 보안 적용이 제한적이다.

데이터 빌딩 프로세스

models/src - src_user_event.sql 생성

WITH src_user_event AS (
 SELECT * FROM raw_data.user_event
)
SELECT
 user_id,
 datestamp,
 item_id,
 clicked,
 purchased,
 paidamount
FROM
 src_user_event

models/src - src_user_variant.sql 생성

WITH src_user_variant AS (
 SELECT * FROM raw_data.user_variant
)
SELECT
 user_id,
 variant_id
FROM
 src_user_variant

models/src - src_user_metadata.sql 생성

WITH src_user_metadata AS (
 SELECT * FROM raw_data.user_metadata
)
SELECT
 user_id,
 age,
 gender,
 updated_at
FROM
 src_user_metadata

=> dbt run 실행시 위의 src폴더 밑의 sql파일에서 정의한 3개의 테이블을 3개의 view로 만들어낸다.

Materialization 이란?
- 입력 데이터(테이블)들을 연결해서 새로운 데이터(테이블)을 생성하는 것
- 4가지의 내장 materialization이 제공된다
- 파일이나 프로젝트 레벨에서 가능하다
- dbt run을 기타 파라미터를 가지고 실행

Materialization 종류
- View : 데이터를 자주 사용하지 않는 경우
- Table : 데이터를 반복해서 자주 사용하는 경우
- Incremental(Table Appends) : Fact 테이블, 과거 레코드를 수정할 필요가 없는 경우
- Ephemeral(CTE) : 한 SELECT에서 자주 사용되는 데이터를 모듈화하는데 사용

models 밑에 core 테이블들을 위한 폴더 생성
- dim 폴더와 fact 폴더 생성
        - dim 밑에 각각 dim_user_variant.sql과 dim_user_metadata.sql 생성
        - act 밑에 fact_user_event.sql 생성
=> 이 모두를 physical table로 생성

-- WHERE 절을 추가함으로써 중복제거와 덧붙이기가 가능하다

 

 

Analytics 생성

 

models/analytics - analytics_variant_user_daily.sql 생성

 

 

YML 설정

 

 

dbt compile과 dbt run의 차이
- dbt compile : SQL코드까지만 생성하고 실행하지는 않는다.
- dbt run : 생성된 코드를 실제 실행까지 완료한다.