데이터엔지니어링

[8주차] 데이터 파이프라인과 Airflow (1)

heecup 2024. 5. 20. 14:04

🙂 데이터 파이프라인

✔ 데이터 파이프라인이란?

  • ETL: Extract, Transform and Load
  • Data Pipleline, ETL, Data Workflow, DAG
    • ETL (Extract, Transform and Load)
    • DAG (Directed Acyclic Graph) in Airflow
  • ETL vs ELT
    • ETL: 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
      • 데이터 엔지니어 업무
    • ELT: DW 내부 데이터를 조작해서 새로운 데이터를 만드는 프로세스
      • 데이터 분석가 업무
      • DBT가 가장 유명
  • Data Lake vs. Data Warehouse
    • Data Lake
      • 구조화 데이터 + 비구조화 데이터
      • 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지
      • DW보다 몇 배는 더 큼
    • Data Warehouse
      • 보존 기한이 있는 구조화된 데이터를 저장하고 처리하는 스토리지
      • 보통 BI 툴(Looker, Tableau, Superset, ...)은 DW를 백엔드로 사용

 

  • Data Pipeline의 정의
    • 데이터를 소스로부터 목적지로 복사하는 작업
      • 코딩(python) 혹은 SQL을 통해 이뤄짐
      • 보통 목적지는 DW
  • Data Pipeline의 종류
    • Raw Data ETL Jobs 
      1. 외부와 내부 데이터 소스에서 데이터를 읽어다가 (보통 API 사용)
      2. 적당한 데이터 포맷 변환 후 (데이터의 크기가 커지면 Spark 등이 필요)
      3. DW 로드
    • Summary / Report Jobs (ELT)
      1. DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
      2. Raw Data를 읽어서 일종의 리포트 형태나 써머리 평태의 테이블을 다시 만드는 용도
      3. 특수한 형태로는 AB테스트 결과를 분석하는 데이터 파이프라인도 존재
    • Production Data Jobs
      • DW로부터 데이터를 읽어 다른 Storage(보통 프로덕션 환경)로 쓰는 ETL
        • 써머리 정보가 프로덕션 환경에서 성능 이유로 필요
        • 머신러닝 모델에서 필요한 피쳐를 미리 계산해 두는 경우

✔ 데이터 파이프라인을 만들 때 고려사항

🍦 Best Practices 1

  • 가능하면 데이터가 작을 경우 매번 통째로 복사해서 테이블 생성 (Full Refresh)
  • Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 몇 가지 조건이 있음.
    • 데이터 소스가 프로덕션 DB 테이블이라면 다음 필드가 필요: created, modified, deleted
    • 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드를 읽을 수 있어야 함.

🍦 Best Practices 2

  • 멱등성(Idempotency)을 보장하는 것이 중요
    • 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 말아야 함
      • 중복 데이터 생성 X
    • critical point들이 모두 one atomic action으로 실행되어야 함
      • SQL의 transaction

🍦 Best Practices 3

  • 실패한 데이터 파이프라인의 재실행이 용이해야 함
  • 과거 데이터를 다시 채우는 과정 (Backfill)이 용이해야 함 <- Airflow의 강점

🍦 Best Practices 4

  • 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
    • 비지니스 오너 명시: 누가 이 데이터를 요청했는지를 기록화
    • 나중에 데이터 카탈로그로 들어가서 데이터 디스커버리에 사용 가능
      • 데이터 리니지가 중요

🍦 Best Practices 5

  • 주기적으로 쓸모없는 데이터를 삭제

🍦 Best Practices 6

  • 데이터 파이프라인 사고시 마다 사고 리포트 쓰기
    • 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함
    • 사고 원인(root-cause)을 이해하고 이를 방지하기 위한 액션 아이템의 실행이 중요
    • 기술 부채의 정도를 이야기해주는 바로미터

🍦 Best Practices 7

  • 중요 데이터 파이프라인의 입력과 출력을 체크
    • 아주 간단하게 입력 레코드 수와 출력 레코드 수가 몇 개인지 체크
    • 써머리 테이블을 만들어내고 PK uniqueness가 보장되는지 체크
    • 중복 레코드 체크

✔ Airflow

🍦 소개

  • 파이썬으로 작성된 데이터 파이프라인 (ETL) 프레임워크
  • 데이터 파이프라인 스케쥴링 지원
  • 다양한 데이터 소스와 DW를 쉽게 통합: https://airflow.apache.org/docs/
  • 데이터 파이프라인을 DAG(Directed Acyclic Graph)라고 호칭
  • Backfill 관련 다양한 기능을 제공

🍦 구성

총 5개의 컴포넌트로 구성

  • 웹 서버 - 스케줄러와 DAG의 실행 상황을 시각화
  • 스케줄러 - DAG를 워커에게 배정
  • Worker - 실제로 DAG를 실행
  • 메타 데이터 DB (sqlite가 기본)
  • 큐 (다수서버 구성인 경우에 사용) - Executor가 달라짐

 

스케줄러와 각 DAG의 실행결과는 별도 DB에 저장됨

  • 기본으로 설치되는 DB는 SQLite
  • 실제 프로덕션에서는 MySQL이나 Postgresql을 사용

 

Airflow 스케일링 방법

 

구조

서버 한 대
다수 서버

🍦 Airflow 개발의 장단점

  • 장점
    • 데이터 파이프라인 세밀하게 제어 가능
    • 다양한 데이터 소스와 DW 지원
    • Backfill이 용이
  • 단점
    • 배우기가 어려움
    • 상대적으로 개발환경을 구성하기가 쉽지 않음
    • 클라우드 버전 사용 선호
      • GCP: Cloud Composer
      • AWS: Managed Workflows for Apache Airflow
      • Azure: Data Factory Managed Airflow

🍦 DAG

  • Directed Acyclic Graph
  • ETL을 부르는 명칭
  • DAG는 Task로 구성
    • 3개의 Task라면 Extract, Transform, Load
  • Task - Airflow의 Operator를 통해 생성
    • Airflow에서 이미 다양한 종류의 오퍼레이터를 제공
    • 경우에 맞게 사용 오퍼레이터를 결정하거나 필요하다면 직접 개발
    • e.g. Redshift writing, Postgresql query, S3 Read/Write, Hive query, Spark job, shell script