[TIL] 8주차_Day31: 데이터 웨어하우스 관리, 고급 SQL, BI 대시보드 (1)

💡Today I Learned

• 데이터 웨어하우스, SQL, BI 대시보드에 대한 첫 번째 수업을 진행했습니다.

---

1. 데이터 팀의 역할

- 데이터 조직이 하는 일

: 신뢰할 수 있는 데이터를 바탕으로 부가 가치(=간접 매출)를 생성

: 결정 과학(Decision Science) → 데이터 기반 지표(KPI) 정의, 대시보드/리포트 생성

: (Product Science) 고품질 데이터 기반 사용자 경험 개선, 프로세스 최적화 → by.ML 알고리즘

 

- 데이터 팀의 발전 단계

: 온라인 서비스에서 생기는 데이터 → 데이터 인프라(Production db, ETL/ELT) → 데이터 분석(지표 정의, 시각화, ...) ↔ 데이터 과학 적용(사용자 경험 개선 ex) 추천, 검색 등의 개인화 서비스)

 

1. 데이터 인프라 구축 = 데이터 엔지니어가 수행

: 인프라 = ETL(Airflow) + 웨어하우스 (Redshift, SnowFlake, BigQuery, ...)

 

2. 데이터 분석 (지표 정의, 시각화, 리포팅) = 데이터 분석가가 수행

: 대시보드 (ex: Looker, Tableau, Power BI, Superset)

: 지표 (3A = Accessible_자동화된 시각화 대시보드, Actionable_지표가 오르고 내리는 의미 이해 가능, Auditable_지표 값이 맞는지 확인 가능해야 함) 가 중요

: KPI의 예) 매출액, 월간/주간 액티브 사용자 수, ...

 

3. 데이터 과학 적용 (사용자 경험 개선) = 데이터 과학자가 머신러닝 모델을 만들어 수행

: AI팀, Product Science팀, ...

: 머신 러닝 = 프로그래밍 없이 배움이 가능한 알고리즘, 데이터로부터 패턴을 찾아 학습 → 데이터의 품질/크기 중요

 

- 데이터 웨어하우스

: 회사에 필요한 모든 데이터를 모아놓은 중앙 db

: 데이터의 크기에 맞게 어떤 db를 사용할지 선택

: 프로덕션 운영용 DB와 별개의 DB여야 함

• 프로덕션 데이터 베이스 - OLTP(Transaction): 서버 한 대에 저장할 수 있는 데이터의 양에 제한, 속도 빨라야 함 / 용량 적음 (ex: MySQL, PostgreSQL) (for 백엔드 엔지니어)
• 데이터 웨어하우스 - OLAP(Analytical): 분석을 목적, 속도 느림 / 용량 큼 (for 데이터 사이언티스트/분석가/엔지니어, 마케팅 직원, PM)

 

- ETL

: Extract, Transform, Load == Pipeline

: 다른 곳에 존재하는 데이터를 가져와서 웨어하우스에 로드

: Extract = 외부 데이터 소스에서 데이터 추출

: Transform = 추출한 데이터 포맷 변환 (+정제)

: Load = 데이터 웨어하우스로 적재

: ex) Airflow (오픈소스 프로젝트, 파이썬 기반, Airbnb에서 시작함)

 

2. 데이터 조직의 구성원

: 데이터 엔지니어 + 분석가 + 과학자

 

- 데이터 엔지니어

: 기본적으로는 SW 엔지니어

: 데이터 웨어하우스 구축 (ETL, 클라우드, Redshift, BigQuery, SnowFlake)

: ETL 코드 작성하고 주기적으로 실행 (ETL 스케줄러 or 프레임워크_Airflow)

: 데이터 분석가 & 과학자를 지원

: MLOps(데이터 엔지니어 + 과학자 + DevOps), ML Engineer(데이터 엔지니어 + 과학자)가 다음 스텝

*) 필요한 기술: SQL, 컨테이너 기술(도커, 쿠버네티스), 클라우드 컴퓨팅, ML, A/B 테스트, 통계 지식

 

- 데이터 분석가

: 비즈니스 인텔리전스를 책임짐

: 주요 지표(KPI)를 정의, 대시보드 형태로 시각화

: 대시보드 → 태블로(Tableau), 룩커(Looker), 수퍼셋(Superset)

: 비즈니스 도메인에 대한 깊은 지식

: 임원, 리더들이 데이터 기반 결정을 내릴 수 있도록 도움

: (현재 트랜드) 데이터 활용 능력이 있는 팀들 내에서 자체적으로 행하거나, 현업 팀에 소속.. → Citizen Data Analyst

*) 필요한 기술: SQL, 대시보드 툴, 데이터 모델링(여러 데이터 join으로 새로운 테이블 생성, 스키마 정의), 통계 지식, 비즈니스 도메인 지시, KPI 정의 능력 (코딩을 많이 하지는 x)

 

- MLOps

DevOps → 개발자가 만든 코드를 시스템에 반영하는 프로세스 = CI/CD, 시스템 모니터링

MLOps → DevOps와 하는 일 동일, but ML 모델을 대상으로 함, 모델 빌딩/배포/모니터링

