데이터 웨어하우스 소개 & 데이터 파이프라인

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

데이터 웨어하우스

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

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

 

- 고정비용 옵션 : AWS의 Redshift

-> 매달 정해진 비용 부과

 

- 가변비용 옵션 : 구글의 BigQuery, Snowflake

-> 사용한 만큼 부과

 

=> 가변비용 옵션이 좀 더 확장가능한 옵션임. 처리할 수 있는 데이터의 크기가 크기 때문. 

 

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

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

 

데이터 레이크

: SQL을 기반으로 데이터 처리를 하는 관계형 데이터베이스

: 스토리지에 가까움

-> 데이터 웨어하우스는 로그 파일과 같은 비구조화 데이터를 저장하기 부적합함 (설계, 비용 문제)

반면에 데이터 레이크는 비구조화 데이터를 저장하기에 무리가 없음

구조화 데이터 + 비구조화 데이터

 

- 보통 클라우드 스토리지가 됨 

ex. AWS라면 S3가 대표적인 데이터 레이크라고 할 수 있음

 

보통 데이터를 데이터 레이크(스토리지)에 저장하고 (ETL) 

필요할 때마다 데이터 웨어하우스에 저장함(ELT)

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

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

 

 

ETL (Extract, Transform, Load) -> ELT

: ETL은 데이터 크기가 커지고 활용도가 늘어나면 ETL 수가 늘어남

-> ETL이 실패하는 경우 빠르게 고치는 것이 중요

-> 이를 적절하게 스케줄하고 관리하는 것이 중요

-> 이러한 관리를 쉽게 해주고 ETL 작성을 쉽게 해주는 툴이 Airflow

 

: ETL을 통해 데이터가 데이터 레이크 or 데이터 웨어하우스 안으로 들어오면,,,

이 데이터를 조인하여 새로운 정보를 만들어냄. 이것이 바로 ELT

 

-> 즉, 데이터를 분석하기 쉽게 요약 데이터로 만드는 과정을 ELT 라고 함! 

=> 이를 구현하는데 사용하는 기술이 dbt

 

 

Airflow

: ETL or ELT를 스케줄링해주고 문제 해결을 도움

- Airflow는 오픈소스 프로젝트로 파이썬 3 기반이며, 에어비앤비, 우버, 리프트, 쿠팡 등에서 사용

(AWS, 구글 클라우드, Azure 에서도 지원)

 

- AIrflow 에서는 ETL을 DAG로 부르며, 웹 인터페이스를 통한 관리 기능 제공

- 크게 3가지 컴포넌트로 구성 : 스케줄러, 웹서버, 워커(Worker)

- DAGs : 데이터 파이프라인 -> 정해진 시간에 실행됨

 

ELT

: 데이터 웨어하우스 내부 데이터를 조작하여 (보통 좀 더 추상화되고 요약된) 새로운 데이터를 만드는 프로세스

- 데이터 분석가가 이를 수행

- dbt가 이러한 프로세스 전용 기술임. (dbt를 사용하여 ELT를 수행하는 직군을 Analytics Engineering 이라함)

 

* ETL : 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스

-> 보통 데이터 엔지니어가 이를 수행

 

ETL / ELT 과정 예시

- 다양한 데이터 소스(프로덕션 DB, 유저 데이터, 카드 데이터 등)를 소스별로

ETL을 Airflow 위에서 구현 -> 주기적으로 자동 실행

-> 데이터 웨어하우스 내의 테이블로 복제

-> 다양한 원본 데이터를 ELT로 요약 테이블 생성(bdt 툴 사용) (소비하기 쉬운 형태로 요약된 테이블을 만듦)

-> 이러한 요약 테이블을 바탕으로 대시보드 제작, 데이터 분석 등 진행

 

* 데이터가 커지면 ELT 과정에서 다양한 이슈 발생

-> 이 부분에서 빅데이터 처리 기술이 필요해짐(Spark 등)

 

 

빅데이터 처리 프레임워크

: 다수의 서버로 구성된 분산 시스템 -> 하나의 부모 아래 여러 개의 자식 형태로 되어있음

- Fault Tolerance : 소수의 서버가 고장나도 동작해야함 -> 여러개의 서버에 중복 저장

- 확장 용이 : Scale out이 되어야함(용량을 증대하기 위해 서버의 개수 추가)

 

* 1세대 : 하둡 기반의 Map reduce, Hive/Presto(Map reduce를 SQL로 쓰는 것)

* 2세대 : Spark (빅데이터와 관계된 거의 모든 일을 수행함)

* HDFS : 분산 파일 시스템

 

데이터 웨어하우스 옵션들

확실히 기억하고 싶은 내용이라 별도 정리해둠. 

2024.04.16 - [데이터 분석] - 데이터 웨어하우스의 옵션들

데이터 웨어하우스의 옵션들

 

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

: 실리콘밸리 회사들은 어떤 기술들을 사용할까?

 

데이터 플랫폼의 발전단계

초기단계 : 데이터 웨어하우스 + ETL

- 클라우드 : 대부분 AWS 사용

- 빅데이터 시스템 : 대부분 Spark 사용

- 대시보드 : 자체제작, Looker, Tableau, Power BI 등

- 데이터 파이프라인 프레임워크 : Airflow

 

발전단계 : 데이터 양 증가

==> 

- Spark와 같은 빅데이터 처리 시스템 도입

- 데이터 레이크 도입 -> 비구조화 데이터 & 더 큰 데이터 저장

   - 로그 데이터와 같은 대용량 비구조화 데이터 대상

 

