데이터 웨어하우스는 조직 내 여러 데이터 소스를 하나로 모아 분석과 의사결정 지원에 최적화된 데이터 저장소를 말한다. 일반적인 운영 DB는 주문, 회원가입, 결제 등 트랜잭션을 빠르게 처리하는 것이 목적이지만 데이터 웨어하우스는 과거부터 현재까지의 데이터를 통합해 패턴 분석, 집계, 리포팅을 수행하는데 초점을 둔다. 미국의 데이터베이스 전문가 Bill Inmon은 데이터 웨어하우스를 다음과 같이 정의했다.
“주제 지향적(Subject-Oriented), 통합적(Integrated), 비휘발성(Non-Volatile), 시계열(Time-Variant) 데이터 저장소”
이 말은 곧 데이터 웨어하우스의 핵심 특징을 설명한다.
- 주제 지향 – 부서나 시스템 단위가 아니라 고객·상품·매출 같은 분석 주제별로 데이터를 구성한다.
- 통합 – 서로 다른 DB와 포맷, 코드 체계를 통일해 하나의 표준화된 데이터로 저장한다.
- 비휘발성 – 한 번 DW에 적재된 데이터는 거의 수정·삭제하지 않고 새로운 데이터만 추가된다.
- 시계열 – 현재 상태뿐만 아니라 과거 데이터까지 보존하여 시간에 따른 추세 분석이 가능하다.
결국 DW는 단순 데이터 저장소가 아니라, “조직의 데이터 히스토리를 담은 분석 전용 창고”라고 볼 수 있다.
데이터 웨어하우스 vs 일반 데이터베이스
운영 DB와 DW는 목적과 설계 철학이 완전히 다르다.
| 구분 | 운영 DB(OLTP) | 데이터웨어하우스(OLAP) |
|---|---|---|
| 목적 | 트랜잭션 처리(실시간 서비스) | 데이터 분석, 리포팅 |
| 데이터 갱신 | CRUD(Insert/Update/Delete) | Append-Only(거의 Insert) |
| 스키마 설계 | 정규화(3NF 중심) | 반정규화, 스타/스노우플레이크 |
| 질의 유형 | 단일 행 조회, 빠른 응답 | 대량 집계, 복잡한 조인 |
| 데이터 시점 | 현재 상태 중심 | 과거부터 현재까지 시계열 |
| 예시 | 쇼핑몰 주문 DB | 매출/상품 분석용 DW |
데이터웨어하우스 기본 아키텍처
데이터웨어하우스는 단일 데이터베이스를 의미하지 않는다. 실제 환경에서는 데이터 수집 → 정제 → 적재 → 분석/시각화까지의 전체 흐름을 포함한다. 아키텍처는 보통 다음 단계로 구성된다.
-
데이터 소스 (Data Sources)
운영 DB, 로그 서버, 외부 API 등 다양한 형태로 존재한다. -
ETL / ELT
데이터를 추출(Extract), 변환(Transform), 적재(Load)하는 과정이다.- ETL: 변환 후 DW에 적재 (전통적 방식)
- ELT: 먼저 DW에 적재 후 변환 (대용량·클라우드 환경에서 유리)
-
Staging Area
원본 데이터를 임시로 저장하여 정제 전후를 관리하는 공간이다. -
Data Warehouse
통합·정제된 데이터를 저장하는 중앙 분석용 DB이다. -
Data Mart
부서나 팀별 목적에 맞춘 소규모 DW로 특정 분석 목적에 최적화되어 있다. -
BI / Analytics
Tableau, Power BI, Superset 등을 통해 시각화·리포팅을 수행한다.
이 구조를 통해 운영 DB에 부하를 주지 않고도 장기 데이터 보존과 고급 분석을 수행할 수 있다.
데이터 마트(Data Mart)란?
데이터 마트는 데이터웨어하우스의 부분 집합으로 특정 부서·팀·업무 목적에 맞춘 분석 전용 데이터 저장소다. 예를 들어, 마케팅팀은 고객 행동 데이터와 구매 패턴에 집중한 마트를 활용해 캠페인 효과를 분석할 수 있고 재무팀은 매출·비용 데이터를 중심으로 손익 보고서를 만들 수 있다. 물류팀은 배송 상태, 재고, 리드타임 같은 데이터로 마트를 구성해 운영 효율을 높일 수 있다. 이처럼 데이터 마트는 부서별 요구에 신속하게 대응할 수 있는 장점이 있지만 마트가 여러 개로 분산되면 데이터 일관성을 유지하기 어렵다는 단점도 있다. 실무에서는 Kimball 방식처럼 부서별 마트를 먼저 구축하고 필요 시 이를 통합해 DW를 완성하는 접근이 자주 사용된다.
DW 설계 접근 방식
데이터웨어하우스를 설계할 때는 크게 두 가지 방법론이 있다.
1. 인몬(Inmon) 방식은 Top-Down 접근이다.
먼저 엔터프라이즈 전역 DW를 설계하고 이후 필요에 따라 Data Mart를 파생시킨다. 이 방식은 데이터 일관성을 보장하지만 초기 구축 기간이 길고 유연성이 낮다.
2. 킴볼(Kimball) 방식은 Bottom-Up 접근이다.
부서나 주제별 Data Mart를 먼저 구축하고 이를 통합하여 DW를 완성한다. 애자일한 접근이 가능하고 빠른 가치를 제공하지만 나중에 전체 통합이 어려울 수 있다.
DW 스키마 설계
데이터 웨어하우스에서는 정규화보다 분석 효율성과 집계 성능이 더 중요하다. 따라서 OLTP DB처럼 조인을 최소화하고 쿼리 속도를 높이기 위해 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)를 활용한다.
스타 스키마는 중심에 팩트 테이블(Fact Table)이 있고, 주변에는 차원 테이블(Dimension Table)이 별처럼 배치된다. 예를 들어 sales_fact에는 판매 기록이 저장되고 이를 둘러싼 date_dim, product_dim, customer_dim 같은 차원 테이블이 존재한다. 이 구조는 단순하고 직관적이며 대량 집계와 OLAP 쿼리에 최적화되어 있다.
반면 스노우플레이크 스키마는 차원 테이블을 정규화해 저장 공간을 절약한다. 예를 들어 제품 차원을 product_dim과 category_dim으로 나누어 설계하는 방식이다. 하지만 조인이 늘어나기 때문에 쿼리 성능이 다소 떨어질 수 있다. 따라서 데이터 규모와 분석 요구에 따라 스키마 설계 전략을 선택한다.
📝 배운점
데이터 웨어하우스는 단순한 데이터 저장소가 아니라 조직의 데이터 히스토리를 분석 가능한 형태로 보존하는 전략적 시스템임을 알게 되었다. 운영 DB와 달리 시계열 분석, 집계, 패턴 탐색에 최적화되어 있어 비즈니스 인사이트를 제공한다. 데이터 마트는 부서별 요구를 빠르게 충족시키는 장점이 있으나 전체 DW와의 연계 전략을 고려해야 한다. 또한 스키마 설계에서 스타 스키마와 스노우플레이크 스키마의 차이를 이해하면 쿼리 성능과 저장 효율을 균형 있게 맞출 수 있다. 결국 DW 구축은 데이터 통합, 정제, 시계열 관리, 분석 최적화를 모두 고려한 설계가 핵심이라는 점을 배웠다.
참고
