[TIL_2024.01.04] Airflow 운영과 대안 & dbt

11주차 목요일, 54일차 Today I Learned

 

 

Airflow 운영과 대안 
: 프로덕션 사용을 위한 환경설정, 로그 파일 삭제, 메타데이터 백업, 대안

dbt (1)
: 소개, 사용 시나리오, 설치와 환경설정, Models (Input, Output)

 

 

---

 

 

✏️ 학습 내용

Airflow 운영과 대안

1. 프로덕션 사용을 위한 Airflow 환경설정

 

주의사항

• airflow.cfg is in /var/lib/airflow/airflow.cfg
• core 섹션의 dags_folder가 DAG들이 있는 디렉토리가 되어야 한다.
• Sqlite가 아니라 Postgres or MySQL 사용
• 되도록이면 VPN 뒤에 위치하게 하여 함부로 액세스하지 못하도록
• base_log_folder, child_process_log_directory : Log가 금방 차므로 주기적으로 클린업, 백업 필요
• Scale Up 다음에 Scale Out 다음에 클라우드 고려하는 순서로 스케일링하기
• 메타데이터DB 백업하기
• 헬스체크 모니터링 추가 (규모가 된다면 DataDog, Grafana 등 사용)

 

 

2. Airflow 로그 파일 삭제

• logging
• scheduler

두 군데에 별도의 로그가 기록되므로, 이를 주기적으로 삭제하거나 s3에 백업하는 것이 필요하다.

 

docker compose로 실행된 경우 logs 폴더가 host volume 형태로 유지되어 있다.

 

 

 

3. Airflow 메타데이터 백업

메타데이터의 데이터베이스가 외부에 있다면 (특히 AWS RDS라면) 거기에 바로 주기적인 백업 셋업이 필요하다. 혹은 Airflow와 같은 서버에 메타 데이터 DB가 있다면 (예를들어 PostgreSQL) DAG등을 이용해 주기 백업 실행하여 S3로 저장해야 한다.

 

 

4. Airflow 대안

• Prefect : airflow와 흡사하며 좀 더 경량화된 버전
• Dagster : 데이터파이프라인과 데이터를 동시 관리
• Airbyte : Low-Code 툴에 가까움
• Saas 형태의 데이터 통합 툴 : FiveTran, Stitch Data, Segment

 

---

 

dbt

ETL을 하는 이유는 결국 ELT를 하기 위함이며, 이 때 데이터 품질 검증이 중요해진다. 이를 위해 등장한 것이 DBT (Data Build Tool) 이다.

 

1. Database Normalization

데이터를 수집하여 적재한 후에 Integration 한 이후에, BI & Analytics 하기 위한 중간 과정에 큰 갭이 존재한다. 이 갭을 줄여야 한다.

 

Database Normalization이란 데이터베이스를 좀 더 조직적이고 일관된 방법으로 디자인하려는 방법으로, 데이터베이스 정합성을 쉽게 유지하고 레코드들의 수정/적재/삭제를 용이하게 한다.

• Primary Key
• Composite Key
• Foreign Key

• 1NF (First Normal Form) : 중복을 제거하고, PK가 있으며, 한 셀에는 하나의 값만 있어야 한다.
• 2NF (Second Normal Form) : 1NF + PK중심으로 의존결과를 알 수 있어야 하고, 부분적인 의존도가 없어야 한다.
• 3NF (Third Normal Form) : 2NF + 전이적 부분 종속성이 없어야 한다.

 

SCD (Slowly Changing Dimensions)

DW나 DL에선 모든 테이블들의 히스토리를 유지하는 것이 중요하다. 보통 두 개의 timestamp 필드를 갖는 것이 좋으며, 이 경우 컬럼의 성격에 따라 어떻게 유지할지 방법이 달라진다.

• SCD Type 0 : 한 번 쓰고 나면 바꿀 이유가 없는 경우들, 한 번 정해지면 갱신되지 않고 고정되는 필드들
• SCD Type 1 : 데이터가 새로 생기면 덮어쓰면 되는 컬럼들, 처음 레코드 생성 시에는 존재하지 않았지만 나중에 생기면서 채우는 경우
• SCD Type 2 : 특정 엔티티에 대한 데이터가 새로운 레코드로 추가되어야 하는 경우로, 이 때부터 히스토리가 관계 있어진다.
• SCD Type 3 : 2의 대안으로, 특정 엔티티 데이터가 새로운 컬럼으로 추가되는 경우
• SCD Type 4 : 2의 변종으로, 특정 엔티티에 대한 데이터를 새로운 Dimension 테이블에 저장하는 경우

 

 

 

2. 소개

dbt란 데이터를 빌드하는 툴, ELT용 오픈소스이다. dbt Labs라는 회사가 상용화했고, Analytics Engineer라는 말을 만들어냈다. 다양한 데이터 웨어하우스를 지원하고, 클라우드 버전도 존재한다.

 

dbt를 구성하는 컴포넌트는 여러 가지 있는데, 데이터 모델, 데이터 품질 검증, 스냅샷 등이 있다.

 

 

 

3. 사용 시나리오

dbt가 어떻게 사용될 수 있는지 가상 환경 세팅

 

데이터 변경 사항을 이해하기 쉽고 필요하다면 롤백을 할 수 있도록, 데이터간 리니지 확인 가능하도록, 데이터 품질 테스트 및 에러 보고를 하도록, Fact 테이블의 증분 로드 (Incremental Update)가 되도록, Dimension 테이블 변경 추적이 가능하도록, 용이한 문서 작성이 가능하도록 도와주는 것이 바로 dbt이다.

