<aside> 💡 데이터 웨어하우스와 데이터 레이크와 ETL/ELT

데이터 웨어하우스와 데이터 레이크에 대해 알아보고 다음으로 ETL/ELT에 대해 알아보자

</aside>

데이터 웨어하우스 옵션별 장단점

• 데이터 웨어하우스는 기본적으로 클라우드가 대세

• 데이터가 커져도 문제가 없는 확장가능성(Scalable)과 적정한 비용이 중요한 포인트

• 크게 고정비용 옵션과 가변비용 옵션이 존재하며 후자가 좀더 확장가능한 옵션

• AWS의 Redshift, 구글 클라우드의 BigQuery, 스노우플레이크(Snowflake)

  • Redshift는 고정비용 옵션이며 BigQuery와 스노우플레이크는 가변비용

• 오픈소스 기반(Presto, Hive)을 사용하는 경우도 클라우드 버전 존재

• 데이터가 작다면 굳이 빅데이터 기반 데이터베이스를 사용할 필요가 없음

• 데이터 레이크

  • 구조화 데이터 + 비구조화 데이터 (로그 파일)
  • 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움
  • 보통은 데이터 웨어하우스보다 몇 배는 더 크고 더 경제적인 스토리지
  • 보통 클라우드 스토리지가 됨
    • AWS라면 S3가 대표적인 데이터 레이크라 볼 수 있음
  • 데이터 레이크가 있는 환경에서 ETL과 ELT

    • 데이터 레이크와 데이터 웨어하우스 바깥에서 안으로 데이터를 가져오는 것: ETL

      • load의 목적지는 데이터 레이크가 될 수도, 데이터 웨어하우스가 될 수도.. 그것은 목적에 따라 다르다.

    • 데이터 레이크와 데이터 웨어하우스 안에 있는 데이터를 처리하는 것: ELT

      

ETL(Extract, Transform, Load) ⇒ ELT

• ETL의 수는 회사의 성장에 따라 쉽게 100+개 이상으로 발전

• 중요한 데이터를 다루는 ETL이 실패했을 경우 이를 빨리 고쳐서 다시 실행하는 것이 중요

• 이를 적절하게 스케줄하고 관리하는 것이 중요해지며 그래서 ETL 스케줄러 혹은 프레임워크가 필요해짐

  • Airflow가 대표적인 프레임웍

• ELT

  • 데이터 요약를 위한 ETL도 필요해짐 → ELT라고 부름
  • dbt는 ELT 프레임워크
  • Airflow와 dbt를 같이 mix해서 사용이 가능하다.
  • 앞에서 설명한 ETL은 다양한 데이터 소스에 있는 데이터를 읽어오는 일을 수행.
  • 하지만 이를 모두 이해해서 조인해서 사용하는 것은 데이터가 다양해지고 커지면서 거의 불가능해짐.
  • 소스 단에서 읽어온 데이터들을 조인해서 정리하고 요약하는 과정이 필요하다
  • 주기적으로 요약 데이터를 만들어 사용하는 것이 더 효율적. dbt 사용

    • 예) 고객 매출 요약 테이블, 제품 매출 요약 테이블, …

      

• 다양한 데이터 소스의 예

  • 프로덕션 데이터베이스(웹/앱에서 사용하는 데이터베이스)의 데이터
    • 보통 MySQL, Postgres등이 프로덕션 데이터베이스로 사용됨
  • 이메일 마케팅 데이터
    • Mailchimp, HubSpot, SendGrid, ...
  • 크레딧카드 매출 데이터
    • Stripe
  • 서포트 티켓 데이터
    • Zendesk, Kustomer, ...
  • 서포트 콜 데이터
    • ChannelTalk, RingCentral, Talkdesk, …
  • 세일즈 데이터
    • Salesforce
  • 사용자 이벤트 로그
    • Amplitude, MixPanel, 웹서버로그, ...