데이터분석

41. 데이터 웨어하우스, 데이터 파이프라인

장수우 2024. 1. 29. 23:00
학습 주제
  • 데이터 웨어하우스와 데이터 레이크와 ETL / ELT
  • 데이터 웨어하우스 옵션들
  • 실리콘밸리 회사들의 데이터 스택 트렌드
  • 데이터 파이프라인이란?
  • 데이터 파이프라인을 만들 때 고려할 점
  • 간단한 ETL 작성하기
주요 학습 내용
  • 데이터 웨어하우스 옵션별 장단점
    • 데이터 웨어하우스는 기본적으로 클라우드가 대세
    • AWS의 Redshift, 구글 클라우드의 BigQuery, Snowflake
      - Redshift는 고정비용 옵션이며 BigQuery와 Snowflake는 가변비용
    • 데이터가 작다면 굳이 빅데이터 기반 데이터베이스를 사용할 필요가 없다.
    • 오픈소스 기반 (Presto, Hive)을 사용하는 경우도 클라우드 버전 존재
    • 크게 고정비용 옵션과 가변비용 옵션이 존재, 후자가 좀더 확장 가능한 옵션
    • 데이터가 커져도 문제가 없는 확장가능성(Scalable)과 적정한 비용이 중요
  • 데이터 레이크
    • 구조와 데이터 + 비구조화 데이터(로그 파일) 
    • 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가깝다.
    • 보통은 데이터 웨어하우스보다 몇 배는 더 크고 더 경제적인 스토리지
    • 보통 클라우드 스토리지가 된다.
      - AWS 라면 S3가 대표적인 데이터 레이크라 볼 수 있다.
    • 데이터 레이크가 있는 환경에서 ETL과 ELT
      - 데이터 레이크와 데이터 웨어하우스 바깥에서 안으로 데이터를 가져오는 것 : ETL
      - 데이터 레이크와 데이터 웨어하우스 안에 있는 데이터를 처리하는 것 : ELT
  • ETL(Extract, Transform, Load) -> ELT
    • ETL의 수는 회사의 성장에 따라 쉽게 100+ 개 이상으로 발전한다.
      - 중요한 데이터를 다루는 ETL이 실패했을 경우 이를 빨리 고쳐서 다시 실행하는 것이 중요
    • 이를 적절하게 스케줄하고 관리하는 것이 중요해지며 그래서 ETL 스케줄러 혹은 프레임웍이 필요하다
      - Ariflow가 대표적 프레임워크
    • 데이터 요약을 위한 ETL도 필요하다 -> ELT 라고 부른다.
      - 앞에서 설명한 ETL은 다양한 데이터 소스에 있는 데이터를 읽어오는 일은 수행한다.
      - 이를 모두 이해하면서 조인 후 사용하는 것은 데이터가 다양해지고 커지면서 불가능에 가깝다.
      - 주기적으로 요약 데이터를 만들어 사용하는 것이 더 효율적이다. ex) 고객 매출 요약 테이블 , ...
  • Airflow (ETL 스케줄러) 소개
    • ETL 관리 및 운영 프레임웍의 필요성
      - 다수의 ETL이 존재할 경우 이를 스케줄해주고 이들간의 의존관계를 정의 해주는 기능이 필요하다.
      - 특정 ETL이 실패할 경우 이에 관한 에러 메세지를 받고 재실행해주는 기능도 중요하다(Backfill)
    • 가장 많이 사용되는 프레임웍 = Airflow
      - 오픈소스 프로젝트로 파이썬 3 기반, 에어비앤비, 우버, 리프트, 쿠팡등에서 사용한다.
      - AWS와 구글클라우드와 Azure에서도 지원
    • ETL을 DAG라 부르며 웹 인터페이스를 통한 관리 기능을 제공
    • 스케줄러, 웹서버, 워커로 구성
  • ELT
    • ETL : 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
      - 보통 데이터 엔지니어가 수행
    • ELT : 데이터 웨어 하우스 내부 데이터를 조작해서 새로운 데이터를 만드는 프로세스
      - 전용기술들이 있으며 dbt가 가장 유명하다 : Analyics Engineering
      - 데이터분석가가 수행
      - 데이터 레이크를 쓰기도 한다.
    • 데이터 레이크에서 데이터 웨어하우스 넘어가는 부분에서 빅데이터 처리 기술이 필요해진다.(Spark 등)
  • 빅데이터 처리 프레임웍
    • 분산 환경 기반(1대 혹은 그 이상의 서버로 구성)
      - 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요
    • Fault Tolerance
      - 소수의 서버가 고장나도 동작해야한다.
    • 확장이 용이해야한다.
      - Scale Out이 되어야한다.
      - 용량을 증대하기 위해서 서버 추가
  • 대표적인 빅데이터 프로세싱 시스템
    • 1세대 : 하둡기반의 Mapreduce, Hive / Presto
    • 2세대 : Spark (SQL, DataFrame, Streaming, ML, Graph)
  • AWS Redshift
    • 2012년에 시작된 AWS기반의 데이터웨어하우스, PB 스케일 데이터 분산 처리 가능하다.
    • CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원한다.
    • AWS 내의 다른 서비스들과 연동이 쉽다.
    • 배치 데이터 중심이지만 실시간 데이터 처리를 지원한다.
    • 웹 콘솔 이외에도 API를 통한 관리 / 제어 가능하다.
  • Snowflake
    • 2014년에 클라우드 기반 데이터웨어하우스로 시작되었다 (20년 상장)
    • SQL 기반으로 빅데이터 저장, 처리, 분석을 가능하게 해준다.
    • CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원한다.
    • 배치 데이터 중심이지만 실시간 데이터 처리 지원
    • 웹 콘솔 이외에도 API를 통한 관리 / 제어 가능하다.
  • Google Cloud Bigquery
    • 2010년에 시작된 구글 클라우드의 데이터 웨어하우스 서비스
    • CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원한다.
    • 구글 클라우드 내의 다른서비스들과 연동이 쉽다.
    • 배치 데이터 중심이지만 실시간 데이터 처리 지원한다.
    • 웹 콘솔 이외에도 API를 통한 관리 / 제어 가능하다.
  • Apache Hive
    • Facebook이 2008년에 시작한 아파치 오픈소스 프로젝트
    • 하둡기반으로 동작하는 SQL 기반 데이터 웨어하우스 서비스
    • CSV, , JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원한다.
    • 배치 빅데이터 프로세싱 시스템
      - 데이터 파티셔닝과 버킷팅과 같은 최적화 작업 지원한다.
    • 웹 UI와 커멘드라인 UI(CLI라고 부른다) 두 가지를 지원한다.
    • 점점 Spark에 의해 밀리는 분위기
  • Apache Presto
    • HIVE와 거의 동일
    • AWS Athena가 바로 Presto를 기반으로 만들어졌다.
  • Apache lceberg
    • Netflix 가 2018년에 시작한 아파치 오픈소스 프로젝트로 데이터 웨어하우스 기술이 아니다.
    • 대용량 SCD (Slowly-Changing Datasets) 데이터를 다룰 수 있는 테이블 포맷
      - HDFS, S3, Azure Blob Storage 등의 클라우드 스토리지 지원
      - ACID 트랙잭션과 타임여행 (과거 버전으로 롤백과 변경 기록 유지 등등)
      - 스키마 진화 (Schema Evolution) 지원을 통한 컬럼 제거와 추가 가능 (테이블 재작성 없이) 
    • 자바와 파이썬 API를 지원
    • Spark, Flink, Hive, Hudi 등의 다른 Apache 시스템과 연동 가능
  • Apache Spark
    • UC 버클리 AMPLab이 2013년에 시작한 아파치 오픈소스 프로젝트
    • 빅데이터 처리 관련 종합선물세트
    • 다양한 분산처리 시스템 지원
    • 다양한 파일시스템과 연동 가능
    • CSV, JSON, Avro, ORC, Parquet 등과 같은 다양한 데이터 포맷을 지원
    • 다양한 언어 지원: 자바, 파이썬, 스칼라, R
  • 데이터 플랫폼의 발전단계
    • 초기 단계 : 데이터 웨어하우스 + ETL
    • 발전 단계 : 데이터 양 증가
      - Spark와 같은 빅데이터 처리시스템 도입
      - 데이터 레이크 도입 : 보통 로그 데이터와 같은 대용량 비구조화 데이터 대상
      - 데이터 소스 -> 데이터 파이프라인 -> 데이터 웨어하우스
      - 데이터 소스 -> 데이터 파이프라인 -> 데이터 레이크
      - 데이터 레이크 -> 데이터 파이프라인 -> 데이터 웨어하우스
      ▪ 이때 Spark/Hadoop 등이 사용됨
      ▪ Hadoop: Hive/Presto등이 기반됨
    • 성숙 단계 : 데이터 활용 증대
      - 현업단의 데이터 활용이 가속화
      - ELT 단이 더 중요해지면서 dbt 등의 analytics engineering 도입
      - 데이터 레이크 to 데이터 레이크, 데이터 레이크 to 데이터 웨어하우스, 데이터 웨어하우스 to 데이터 웨어하우스
      - MLOps 등 머신러닝 관련 효율성 증대 노력 증대
  • 데이터 파이프라인의 정의
    • 데이터를 소스로부터 목적지로 복사하는 작업
      - 보통 코딩(파이썬 혹은 스칼라) 혹은 SQL을 통해 이뤄짐
      - 대부분의 경우 목적지는 데이터 웨어하우스가 된다.
    • 데이터 소스의 예시
      - 프로덕션 데이터베이스, 로그 파일, API, 실시간 스트림 데이터, …
      - 데이터의 예Click stream, call data, ads performance data, transactions, sensor data, …
    • 데이터 목적지의 예시
      - 데이터 웨어하우스, 캐시 시스템 (Redis, Memcache), 프로덕션 데이터베이스, NoSQL, S3, ...
  • 데이터 파이프라인의 종류 ( 보통 데이터 엔지니어가 수행)
    • Raw Data ETL Jobs
      1. 외부와 내부 데이터 소스에서 데이터를 읽어다가 (많은 경우 API를 통하게 됨)
      2. 적당한 데이터 포맷 변환 후 (데이터의 크기가 커지면 Spark등이 필요해짐)
      3. 데이터 웨어하우스 로드
    • ELT (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
        - 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
        - 혹은 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우
      2. 흔한 타켓 스토리지
        - Cassandra/HBase/DynamoDB와 같은 NoSQL
        - MySQL과 같은 관계형 데이터베이스 (OLTP)
        - Redis/Memcache와 같은 캐시
        - ElasticSearch와 같은 검색엔진
  • 데이터 파이프라인을 만들 때 고려할 점
    • 버그
    • 데이터 소스상의 이슈 : 동작하지 않거나, 포맷이 바뀜
    • 데이터 파이프라인들 간의 의존도에 이해도 부족
    • 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어난다.
    • 데이터 소스간의 의존도가 생기면서 더 복잡해진다.
    • 관리해야하는 DW상의 테이블도 늘어난다.
  • Best Practices
    • 가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블 만들기 (Full Refresh)
    • Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 몇가지 조건
      1. created(데이터 업데이트 관점에서는 불필요)
      2. modified
      3. deleted
      4. 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야함
    • 역동성(Idempotency)를 보장하는 것이 중요하다
      • 역동성이란?
      • 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 말아야 한다
    • 실패한 데이터 파이프라인을 재실행이 쉬어야한다
    • 과거 데이터를 다시 채우는 과정(Backfill)이 쉬어야 한다
    • Airflow는 backfill에 강점을 가지고 있다.
    • 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화 한다
      • 비지니스 오너 명시 : 누가 이 데이터를 요청했는지를 기록흐로 남긴다.
      • 나중에 데이터 카탈로그로 들어가서 데이터 디스커버리에 사용 가능하다
        - 데이터 리니지가 중요해졌다 -> 이해 못할 시 온갖 종류의 사고가 발생
    • 주기적으로 쓸모없는 데이터들을 삭제한다
    • 데이터 파이프라인 사고시마다 사고 리포트(post-mortem) 쓰기
      1. 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함
      2. 사고 원인(root-cause)을 이해하고 이를 방지하기 위한 액션 아이템들의 실행이 중요해짐
      3. 기술 부채의 정도를 이야기해주는 바로미터
    • 중요 데이터 파이프라인의 입력과 출력을 체크하기
      1. 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇개인지 체크하는 것부터 시작
      2. 써머리 테이블을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 체크
      3. 중복 레코드 체크
      4. 1~3번 반복
공부하면서 어려웠던 점

 - 

반응형

'데이터분석' 카테고리의 다른 글

43. 지표의 이해와 좋은 지표란?  (2) 2024.01.30
42. Snowflake  (1) 2024.01.29
35. 데이터 분석 프로세스  (1) 2024.01.27
34. 회귀분석과 데이터모델링  (1) 2024.01.27
33-(3). seaborn  (1) 2024.01.15

'데이터분석'의 다른글

  • 현재글41. 데이터 웨어하우스, 데이터 파이프라인

관련글

티스토리툴바