* 데이터 적재 과정

- 데이터 소스(기본적으로 수집된 데이터) -> 데이터 파이프라인 -> 데이터 웨어하우스에 적재

- 데이터 소스 -> 데이터 파이프라인 -> 데이터 레이크에 적재

- 데이터 레이크 -> 데이터 파이프라인 -> 데이터 웨어하우스에 적재

- 데이터 레이크 -> 데이터 파이프라인 -> 데이터 레이크에 저장

- 데이터 웨어하우스 -> 데이터 파이프라인 -> 데이터 웨어하우스에 저장

 

데이터 레이크의 데이터는 크기가 크기 때문에 빅데이터 처리 시스템 필요(Spark/Hadoop(Hive/Presto) 등)

 

성숙단계 : 현업 단의 데이터 활용 가속화

==>

ELT 고도화 및 중요해짐 -> dbt (analytics engineering 도입)

머신러닝 모델 -> 머신러닝 효율성 증대 노력(MLOps 직군)

 

데이터 파이프라인이란?

데이터 파이프라인 = ETL (Extract,Transform, Load)

= 데이터 워크플로우 = DAG(Directed Acyclic Graph, Airflow에서 ETL를 지칭하는 용어)

 

=> 데이터 소스(기초 데이터)에서 재가공을 통해 데이터 레이크 혹은 데이터 웨어하우스에 저장하는 과정!!

즉, 데이터를 소스로부터 목적지(대부분 데이터 웨어하우스)로 복사하는 작업

(파이썬, 스칼라, SQL 등을 통해 이뤄짐)

 

데이터 소스의 예

: 프로덕션 데이터베이스, 로그파일, API, 실시간 스트림 데이터 등,,

-> 클릭 로그, 광고 로그, 판매 정보, 센서 데이터 등 모두

 

데이터 목적지의 예

: 데이터 웨어하우스, 캐시 시스템, 프로덕션 데이터베이스 등

 

데이터 파이프라인의 종류

(1) Raw Data ETL

: 데이터 시스템 밖에 있는 데이터를 읽어다 데이터 시스템 내부에 저장

: 외부와 내부 데이터 소스에서 데이터를 읽어(API 사용) 데이터 포맷 변환 후(Spark 등 사용) 데이터 웨어하우스에 로드

-> 보통 데이터 엔지니어가 진행

 

(2) Summary / Report Jobs

: 성격이 ELT와 같음 -> 데이터 웨어하우스에서 데이터를 읽어 다시 데이터 웨어하우스에 적재하는 과정

: 데이터 소스와 데이터 목적지가 동일한 경우

: Raw Data를 읽어 일종의 리포트 형태나 써머리 형태의 요약 테이블을 다시 만듦

: AB 테스트 결과를 분석하는 데이터 파이프라인도 존재

-> Analytics Engineer (dbt)

 

(3) Production Data Jobs

: 데이터 소스와 목적지가 정반대

- 데이터 웨어하우스로부터 데이터를 읽어 다른 스토리지에 저장하는 ETL

-> 데이터 분석 시 실시간으로 데이터를 분석하면 성능 문제가 발생하기에, 

데이터 웨어하우스에서 일정 시간동안 데이터를 읽어와 그 스토리지 상에서 데이터를 분석함

 

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

데이터가 늘어날수록 데이터파이프라인의 수 증가 -> 유지보수 비용 기하급수적으로 증가

 

(1) Full Refresh VS Incremental Update

* Full Refresh : 데이터가 작을 경우 매번 전체로 테이블 만들기

- 데이터가 작을 경우만 가능!! 

 

* Incremental Update : 변경된 부분만 읽어옴

- 새로 생긴 레코드, 삭제된 레코드, 내용이 변경된 레코드

- 데이터 소스가 똑똑해야함. 일정 기준을 바탕으로 변경된 레코드 읽어옴

(데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야함

=> created, modified, deleted 정보에 관한 레코드를 필수로 갖춰야 가능!!)

 

(2) 멱등성 보장

멱등성이란?

: 동일한 입력 데이터에서 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지면 안됨

ex. 중복 데이터 X. 

-> SQL 트랜잭션이 필수적임

 

(3) Backfill

: 데이터파이프라인이 실행 실패할 때, 재실행이 쉬워야 함

: 과거 데이터를 다시 채우는 과정(Backfill)이 쉬워야 함

-> Airflow는 이 부분에 강점을 갖고 있음

 

(4) 데이터 파이프라인 문서화

: 입력과 출력을 명확히하고 문서화 필요

+ 누가 이를 요청했는지 기록으로 남기기 (비즈니스 오너 명시)

=> 이것을 데이터 카탈로그에 기록하여 데이터 디스커버리에 사용

 

(5) 주기적으로 쓸모없는 데이터 삭제

: 필요없는 데이터 파이프라인 삭제 

 

(6) 사고 리포트 작성

: 의미있는 사고에 대해서 사고의 원인을 작성하여 재발생 방지

 

(7) 중요한 데이터 파이프라인의 입력과 출력 체크 필요

: 입출력의 레코드 수 계산, 출력을 테스트하여 진짜 필요한 것이 맞는지 확인. 중복 레코드 체크

==> 데이터 대상 유닛 테스트

 

간단한 ETL 작성하기

Extract : 데이터를 데이터 소스에서 읽어내는 과정. 보통 API 호출

Transform : 원본 데이터의 포맷을 원하는 형태로 변경. 필수 X

Load : 최종적으로 Data Warehouse에 테이블로 집어넣는 과정