OLTP OLAP Data Warehouse Data Mart

OLTP OLAP Data Warehouse Data Mart 챕터는 운영 DB와 분석 저장소의 목적을 분리하고, 분석 가능한 fact와 dimension 모델로 데이터를 재구성한다.
목표는 운영 DB를 분석 쿼리로 압박하지 않고, 지연을 허용하는 데이터는 warehouse와 mart에서 재계산 가능하게 만드는 것이다.
Java/Spring 백엔드 개발자는 주문 API의 transaction row가 어떤 event와 fact, dimension, mart로 바뀌는지 설명할 수 있어야 한다.

OLTP와 OLAP 차이: OLTP는 사용자 요청의 현재 상태를 안전하게 바꾸는 시스템이고, OLAP은 많은 데이터를 읽어 패턴과 지표를 계산하는 시스템이다.
Data Warehouse와 Data Mart: warehouse는 여러 원천을 통합한 분석 기반이고, mart는 특정 팀이나 기능이 반복 조회하는 지표 모델이다.
Fact Dimension 기본: fact는 측정 가능한 사건이고 dimension은 사건을 해석할 기준이다. 주문 금액은 fact, 회원 등급과 상품 카테고리는 dimension이다.
운영 DB와 분석 DB 분리 기준: 운영 DB를 분석 쿼리로 압박하기 시작하면 읽기 부하, lock, replica lag, 지표 정의가 서비스 운영과 얽힌다.
백엔드 개발자가 알아야 할 분석 요구사항: 분석 요구사항은 단순 컬럼 추가가 아니라 이벤트 의미, 집계 기준, 지연 허용치, 재처리 범위를 포함한다.
이 챕터의 모든 문서는 Web-Database의 OLTP 판단을 넘어, 데이터 이동과 재처리 가능성을 중심으로 읽어야 한다.

운영 DB replica를 붙이면 OLAP 문제가 끝난다고 보기 쉽다.
- replica는 부하를 줄일 수 있지만 지표 정의, freshness, 재처리 문제를 해결하지는 않는다.
- 분석 요구가 반복되면 fact, dimension, mart 기준으로 모델을 분리해야 한다.
fact와 mart를 같은 것으로 보기 쉽다.
- fact는 사건 grain을 보존하는 기반이고, mart는 특정 소비 목적에 맞춘 집계 결과다.
- mart 오류를 고칠 때 fact부터 다시 만들지 mart만 다시 만들지 구분해야 한다.
현재 dimension만 저장해도 충분하다고 오해하기 쉽다.
- 과거 리포트가 주문 당시 상품 카테고리나 회원 등급을 써야 한다면 dimension 이력이 필요하다.
- 이 기준이 없으면 시간이 지날수록 같은 기간 리포트 수치가 바뀐다.

이 챕터의 핵심 판단 기준은 무엇인가?
- 운영 transaction과 분석 workload를 분리하고, fact grain과 dimension 이력, mart freshness를 명확히 하는 것이다.
Web-Database와의 경계는 무엇인가?
- Web-Database는 운영 DB query와 transaction 성능 중심이고, 이 챕터는 운영 데이터가 분석 모델로 이동해 재계산되는 흐름 중심이다.
개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- 운영 table과 summary table을 분리하고, summary 갱신 시각, 재실행 범위, count/sum 검증 SQL을 남기는 것이다.

동블