ETL vs ELT
- ETL: 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
- 보통 엔지니어들이 수행
- ELT: 데이터 웨어하우스 내부 데이터를 조작해서 (보통은 좀더 추상화되고 요약된) 새로운 데이터를 만드는 프로세스
- 보통 데이터 분석가들이 수행
- 이 경우, 데이터 레이크 위에서 이런 작업들이 벌어지기도 함
- 이런 프로세스 전용 기술들이 있으며 dbt(Data Build Tool)가 가장 유명: Analytics Engineering
Data Lake vs Data Warehouse
- Data Lake
- 구조화 데이터 + 비구조화 데이터
- 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움
- 보통은 데이터 웨어하우스보다 몇 배는 더 큰 스토리지
- Data Warehouse
- 보존 기한이 있는 구조화된 데이터를 저장하고 처리하는 스토리지
- 보통 BI 툴들(룩커, 태블로, 수퍼셋, ...)은 데이터 웨어하우스를 백엔드로 사용함
Data Pipeline
- 데이터를 소스로부터 목적지로 복사하는 작업
- 이 작업은 보통 고딩 (파이썬 혹은 스칼라) 혹은 SQL을 통해 이뤄짐
- 대부분 목적지는 데이터 웨어하우스가 됨
- 데이터 소스의 예
- Click stream, call data, ads performance data, transactions, ...
- 데이터 목적의 예
- 데이터 웨어하우스, 캐시 시스템, 프로덕션 데이터베이스, NoSQL, S3, ...
데이터 파이프라인 종류
- Raw Data ETL Jobs
- 외부와 내부 데이터 소스에서 데이터를 읽은 후 (대부분 API를 통해 가져옴)
- 적당한 데이터 포맷으로 변환 후 (데이터 크기가 커지면 Spark등이 필요해짐)
- 데이터 웨어하우스로 로드
- Summary/Report Jobs
- DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ELT
- Raw Data를 읽어서 일종의 리포트 형태나 써머리 형태의 테이블을 다시 만드는 용도
- 특수한 형태로는 AB 테스트 결과를 분석하는 데이터 파이프라인도 존재
- * 요약 테이블의 경우, SQL (CTAS를 통해)만으로 만들고 이는 데이터 분석가가 하는 것이 맞음. 데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 작업할 수 있는 환경을 만들어 주느냐가 관건 -> Analytics Engineer (DBT)
- Production Data Jobs (데이터 시스템 밖에 있는 스토리지에 저장)
- DW로부터 데이터를 읽어 다른 Storage(많은 경우 프로덕션 환경)로 쓰는 ETL
- 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
- 혹은 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우
- 이 경우 흔한 타겟 스토리지
- Cassandra/HBase/DynamoDB와 같은 NoSQL
- MySQL과 같은 관계형 데이터베이스 (OLTP)
- Redis/Memcache와 같은 캐시
- ElasticSearch와 같은 검색엔진
- DW로부터 데이터를 읽어 다른 Storage(많은 경우 프로덕션 환경)로 쓰는 ETL
데이터 파이프라인을 만들 때 고려할 점
Best Parctices
1. 가능하면 데이터가 작을 경우 매번 통째로 복사해서 테이블을 만들기 (Full Refresh)
- 과거 데이터가 문제 있다 하더라도 다 읽어보면 되니까 해결하기 간단함
- 그러나 사이즈가 커지면 어려워짐
- Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 몇 가지 조건이 있음
- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
- created (데이터 업데이트 관점에서 필요하지는 않음)
- modified
- deleted
- 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야 함
- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
* full refresh vs Incremental upate 판단 기준: 이 데이터를 full refresh 할 때 걸리는 시간을 고려했을 때 뒷단에서 이 데이터가 이용가능해지기를 기다리는 파이프라인이 있다고 한다면, full refresh를 할 때 걸리는 시간이 짧은가를 고려
* 데이터 소스가 어떤 시점을 기준으로 변경하거나 가져올 수 있어야 만 Incremental update 가능
2. 멱등성(Idemprotency)을 보장하는 것이 중요
- 멱등성이란?
- 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 동일함
- ex. 중복 데이터가 생기면 안 됨
- 중요한 포인트는 critical point들이 모두 one atomic action으로 실행이 되어야 한다는 점
- 즉, 실패하면 깔끔하게 실패해야 함
- SQL의 transaction이 꼭 필요한 기술
- 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 동일함
3. 실패한 데이터 파이프라인을 재실행이 쉬어야 함
- 과거 데이터를 다시 채우는 과정(backfill)이 쉬어야 함
- airflow는 이 부분(특히 backfill)에 강점을 갖고 있음
4. 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
- 비지니스 오너 명시: 누가 이 데이터를 요청했는지를 기록으로 남길 것
- 이게 나중에 데이터 카탈로그로 들어가서 데이터 디스커버리에 사용가능
- 데이터 리니지가 중요해짐 -> 이걸 이해하지 못 하면 온갖 종류의 사고 발생
5. 주기적으로 쓸모 없는 데이터들을 삭제
- Kill unused tables and data pipelines proactively
- Retail only necessary data in DW and move past data to DL (or storage)
6. 데이터 파이프라인 사고시 마다 사고 리포트(post-mortem) 쓰기
- 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함
- 사고 원인(root-cause)을 이해하고 이를 방지하기 위한 액션 아이템들의 실행이 중요해짐
- 기술 부채의 정도를 이야기해주는 바로미터
7. 중요 데이터 파이프라인의 입력과 출력을 체크하기
- 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇 개인지 체크하는 것부터 시작
- 써머리 테이블을 만들어내고 primary key가 존재한다면 primary key uniqueness가 보장되는지 체크하는 것이 필요함
- 중복 레코드 체크
- (반복)
Airflow
- airflow는 파이썬으로 작성된 데이터 파이프라인 (ETL) 프레임워크
- airbnb에서 시작한 아파티 오픈소스 프로젝트
- 가장 많이 사용되는 데이터 파이프라인 관리/작성 프레임워크
- 데이터 파이프라인 스케줄링 지원
- 정해진 시간에 ETL 실행 혹은 한 ETL의 실행이 끝나면 다음 ETL 실행
- 웹 UI를 제공하기도 함
- 데이터 파이프라인(ETL)을 쉽게 만들 수 있도록 해줌
- 다양한 데이터 소스와 데이터 웨어하우스를 쉽게 통합해주는 모듈 제공
- 데이터 파이프라인 관리 관련 다양한 기능을 제공해줌: 특히 backfill
- airflow에서는 데이터 파이프라인을 DAG(Directed Acyclic Graph)라고 부름
- 하나의 DAG는 하나 이상의 태스크로 구성됨
- 2020년 12월에 airflow 2.0 이 릴리스 됨
Airflow 구성
- 웹 서버 (Web server)
- 스케줄러 (Scheduler)
- 워커 (Worker): 실제 코드를 실행해주는 일꾼
- CPU 개수 만큼 생길 수 있음
- 메타 데이터 데이터베이스: 위 3개의 컴포넌트가 자기 상황을 기록하는 곳
- sqlite가 기본으로 설치됨
- 큐 (다수 서버 구성인 경우에만 사용됨): 중간 매개체
- 이 경우 Executor가 달라짐
- 스케줄러는 DAG들을 워커들에게 배정하는 역할을 수행
- 웹 UI는 스케줄러와 DAG의 실행 상황을 시각화해줌
- 워커는 실제로 DAG를 실행하는 역할을 수행
- 스케줄러와 각 DAG의 실행결과는 별도 DB에 저장됨
- 기본으로 설치되는 DB는 SQLite
- 실제 프로덕션에서는 Mysql이나 Postgress를 사용해야 함
airflow 개발의 장단점
- 장점
- 데이터 파이프라인을 세밀하게 제어 가능
- 다양한 데이터 소스와 데이터 웨어하우스를 지원
- 백필(backfill)이 쉬움
- 단점
- 배우기가 쉽지 않음
- 상대적으로 개발환경을 구성하기가 쉽지 않음
- 직접 운영이 쉽지 않음. 클라우드 버전 사용이 선호됨
- GCP provides "Cloud Composer
DAG란?
- airflow에서 ETL을 부르는 명칭
- DAG는 태스크로 구성됨
- ex. 3개의 태스크로 구성된다면 Extract, Transform, Load로 구성
- 태스크란? - airflow의 오퍼레이터(operator)로 만들어짐
- airflow에서 이미 다양한 종류의 오퍼레이터를 제공함
- 경우에 맞게 사용 오퍼레이터를 결정하거나 필요하다면 직접 개발
반응형
