[Daily morning study] OLTP vs OLAP와 데이터 웨어하우스 개념
#daily morning study
OLTP와 OLAP의 차이
데이터베이스 시스템은 사용 목적에 따라 크게 OLTP와 OLAP 두 가지로 나뉜다.
OLTP (Online Transaction Processing)
실시간 트랜잭션 처리에 최적화된 시스템이다. 쇼핑몰에서 주문을 처리하거나, 은행에서 계좌 이체를 실행하거나, 사용자 정보를 업데이트하는 것처럼 짧고 빈번한 읽기/쓰기 작업이 주를 이룬다.
주요 특성:
- 트랜잭션 단위로 데이터 처리 (INSERT, UPDATE, DELETE)
- 응답 속도가 매우 빠름 (밀리초 단위)
- 동시에 많은 사용자가 접근
- 정규화된 테이블 구조로 데이터 중복 최소화
- 최신 데이터 상태가 중요
대표 DB: MySQL, PostgreSQL, Oracle, SQL Server
OLAP (Online Analytical Processing)
대용량 데이터를 분석하고 집계하는 데 특화된 시스템이다. “지난 3년간 월별 매출 추이를 구해라”, “지역별 상위 10개 상품은?” 같은 복잡한 분석 쿼리를 다룬다.
주요 특성:
- 읽기 위주의 복잡한 집계 쿼리 (GROUP BY, JOIN, 윈도우 함수 등)
- 수백만~수십억 건의 데이터를 한 번에 처리
- 비정규화된 구조로 쿼리 성능 최적화 (중복 허용)
- 배치 방식으로 데이터 적재 (실시간 업데이트 드묾)
- 히스토리 데이터가 중요
대표 솔루션: Amazon Redshift, Google BigQuery, Snowflake, ClickHouse
비교 정리
| 항목 | OLTP | OLAP |
|---|---|---|
| 목적 | 트랜잭션 처리 | 데이터 분석 |
| 작업 유형 | CRUD (짧은 쿼리) | 복잡한 집계 쿼리 |
| 데이터 양 | 적음 (수천~수백만 건) | 많음 (수억~수십억 건) |
| 응답 시간 | 밀리초 | 초~분 |
| 정규화 | 높은 정규화 | 비정규화 (스타/스노우플레이크 스키마) |
| 동시 사용자 | 수천 명 | 소수 (분석가, BI 도구) |
| 업데이트 빈도 | 실시간 | 배치(일/시간 단위) |
데이터 웨어하우스
데이터 웨어하우스(Data Warehouse, DW)는 여러 OLTP 시스템과 외부 소스에서 데이터를 수집·통합·저장하여 분석(OLAP) 목적으로 사용하는 중앙 저장소다.
왜 필요한가
운영 DB(OLTP)에서 직접 분석 쿼리를 실행하면 문제가 생긴다.
- 무거운 집계 쿼리가 서비스 트랜잭션을 방해 (성능 저하)
- 여러 시스템(CRM, ERP, 로그 등)에 흩어진 데이터를 합칠 방법 없음
- 히스토리 보존이 어려움 (OLTP는 최신 상태만 유지하는 경우 많음)
데이터 웨어하우스는 이 문제를 분리 원칙으로 해결한다. 운영 DB는 서비스에, 웨어하우스는 분석에 집중시킨다.
ETL 파이프라인
데이터 웨어하우스를 채우는 과정은 ETL(Extract-Transform-Load) 또는 ELT 방식으로 이루어진다.
[운영 DB / 외부 API / 로그 파일]
↓ Extract (추출)
[Staging Area / Raw 데이터]
↓ Transform (변환·정제)
[데이터 웨어하우스]
↓
[BI 도구 / 분석 쿼리 / 리포트]
- Extract: 소스 시스템에서 데이터를 주기적으로 추출 (변경분만 추출하는 CDC 방식도 있음)
- Transform: 데이터 정제, 타입 변환, 비즈니스 룰 적용, 키 매핑 등
- Load: 변환된 데이터를 웨어하우스에 적재
ELT는 변환을 나중에 웨어하우스 안에서 처리하는 방식이다. BigQuery, Snowflake처럼 컴퓨팅 파워가 강력한 클라우드 DW에서 선호한다.
데이터 웨어하우스 스키마 설계
스타 스키마 (Star Schema)
가장 많이 쓰이는 구조다. 중심에 팩트 테이블(Fact Table) 이 있고, 그 주변에 차원 테이블(Dimension Table) 이 별처럼 배치된다.
[날짜 차원]
|
[상품 차원] -- [매출 팩트] -- [지역 차원]
|
[고객 차원]
- 팩트 테이블: 측정값(매출액, 수량, 클릭 수 등)과 외래 키만 담음. 행이 매우 많음.
- 차원 테이블: 분석 기준이 되는 속성 정보 (날짜, 고객, 상품, 지역 등)
장점: 쿼리가 단순하고 빠름. 이해하기 쉬움.
단점: 차원 테이블에 중복 데이터가 있을 수 있음.
스노우플레이크 스키마 (Snowflake Schema)
스타 스키마에서 차원 테이블을 더 정규화한 형태다. 예를 들어 상품 차원을 상품 → 서브카테고리 → 카테고리로 분리한다.
장점: 저장 공간 절약, 데이터 일관성 향상.
단점: 조인이 많아져 쿼리가 복잡해지고 느려질 수 있음.
실무에서는 보통 스타 스키마를 기본으로 선택하고, 필요한 경우에만 일부 정규화한다.
데이터 마트 (Data Mart)
데이터 웨어하우스의 하위 개념이다. 전체 웨어하우스에서 특정 부서나 주제에 맞는 데이터만 뽑아 만든 소규모 데이터 저장소다.
예: 마케팅팀 데이터 마트, 재무팀 데이터 마트
데이터 마트 구성 방법은 두 가지다.
- 종속형: 중앙 웨어하우스에서 파생 (Top-down)
- 독립형: 소스 시스템에서 직접 구성 (Bottom-up)
대기업에서는 종속형이 일반적이다. 웨어하우스를 신뢰할 수 있는 단일 진실 공급원(Single Source of Truth)으로 유지하면서, 마트를 통해 각 팀의 접근성을 높인다.
현대적인 데이터 아키텍처
데이터 레이크 (Data Lake)
정형·비정형 데이터(로그, 이미지, JSON, CSV 등)를 원본 그대로 대규모로 저장하는 시스템이다. 데이터 웨어하우스와 달리 스키마를 미리 정하지 않는다(Schema-on-Read).
AWS S3, Azure Data Lake Storage, GCS 등이 저장소로 활용된다.
레이크하우스 (Lakehouse)
데이터 레이크의 유연성과 웨어하우스의 성능·거버넌스를 결합한 아키텍처다. Delta Lake, Apache Iceberg, Apache Hudi 같은 오픈 테이블 포맷이 핵심 기술이다.
[소스 시스템]
↓
[데이터 레이크 (원시 데이터 저장)]
↓
[Delta Lake / Iceberg (트랜잭션 지원, 스키마 강제)]
↓
[BI 분석 / ML 모델 / 실시간 쿼리]
Databricks, Snowflake, Google BigLake가 이 방향으로 수렴하고 있다.
핵심 정리
- OLTP: 서비스 운영을 위한 빠른 트랜잭션 처리. 정규화, 짧은 쿼리, 실시간.
- OLAP: 비즈니스 인사이트를 위한 대용량 분석. 비정규화, 복잡한 집계, 배치.
- 데이터 웨어하우스: OLTP → ETL → DW로 데이터를 통합해 분석 전용 플랫폼 구성.
- 스타 스키마: 팩트 테이블 + 차원 테이블로 분석 쿼리 성능 최적화.
- 데이터 레이크/레이크하우스: 정형·비정형 데이터를 원본 저장 후 필요에 따라 처리.
OLTP와 OLAP을 분리하는 이유는 결국 관심사 분리(Separation of Concerns) 다. 서비스 안정성과 분석 성능 모두를 잡으려면, 두 역할을 전용 시스템에서 각자 최적화해야 한다.
