데이터 파이프라인 (ETL)
- ETL : Extract, Transform and Load
- Data Pipeline, ETL, Data Workflow, DAG
- Airflow에서는 DAG (Directed Acyclic Graph)라고 부름
- 데이터를 소스로부터 목적지로 복사하는 작업
- 보통 코딩 (파이썬, 스칼라) 혹은 SQL을 통해 이뤄짐
- 대부분의 경우 목적지는 데이터 웨어하우스
ETL vs ELT
- ETL : 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
- 데이터 엔지니어들이 수행
- ELT : 데이터 웨어하우스 내부 데이터를 조작하여 새로운 데이터를 만드는 프로세스
- 데이터 분석가들이 많이 수행
- 데이터 레이크 위에서 작업을 진행하기도 함
- ELT에는 전용 기술들이 있으며 dbt가 가장 유명 (Analytics Engineering)
- dbt : Data Build Tool
Data Lake vs Data Warehouse
- Data Lake (데이터 레이크)
- 구조화 데이터 + 비구조화 데이터
- 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움
- 데이터 웨어하우스보다 몇 배는 더 큰 스토리지
- Data Warehouse
- 보존 기한이 있는 구조화 된 데이터를 저장하고 처리하는 스토리지
- BI 툴들은 데이터 웨어하우스를 백엔드로 사용
데이터 파이프라인의 종류
- Raw Data ETL Jobs -> 데이터 엔지니어의 업무
- 외부와 내부 데이터 소스에서 데이터를 읽음 -> Extract (많은 경우 API를 통해 진행)
- 데이터 포맷 변환 -> Transform (데이터의 크기가 커지면 Spark 등이 필요)
- 데이터 웨어하우스로 로드 -> Load
- Summary / Report Jobs -> 주로 데이터 분석가의 업무
- DW (혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
- Raw Data를 읽어 일종의 리포트 형태나 summary 형태의 테이블을 다시 만드는 용도
- 특수한 형태로는 A/B 테스트 결과를 분석하는 데이터 파이프라인도 존재
- 데이터 엔지니어의 관점에서 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어 주느냐가 중요
- Production Data Jobs
- DW로부터 데이터를 읽어 다른 스토리지 (많은 경우 프로덕션 환경)로 쓰는 ETL
- summary 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
- 혹은, 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우 - 흔한 타겟 스토리지
- Cassandra / HBase / DynamoDB와 같은 NoSQL
- MySQL과 같은 관계형 데이터베이스 (OLTP)
- Redis / Memcache와 같은 캐시
- ElasticSearch와 같은 검색엔진
- DW로부터 데이터를 읽어 다른 스토리지 (많은 경우 프로덕션 환경)로 쓰는 ETL
데이터 파이프라인 구성 시 주의할 점
- 데이터 파이프라인은 많은 이유로 실패
- 버그
- 데이터 소스상의 문제 : What if data sources are not available or change its data format
- 데이터 파이프라인들간의 의존도 이해 부족
- 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남
- 데이터 소스간의 의존도가 생기면서 더 복잡해짐
ex_) 마케팅 채널 정보가 업데이트가 안된다면 마케팅 관련 다른 모든 정보들이 갱신되지 않음 - More tables needs to be managed (source of truth, search cost...)
- 데이터 소스간의 의존도가 생기면서 더 복잡해짐
데이터 파이프라인 구성 모범 사례
- Full Refresh - 모든 데이터를 통채로 복사하여 테이블 생성
- Incremental updata 만이 가능하다면, 대상 데이터 소스가 갖춰야 할 조건이 있음
- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
- created (업데이트 관점에서는 필요치 않음)
- modified
- deleted
- Incremental updata 만이 가능하다면, 대상 데이터 소스가 갖춰야 할 조건이 있음
- 멱등성 (Idemporency)을 보장하는 것이 중요
- 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 함
- 중복 데이터가 생기지 않아야 함 - 중요한 포인트는 critical point들이 모두 one atomic action으로 실행이 되어야 함
- SQL의 transaction이 꼭 필요한 기술
- 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 함
- 실패한 데이터 파이프라인을 재실행이 쉬워야 함
- 과거 데이터를 다시 채우는 과정 (Backfill)이 쉬워야 함
- Airflow는 Backfill에 있어 강점을 가지고 있음
- 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
- 누가 해당 데이터를 요청했는지를 기록
- 추후에 기록이 데이터 카탈로그로 들어가 데이터 디스커버리에 사용 가능
- 주기적으로 쓸모없는 데이터들을 삭제
- 데이터 파이프라인 사고시 마다 사고 리포트 작성
- 목적 : 동일한 혹은 비슷한 사고 방지
- 원인을 이해하고 이를 방지하기 위한 액션 아이템들의 실행이 중요
- 기술 부채의 정도를 이야기해주는 바로미터
- 중요 데이터 파이프라인의 입력과 출력을 체크하기
- 간단하게 입력 레코드와 출력 레코드 수가 몇 개인지 체크하는 것부터 시작
- summary 테이블을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 확인
- 중복 레코드 확인
728x90
'ssung_데이터 엔지니어링 > 9주차_Airflow' 카테고리의 다른 글
Airflow_(4) (0) | 2023.12.14 |
---|---|
Airflow_(3) (0) | 2023.12.13 |
Airflow_(2) (0) | 2023.12.12 |