• Fact Table : 분석의 초점이 되는 양적 정보를 포함하는 중앙 테이블
• Dimension Table : Fact xpdlqmfdp eogks tkdtp wjdqhfmf wprhdgksms xpdlqmf

 

 

 

4. 설치와 환경설정

dbt 설치는 클라우드를 이용하거나 직접 설치하면 된다. 보통 git을 사용한다. 설치 후에는 환경설정을 하고, Connector 설정을 한 다음에 데이터 모델링을 하고, 테스트 코드를 작성하면 된다. 필요하다면 스냅샷을 설정하여 히스토리 관리도 할 수 있다.

 

클라우드 버전이 dbt Cloud, 로컬 개발 버전이 dbt Core이다.

 

1. dbt-core 모듈 설치 : `pip3 install dbt-redshift`
2. Connector 연결 : Redshift 연결 정보를 확인하여 연결한다.
3. 환경 설정 : `dbt init {}` - 이 때에 yml 파일 포맷으로 환경설정을 진행한다.

• dbt_project.yml : 메인 환경 설정 파일
• medels, seeds, tests, snapshots, macros, analyses 폴더
• README.md

 

 

 

5. dbt Models (Input, Output)

dbt Mdel을 사용하여 입력 데이터들을 Transform 할 수 있다. Model이란 ELT 테이블을 만듦에 있어 기본이 되는 빌딩블록으로, 테이블이나 뷰나 CTE의 형태로 존재한다. 입력, 중간, 최종 테이블을 정의하는 곳으로, 총 3개의 티어로 나뉜다. Raw에서 클린업하여 Staging 되면 변환을 통해 Core로 만든다.

View
SELECT 결과를 기반으로 만들어진 가상 테이블로, 데이터의 추상화와 보안 및 복잡한 쿼리의 간소화가 가능하다. 다만 매번 쿼리가 실행되어 시간이 소요되고, 원본 데이터의 변경을 모르면 실행이 실패한다.

CTE (Common Table Expression)
WITH 구문을 이용하여 임시 테이블을 만든다.

 

 

구성 요소는 Input과 Output 2가지이며, models 폴더 밑에 sql 파일로 존재하여 관리가 용이하다. 기본적으로는 SELECT + Jinja Template과 매크로로 만들며, 다른 테이블을 사용 가능하여 이를 통해 리니지 파악도 할 수 있다.

• Input : Raw (입력) -(cleanup)-> Staging (중간). 입력은 CTE로, 중간 데이터는 View로 정의한다.
• Output : Staging -(transform)-> Core (최종). 최종 결과물을 Table로 정의한다.

 

Materialization이란 입력 데이터(테이블)들을 연결해서 새로운 데이터(테이블)를 생성하는 것, 즉 ELT이다. 보통 여기서 추가 Transformation이나 데이터 클린업을 수행한다. 4가지의 내장 Materialization이 제공되며, 파일이나 프로젝트 레벨에서 가능하다. dbt run을 기타 파라미터를 가지고 실행할 수 있다.

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

 

 

Models 밑에 Core 테이블들을 위해서 dim 폴더와 fact 폴더를 모두 physical table로 생성해야 한다. 그리고 그 아래에 각각 sql 파일을 생성해야 한다. 폴더를 피지컬 테이블로 생성하기 위해 Jinja 템플릿과 ref 태그를 사용해서 dbt 내 다른 테이블들을 액세스해야 한다.

 

Model 빌딩 확인은 해당 스키마 밑에 테이블 생성 여부 확인을 통해 가능하다.

 

dbt compile : SQL 코드까지만 생성하고 실행하지는 않음
dbt run : 생성된 코드를 실제 실행함

 

 

 

 

반응형

 

 

 

 

💡 배운 점

• Airflow 운영과 대안 관련하여 프로덕션 사용을 위한 Airflow 환경설정 주의사항, 로그 파일 삭제, 메타데이터 백업에 대해 배웠다.
• Airflow 대안으로 어떤 툴이 있는지 알아보았다.
• Database Normalization에 대해 알아보았다.
• dbt에 대한 간략한 소개를 배웠다.
• dbt가 어떻게 사용될 수 있는지 사용 시나리오에 대해 배웠다.
• Models (Input, Output)에 대해 배웠다.
• Materialization (View, Table, Incremental,, Ephemeral)에 대해 배웠다.

 

 

 

---

 

📝 남아있는 의문과 개선점

• 메타데이터 백업 처리, 세팅은 어떻게 하는 것인지?
• 메타데이터에 속하는 것은 어떤 것이 있고, 왜 백업을 해야 하는 것인지?

• Database Normalization이란?
• Composite Key이 무엇이고 어떻게 사용되는지?
• 1NF, 2NF, 3NF, SCD가 무엇이고 어떻게 연관있는지?

• dbt 환경설정 및 Connector 연결방법
• Table, View, CTE 차이점 (특히 CTE가 무엇인지?)
• Materialization 라고 따로 이름붙인 이유는? 그리고 이 개념에 대해서
• Models 데모

 

 

---

 

☁️ 소감

헷갈리고 정체를 알 수 없는 용어들이 여러 개 나왔다. 좀 더 살펴봐야 할 것 같다. 하지만 dbt는 분명 유용한 툴이 될 것 같아서 좀 더 배우고 싶다. 실제로 회사에서 사용하기에 매우 유용할 것 같다.