1. 데이터 웨어하우스 소개

데이터 웨어하우스와 데이터 레이크와 ETL/ELT

 데이터 웨어하우스는 기본적으로 클라우드가 대세이다. 데이터가 커져도 문제가 없는 확장가능성과 적정한 비용이 중요하다. 크게 고정비용 옵션과 가변비용 옵션이 존재하며 후자가 좀더 확장가능한 옵션이다. AWS의 Redshift는 고정비용 옵션이고 구글 클라우드의 BIgQuery, 스노우플레이크(Snowflake)는 가변비용이다. 오픈소스 기반(Presto, Hive)을 사용하는 경우도 클라우드 버전 존재한다.데이터가 작다면 굳이 빅데이터 기반 데이터베이스를 사용할 필요는 없다.

 

 데이터 레이크는 구조화 데이터와 비구조화 데이터(로그 파일)가 합쳐진 형태이다. 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가깝다. 데이터 웨어하우스보다 몇 배는 더 크고 더 경제적인 스토리지이다. 데이터 레이크와 데이터 웨어하우스 바깥에서 안으로 데이터를 가져오는 것은 ETL, 데이터 레이크와 데이터 웨어하우스 안에 있는 데이터를 처리하는 것은 ELT이다. 

 

 ETL의 수는 회사의 성장에 따라 쉽게 100개 이상으로 늘어난다. 중요한 데이터를 다루는 ETL이 실패했을 경우 이를 빨리 고쳐서 다시 실행하는 것이 중요하다. 또, 적절하게 스케줄하고 관리하는 것이 중요해지며 그래서 ETL 스케줄러 혹 프레임워크이 필요해진다. 데이터 요약를 위한 ETL(ELT)도 필요하다. ETL은 다양한 데이터 소스에 있는 데이터를 읽어오는 일을 수행하지만 이를 모두 이해해서 조인해서 사용하는 것은 데이터가 다양해지고 커지면서 거의 불가능하다. 그래서 주기적으로 요약 데이터를 만들어 사용하는 것이 더 효율적이다.

 

 다양한 데이터 소스의 예들이 있다.

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

 다수의 ETL이 존재할 경우 이를 스케줄해주고 이들간의 의존관계(dependency)를 정의해주는 기능이 필요하다. 또, 특정 ETL이 실패할 경우 이에 관한 에러 메세지를 받고 재실행해주는 기능도 중요하다(Backfill). 그래서 ETL 관리 및 운영 프레임워크가 필요하다. 가장 많이 사용되는 프레임워크는 Airflow이다.

 빅데이터 처리 프레임워크는 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요하다. 그리고 소수의 서버가 고장나도 동작해야 하고, 확장이 용이해야 한다.

데이터 웨어하우스 옵션들

• AWS Redshift
  • 2012년에 시작된 AWS 기반의 데이터웨어하우스로 PB 스케일 데이터 분산 처리 가능
  • CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원
  • AWS내의 다른 서비스들과 연동이 쉬움
  • 배치 데이터 중심이지만 실시간 데이터 처리 지원
  • 웹 콘솔 이외에도 API를 통한 관리/제어 가능
• Snowflake
  • 2014년에 클라우드 기반 데이터웨어하우스로 시작됨 (2020년 상장)
  • 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라고 부름) 두 가지를 지원
• Apache Presto
  • Facebook이 2013년에 시작한 아파치 오픈소스 프로젝트
  • 다양한 데이터소스에 존재하는 데이터를 대상으로 SQL 실행 가능
  • CSV, JSON, Avro, ORC, Parquet 등과 같은 다양한 데이터 포맷을 지원
  • 배치 빅데이터 프로세싱 시스템
  • Hive와는 다르게 빠른 응답 속도에 최적화(메모리 기반)
  • 웹 UI와 커맨드라인 UI (CLI라고 부름) 두 가지를 지원
  • AWS Athena가 Presto를 기반으로 만들어짐
• Apache Iceberg
  • Netflix가 2018년에 시작한 아파치 오픈소스 프로젝트로 데이터 웨어하우스 기술이 아님
  • 대용량 SCD (Slowly-Changing Datasets) 데이터를 다룰 수 있는 테이블 포맷
  • 자바와 파이썬 API를 지원
  • Spark, Flink, Hive, Hudi 등의 다른 Apache 시스템과 연동 가능
