Airflow_(1)

데이터 파이프라인 (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와 같은 검색엔진

---

데이터 파이프라인 구성 시 주의할 점

• 데이터 파이프라인은 많은 이유로 실패
  • 버그
  • 데이터 소스상의 문제 : 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
• 멱등성 (Idemporency)을 보장하는 것이 중요
  • 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 함
     - 중복 데이터가 생기지 않아야 함
  • 중요한 포인트는 critical point들이 모두 one atomic action으로 실행이 되어야 함
     - SQL의 transaction이 꼭 필요한 기술
• 실패한 데이터 파이프라인을 재실행이 쉬워야 함
  • 과거 데이터를 다시 채우는 과정 (Backfill)이 쉬워야 함
  • Airflow는 Backfill에 있어 강점을 가지고 있음
• 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
  • 누가 해당 데이터를 요청했는지를 기록
  • 추후에 기록이 데이터 카탈로그로 들어가 데이터 디스커버리에 사용 가능
• 주기적으로 쓸모없는 데이터들을 삭제
• 데이터 파이프라인 사고시 마다 사고 리포트 작성
  • 목적 : 동일한 혹은 비슷한 사고 방지
  • 원인을 이해하고 이를 방지하기 위한 액션 아이템들의 실행이 중요
  • 기술 부채의 정도를 이야기해주는 바로미터
• 중요 데이터 파이프라인의 입력과 출력을 체크하기
  • 간단하게 입력 레코드와 출력 레코드 수가 몇 개인지 체크하는 것부터 시작
  • summary 테이블을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 확인
  • 중복 레코드 확인