: 계속적인 모델 빌딩 & 배포 (프레임워크: AWS SageMaker, MLflow, Kubeflow, ...)

: 모델 서빙 환경과 모델의 성능 저하를 모니터링

: 필요시 escalation 프로세스 진행

: 데이터 엔지니어 + DevOps 엔지니어 + 머신러닝 관련 경험/지식 모두가 필요

 

- 프라이버시 엔지니어

: 전체 시스템에서 개인정보 보호를 위한 가이드라인/툴 제공

 

- 데이터 디스커버리

: 데이터 팀이 커질 때 꼭 필요한 테이블, 대시보드 검색 서비스 (DB를 뒤져 검색)

: 데이터가 커짐 → 테이블, 대시보드의 수도 증가 → 필요한 것 찾는 데 시간이 많이 소요..

: 주기적인 테이블, 대시보드 정제가 필수

 

3. 데이터 웨어하우스

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

: 기본적으로 클라우드 *) 데이터가 적다면 굳이 빅데이터 기반 DB를 사용할 필요가 없음

: 데이터가 커져도 문제 없는 확장 가능성 & 적절한 비용

: 고정비용 옵션 (Redshift) & 가변비용 옵션 (Snowflake) 이 존재함

: 가변비용 옵션 → 더 Scalable, powerful 하지만, 비용 예측이 안됨 (따라서 처음 시작 시에는 고정비용도 ㄱㅊ)

 

- 데이터 레이크

: 구조화 +  비구조화 데이터 (로그 파일)

: 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움

: 데이터 웨어하우스보다 몇 배는 더 크고 더 경제적인 스토리지

: 보통 클라우드 스토리지 (ex: AWS의 S3가 대표적인 데이터 레이크)

: ETL = 데이터 레이크와 데이터 웨어하우스 바깥에서 안으로 데이터를 가져옴 (ex: Airflow)

: ELT = 데이터 레이크와 데이터 웨어하우스 안의 데이터를 프로세싱하는 것 (ex; CTAS로, 혹은 DBT)

 

- ETL → ELT

: ETL의 수는 회사의 성장에 따라 발전

: 데이터 요약을 위한 ETL == ELT 도 필요

 

- 데이터 소스의 예

: 서비스의 production DB (웹/앱에서 사용하는 DB) ex: MySQL, PostgreSQL

: 이메일 마케팅 데이터, 세일즈 데이터, 사용자 이벤트 로그 (비정형 데이터 → 데이터 레이크에 적재), 신용카드 매출 데이터, etc...

 

- Airflow (ETL 스케줄러)

: ETL 관리, 운영 프레임워크

: ETL이 실패할 경우 이에 대한 에러 메시지를 받고 재실행해주는 기능도 제공 (Backfill)

: Airflow에서의 ETL을 'DAG'라고 부름 (웹 UI를 통한 관리 기능)

: 3가지 컴포넌트로 구성 = 스케줄러 + 웹 서버 + 워커

 

- 데이터 웨어하우스의 구성 예

1. 데이터 소스 → [ETL_Airflow위에서 구현] → 2. 데이터 인프라 (요약 테이블_ELT 만들기, 데이터 웨어하우스) → 3. 대시보드, 데이터 분석

 

- ELT

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

: ELT 과정에서 빅데이터 처리 기술(ex: Spark, 하둡)이 필요해짐 (굉장히 큰 로그 파일들이 적재)

: DBT, 데이터 레이크 사용

: 보통 데이터 분석가가 이를 수행함

 

: 데이터 레이크의 로그를 정제해서 새로운 정보를 만들어 웨어하우스에 로딩

: 데이터 웨어하우스의 테이블을 join해 새로운 정보를 만듦

: 데이터 분석/활용을 쉽게 하기 위해, 먼저 소스단에서 읽어온 데이터를 join해 정리/요약하는 과정

 

→ 즉, 데이터 웨어하우스의 원본 데이터 그대로 쓰기 불편한 경우, 추상화를 통해 레이어를 하나 더 쌓음, 정보들을 더 소비하기 쉬운 형태로 만드는 프로세스가 ELT ! 다양한 소스의 데이터들을 요약한 요약 테이블을 만듦

 

- 빅데이터 처리 프레임워크

: 분산 환경 기반 (1대 이상의 서버로 구성)

: Fault Tolerance → 소수의 서버가 고장이 나도 전체 서비스는 안정적으로 동작해야 함

: Scale Out 가능해야 함 (용량 증대 시 서버를 사서 시스템에 추가, 서버의 개수를 늘림)

*) Scale Up: 이미 있는 서버들의 사양을 높임 (ex: CPU, 메모리)

 

4. 데이터 웨어하우스 옵션들

- AWS Redshift

: SQL 지원 & 다양한 데이터 포맷 지원 (csv, json, avro, parquet..)

: AWS 내 다양한 서비스들과의 연동이 쉬움 (ML 모델의 실행도 지원_AWS SageMaker)

: 배치 데이터 중심이지만 실시간 데이터 처리 지원 (실시간 → AWS Kinesis와 연동)