• Apache Spark
  • UC 버클리 AMPLab이 2013년에 시작한 아파치 오픈소스 프로젝트
  • 빅데이터 처리 관련 종합선물세트
  • 다양한 분산처리 시스템 지원
  • 다양한 파일시스템과 연동 가능
  • CSV, JSON, Avro, ORC, Parquet 등과 같은 다양한 데이터 포맷을 지원
  • 다양한 언어 지원: 자바, 파이썬, 스칼라, R

실리콘밸리 회사들의 데이터 스택 트렌드

 데이터 플랫폼의 발전단계는 초기엔 데이터 웨어하우스와 ETL로 구성되었고 데이터 양이 증가하면서 Spark과 같은 빅데이터 처리시스템을 도입하였고 데이터 레이크를 도입하였다. 그리고 데이터 활용이 증대되어 ELT단이 더 중요해지면서 dbt 등의 analytics engineering 도입하였고 MLOps 등 머신러닝 관련 효율성 증대를 위한 노력이 필요해졌다.

실리콘밸리 회사 데이터 스택 비교

데이터 파이프라인 이란?

 데이터 파이프라인은 데이터를 소스로부터 목적지로 복사하는 작업이다. 이 작업은 보통 코딩(파이썬 혹은 스칼라)이나 SQL을 통해 이루어진다. 대부분의 경우 목적지는 데이터 웨어하우스가 된다. 데이터 소스의 예는 프로덕션 데이터베이스, 로그 파일, API, 실시간 스트림 데이터 등이 있다. 데이터 목적지의 예는 데이터 웨어하우스, 캐시 시템 (Redis, Memcache), 프로덕션 데이터베이스, NoSQL, S3 등이 있다.

 다음은 데이터 파이프라인의 종류이다.

• Raw Data ETL Jobs
  • 외부와 내부 데이터 소스에서 데이터를 읽음(많은 경우 API를 통하게 됨)
  • 적당한 데이터 포맷 변환 후(데이터의 크기가 커지면 Spark등이 필요해짐) 데이터 웨어하우스 로드
  • 이 작업은 보통 데이터 엔지니어가 함
• ELT (Summary/Report) Jobs
  • DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
  • Raw Data를 읽어서 일종의 리포트 형태나 요약 형태의 테이블을 다시만드는 용도
  • 특수한 형태로는 AB 테스트 결과를 분석하는 데이터 파이프라인도 존재
  • 요약 테이블의 경우 SQL (CTAS를 통해)만으로 만들고 이는 데이터 분석가가 하는 것이 맞음
  • 데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어 주느냐가 관건
• Production Data Jobs
  • DW로부터 데이터를 읽어 다른 Storage(많은 경우 프로덕션 환경)로 쓰는 ETL
  • 요약 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
  • 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우

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

• 가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블을 만든다(Full Refresh). Incremental update만이 가능하다면 대상 데이터소스가 갖춰야할 조건이 있다. 데이터 소스가 프로덕션 데이터베이스 테이블이라면 created, modified, deleted 필드가 필요하다. 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을
  읽어올 수 있어야 한다.
• 멱등성(Idempotency)을 보장하는 것이 중요하다. 즉, 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 말아야 한다(중복 데이터가 생기지 말아야 한다). 중요한 포인트는 critical point들이 모두 one atomic action으로 실행이 되어야 한다는 점이다.
• 실패한 데이터 파이프라인 재실행과 과거 데이터를 다시 채우는 과정(Backfill)이 쉬워야 한다.
• 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화한다. 
• 주기적으로 쓸모없는 데이터들을 삭제한다.
• 데이터 파이프라인 사고시 마다 사고 리포트(post-mortem)를 쓴다. 
• 중요 데이터 파이프라인의 입력과 출력을 체크한다. 

간단한 ETL 작성하기

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

 ETL 실습으로 웹상에 존재하는 이름 성별 CSV 파일을 Redshift에 있는 테이블로 복사할 것이다. 우선 각자에게 할당된 schema밑에 테이블을 생성한다. 데이터 소스로 CSV파일을 다운로드 한 후 extract, transform, load 3개의 함수를 파이썬으로 Colab에서 작성한다. 

 

공부하며 어려웠던 내용

주로 데이터 엔지니어가 하는 일을 배웠지만 데이터 분석가로서 데이터 관련 전체 과정을 정리할 수 있는 시간이었다.