Data Pipeline

May·2024년 5월 21일

1. 데이터 파이프라인 = ETL(Extract, Trasnform, Load)

  1. 데이터의 흐름과 데이터 팀의 발전 단계
    • 서비스에서 직접 생기는 데이터와 써드파티를 통해 생기는 간접 데이터
    1. 데이터 인프라
      • 필수
        • 데이터 파이프라인 = ETL : 데이터 웨어하우스에 데이터를 적재해주는 프로세스 = Airflow DAG 등
        • 데이터 웨어하우스 : 데이터 분석 전용 데이터베이스
      • 옵션
        • 규모가 커지면 → 빅데이터 처리 프레임워크 (spark, hadoop) 추가
        • 실시간 처리가 필요해지면 → kafka, spark streaming 등 추가
        • 머신러닝이 발전하면 → nosql, cassandra 등 추가
    2. 데이터 분석
      • 시각화 도구 : Tableau, Looker, Superset 등
    3. 데이터 과학 적용
      • 사용자 경험 개선 (추천, 검색 등의 개인화, 자동화 등)

  1. 데이터 웨어하우스의 구성 예
    1. 데이터 소스 (MySQL, Stripe, Mailchimp, Zendesk, Amplitude, RingCentral, Salesforce 등) → 다수의 ETL
    2. → 데이터 인프라(Airflow → 데이터 웨어하우스 → 분석용 데이터 생성(=ELT, 주로 데이터 분석가가 수행)
    3. → 대시보드

  1. 데이터 파이프라인

    1. ETL : Extract,Transform,Load

      • Extract : 데이터를 데이터 소스에서 읽어내는 과정. 보통 API 호출
      • Transform : 필요하다면 그 원본 데이터의 포맷을 원하는 형태로 변경시키는 과정. 굳이 변환할 필요는 없음
      • Load : 최종적으로 Data Warehouse에 테이블로 집어넣는 과정

    2. Data Pipeline, ETL, Data Workflow, DAG

      • DAG : Called DAG(Directed Acyclic Graph) in Airflow

    3. ETL vs. ELT

      • ETL : 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
        • 보통 데이터 엔지니어들이 수행
      • ELT : 데이터 웨어하우스 내부 데이터를 조작해서 (보통은 좀 더 추상화되고 요약된) 새로운 데이터를 만드는 프로세스
        • 보통 데이터 분석가들이 수행
        • 이 경우 데이터 레이크 위에서 이런 작업들이 벌어지기도 함
        • 이런 프로세스 전용 기술들이 있으며 dbt가 가장 유명 : Analytics Engineering
          • dbt = Data Build Tool

    4. Data Lake vs. Data Warehouse

      • 데이터 레이크(Data Lake)
        • 데이터 레이크는 원시 형태의 데이터(raw data)를 대량으로 저장하는 시스템
        • 구조화된 데이터 + 반구조화된 데이터 + 비구조화된 데이터
        • 주로 Hadoop 기반의 분산 파일 시스템(HDFS)을 사용
        • 특징
          • 유연성 : 다양한 데이터 유형을 저장할 수 있으며, 데이터는 구조화될 필요가 없다
          • 확장성 : 대용량 데이터를 처리하고 저장할 수 있는 확장성이 뛰어나다.
          • 원시 데이터 저장 : 데이터는 가공되지 않은 상태로 저장되며, 필요할 때 가공 및 분석된다.
          • 사용 사례 : 데이터 사이언스, 빅데이터 분석, 기계 학습 모델 훈련 등에서 활용
      • 데이터 웨어하우스 (Data Warehouse)
        • 데이터 웨어하우스는 구조화된 데이터를 저장하고 분석하는 시스템
        • 전통적으로 관계형 데이터베이스 관리 시스템(RDBMS) 기반
        • 특징
          • 구조화된 데이터 : 스키마가 사전에 정의되어 있으며, 데이터는 ETL(추출, 변환, 로드) 과정을 통해 저장
          • 성능 : 데이터 쿼리와 분석 성능이 뛰어나며, 비즈니스 인텔리전스(BI) 도구와 통합하여 사용된다.
          • 일관성 : 데이터가 일관된 형태로 저장되어 분석과 보고에 적합하다.
          • 사용 사례 : 경영 보고, 비즈니스 인텔리전스, 데이터 마트 등에서 활용

    5. Data Pipeline의 정의

      • 데이터를 소스로부터 목적지로 복사하는 작업
        • 이 작업은 보통 코딩(파이썬 혹은 스칼라) 혹은 SQL을 통해 이루어짐
        • 대부분의 경우 목적지는 데이터 웨어하우스가 됨
      • 데이터 소스의 예
        • Click stream, call data, ads performance data, transactiosn, sersor data, metadata, ...
        • more concrete cwamples : production databases, log files, API, stream data(Kafra topic)
      • 데이터 목적지의 예
        • 데이터 웨어하우스, 캐시 시스템(Redis, Memcache), 프로덕션 데이터베이스, NoSQL, S3, ...

    6. 데이터 파이프라인 종류

      • Raw Data ETL Jobs
        1. 외부(사외)와 내부(사내) 데이터 소스에서 데이터를 읽어다가 (많은 경우 API 사용)
        2. 적당한 데이터 포맷 변환 후 (데이터의 크기가 커지면 Spark 등이 필요해짐)
        3. 데이터 웨어하우스 로드
        • 이작업은 보통 데이터 엔지니어가 함
      • Summary/Report Jobs
        1. DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
        2. Raw Data를 읽어서 일종의 리포트 형태나 써머리 형태의 테이블을 다시 만드는 용도
        3. 특수한 형태로는 AB 테스트 결과를 분석하는 데이터 파이프라인도 존재
        • 요약 테이블의 경우 SQL(CTAS 사용)만으로 만들고 이는 데이터 분석가가 하는 것이 맞음. 데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어 주느냐가 관건
        • Analytics Engineer (DBT)
      • Production Data Jobs
        1. DW로부터 데이터를 읽어 다른 Storage(많은 경우 프로덕션 환경)로 쓰는 ETL
          a. 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
          b. 혹은 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우
        2. 이 경우 흔한 타켓 스토리지:
          a. Cassandra/HBase/DynamoDB와 같은 NoSQL
          b. MySQL과 같은 관계형 데이터베이스 (OLTP)
          c. Redis/Memcache와 같은 캐시
          d. ElasticSearch와 같은 검색엔진

  2. 데이터 파이프라인을 만들 때 고려할 점

    • 데이터 파이프라인은 많은 이유로 실패함
      • 버그
        - 데이터 소스상의 이슈: What if data sources are not available or change its data format
        - 데이터 파이프라인들간의 의존도에 이해도 부족
    • 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남
      - 데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐. 만일 마케팅 채널 정보가 업데이트가 안된다면 마케팅 관련 다른 모든 정보들이 갱신되지 않음
      - More tables needs to be managed (source of truth, search cost, …)

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

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

      • 실패한 데이터 파이프라인을 재실행이 쉬워야 함
      • 과거 데이터를 다시 채우는 과정(Backfill)이 쉬워야 함
      • Airflow는 이 부분(특히 backfill)에 강점을 갖고 있음

      • 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
        • 비지니스 오너 명시: 누가 이 데이터를 요청했는지를 기록으로 남길 것
        • 이게 나중에 데이터 카탈로그(=데이터에 대한 데이터)로 들어가서 데이터 디스커버리에 사용 가능함
          • 데이터 리니지가 중요해짐 -> 이걸 이해하지 못하면 온갖 종류의 사고 발생

      • 주기적으로 쓸모없는 데이터들을 삭제
        • Kill unused tables and data pipelines proactively
        • Retain only necessary data in DW and move past data to DL (or storage)

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

      • 중요 데이터 파이프라인의 입력과 출력을 체크하기(=data unit test)
        • 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇개인지 체크하는 것부터 시작
        • summary 테이블을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요함
        • 중복 레코드 체크
profile
May
이전 포스트

[데브코스TIL] Redshift 02

0개의 댓글