: 웹 콘솔 이외에도 API를 통한 관리/제어 가능

 

- Snowflake

: SQL 지원 & 다양한 데이터 포맷 지원 (csv, json, avro, parquet..)

: 배치 데이터 중심이지만 실시간 데이터 처리 지원

: 웹 콘솔 이외에도 API를 통한 관리/제어 가능

: 데이터 판매를 통한 매출을 가능케 해주는 Data Sharing, Marketplace 제공

: ETL, 데이터 통합 기능 제공

: 특정 클라우드가 아닌 다양한 클라우드 서비스 연동 가능

 

- Goggle Cloud BigQuery

: SQL 지원 & 다양한 데이터 포맷 지원 (csv, json, avro, parquet..)

: 배치 데이터 중심이지만 실시간 데이터 처리 지원

: 웹 콘솔 이외에도 API를 통한 관리/제어 가능

: 데이터 판매를 통한 매출을 가능케 해주는 Data Sharing, Marketplace 제공

: 가변 비용(스토리지, 컴퓨팅 분리해서 업그레이드 가능), 고정 비용(둘을 같이 업그레이드 해야함) 옵션 모두 지원

: 구글 클라우드 내 다른 서비스들과의 연동

 

- Apache Hive

: 하둡 기반으로 동작하는 SQL(HiveQL) 기반 데이터 웨어하우스 서비스

: 배치 데이터 중심이지만 실시간 데이터 처리 지원

: 데이터 판매를 통한 매출을 가능케 해주는 Data Sharing, Marketplace 제공

: 웹 UI & CLI 두 가지 모두 지원

: 점점 Spark에 의해 밀리는 분위기..

: 속도 보다는 데이터 처리량(→디스크 중심)에 집중 (한 번에 처리할 수 있는 데이터 양 매우 큼)

 

- Apache Presto

: SQL 지원 & 다양한 데이터 포맷 지원 (csv, json, avro, parquet..)

: 배치 빅데이터 프로세싱 시스템

: Hive와는 달리 빠른 응답 속도(→메모리 중심)에 최적화

: 웹 UI & CLI 두 가지 모두 지원

: AWS Athena가 Presto를 기반으로 만들어짐

 

- Apache Iceberg

: 데이터 웨어하우스 기술은 아님 (데이터 파일 포맷)

: 클라우드 스토리지 위에서 모두 다 동작

: 자바, 파이썬 API 지원

: 다른 Apache 시스템과 연동 가능

: Iceberg + Spark 동시에 사용하는 경우도 있음

 

- Apache Spark

: 파이썬 pandas의 DataFrame과 흡사한 구조로 빅데이터를 처리하자!

: 빅데이터 처리 관련 다양한 기능 (DataFrame API or SQL을 써서 배치 데이터 처리 + 그래프 처리 + 실시간 처리 + 머신러닝 기능 ..)

: 분산처리 시스템 지원 (하둡, AWS EMR, 쿠버네티스): 다양한 파일 시스템과 연동 가능 (AWS S3, Cassandra, HBase, HDFS)

: 다양한 데이터 포맷 지원 (csv, json, avro, parquet..)

: 다양한 언어 지원 (자바, 파이썬, 스칼라, R)

 

5. 실리콘밸리 회사들의 데이터 스택 트랜드

- 데이터 플랫폼의 발전 단계

1. 초기: 데이터 웨어하우스 + ETL

2. 발전: 데이터의 양이 증가 → 빅데이터 처리 시스템(Spark), 데이터 레이크 도입

3. 성숙: 데이터의 활용이 증대 →  현업단의 데이터 활용이 가속화됨, ELT 단의 고도화가 필요 (dbt), MLOps 등 머신러닝 관련 효율성이 증대

 

- 2) 발전 단계

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

: 데이터 레이크 도입 (로그 데이터같은 대용량 비구조화 데이터)

: Use case

1. 데이터 소스 → 데이터 파이프라인 → 데이터 웨어하우스 (바로 적재)

2. 데이터 소스 → 데이터 파이프라인 → 데이터 레이크 (데이터 크기 큰 경우)

3. 데이터 레이크 → 데이터 파이프라인 → 데이터 웨어하우스 (여기에 Spark, Hadoop 사용)

4. 데이터 레이크 → 데이터 파이프라인 → 데이터 레이크 (정제해서 다시 저장)

5. 데이터 웨어하우스 → 데이터 파이프라인 → 데이터 웨어하우스 (역시 다시 정제해서 저장) 

 

- 3) 성숙 단계

: ELT단의 데이터 품질이 중요 & ML 모델의 사용이 가속화 됨

: dbt등의 analytics engineering이 도입됨

: MLOps 도입 (머신러닝 개발 운영 관련 효율성 증대)

 

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

클라우드: 대부분 AWS

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

대시보드: Tableau, Looker, 자체제작 ..

데이터 파이프라인 프레임워크: 대부분 Airflow (+dbt나 K8s)

 

---

 

💡Furthermore

• Day 1-2 데이터 엔지니어 스킬 로드맵 확인하기