02. Data Warehouse와 Data Mart 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• Data Warehouse와 Data Mart는 어떤 책임을 나누는가?
• mart를 API 편의 table이나 임시 report table과 구분하는 기준은 무엇인가?
• 백엔드 서비스가 warehouse 적재를 위해 제공해야 할 계약은 무엇인가?
• mart build 실패와 warehouse 적재 지연은 어떻게 추적하고 재처리하는가?

개요

Data Warehouse는 여러 원천 데이터를 모아 분석 가능한 공통 기반으로 정리한 저장소다.

Data Mart는 특정 팀, 제품, 지표가 반복해서 조회하는 형태로 재구성한 데이터 모델이다.

warehouse가 공용 기반이라면 mart는 소비 목적에 맞춘 얇은 제품에 가깝다.

둘을 구분하지 않으면 모든 report 요구가 운영 DB나 임시 SQL로 흩어진다.

원리

warehouse와 mart는 단순히 큰 DB와 작은 DB의 차이가 아니다.

warehouse는 원천의 의미, 이력, 표준화된 dimension, 재처리 가능한 staging을 중요하게 본다.

mart는 조회 성능, 지표 정의, 소비자별 grain, 공개 SLA를 중요하게 본다.

백엔드 개발자는 warehouse를 직접 운영하지 않더라도 원천 데이터의 의미를 제공해야 한다.

흐름

order-service DB
payment-service DB
refund-service DB
  -> ingestion / CDC / batch extract
  -> raw zone
  -> staging zone
  -> warehouse fact/dimension
  -> mart_sales_daily
  -> dashboard / analyst query / product report

raw와 staging은 원천을 보존하고 정리하는 공간이다.

warehouse fact와 dimension은 여러 분석에서 함께 쓰는 기반이다.

mart는 특정 질문에 빠르게 답하기 위해 만들어진 결과다.

Warehouse와 Mart 비교

구분	Warehouse	Mart
목적	공통 분석 기반	특정 소비 목적
예시	fact_order_payment, dim_product	mart_sales_daily
소유	데이터 플랫폼, 분석 플랫폼	지표 owner, 제품/분석 팀
변경 영향	여러 mart와 분석에 영향	특정 dashboard나 기능에 영향
검증	원천 대비 completeness	지표 정의와 freshness
재처리	source partition부터	mart partition부터

이 구분은 장애 때 중요하다.

warehouse 적재가 늦으면 여러 mart가 영향을 받을 수 있고, mart build만 실패하면 특정 dashboard만 stale일 수 있다.

스키마 예시

CREATE TABLE fact_order_payment (
    payment_id bigint NOT NULL,
    order_id bigint NOT NULL,
    member_id bigint NOT NULL,
    product_id bigint NOT NULL,
    paid_amount numeric(14, 2) NOT NULL,
    paid_at timestamp NOT NULL,
    source_event_id varchar(36) NOT NULL,
    loaded_at timestamp NOT NULL,
    PRIMARY KEY (payment_id)
);
 
CREATE TABLE mart_sales_daily (
    order_date date NOT NULL,
    product_category varchar(50) NOT NULL,
    paid_amount numeric(16, 2) NOT NULL,
    order_count bigint NOT NULL,
    refreshed_at timestamp NOT NULL,
    PRIMARY KEY (order_date, product_category)
);

fact table은 사건의 grain을 보존한다.

mart table은 특정 질문에 맞춰 미리 집계한다.

백엔드가 제공해야 할 계약

warehouse 적재 품질은 데이터 플랫폼만의 문제가 아니다.

백엔드 서비스는 원천 데이터 의미를 제공해야 한다.

• business key와 surrogate key의 차이
• status 값의 전이 의미
• 삭제, 취소, 환불의 표현 방식
• event 발생 시각과 DB commit 시각
• 테스트 데이터 제외 기준
• schema 변경 예정과 호환 기간

이 정보가 없으면 warehouse는 데이터를 복사할 수는 있어도 정확한 지표를 만들기 어렵다.

판단 축

• 여러 지표가 공통으로 쓰는 기반이면 warehouse 모델로 둔다.
• 특정 화면이나 팀이 반복 조회하는 결과면 mart로 둔다.
• mart가 원천 보정 logic을 직접 많이 가지면 warehouse 모델이 부족한 신호다.
• warehouse table 변경은 downstream mart 목록과 함께 리뷰한다.
• mart freshness는 소비자에게 공개되는 SLA로 관리한다.

실패 모델

• mart SQL이 운영 DB를 직접 읽어 warehouse를 우회한다.
• warehouse fact의 grain이 불명확해 같은 주문이 여러 번 집계된다.
• mart에 business rule이 복사되어 dashboard마다 지표 정의가 달라진다.
• warehouse 적재는 성공했지만 mart build가 실패해 dashboard가 stale이다.
• 백엔드 schema 변경이 warehouse ingestion을 깨뜨렸지만 사전 공지가 없다.

재처리 기준

warehouse 재처리는 보통 source partition, event offset, updated_at range에서 시작한다.

mart 재처리는 warehouse partition이나 mart target date에서 시작한다.

rerun target: mart_sales_daily
range: 2026-06-01..2026-06-30
source: fact_order_payment
mode: overwrite partition
validation: count, paid_amount sum, freshness

재처리 범위가 mart에만 머무를지 warehouse부터 다시 갈지는 오류 위치에 따라 다르다.

운영 지표

• raw_ingestion_lag: 원천에서 raw zone까지의 지연이다.
• warehouse_load_failed_count: 공통 기반 적재 실패 수다.
• mart_build_duration: 특정 mart 생성 시간이다.
• mart_freshness_lag: 소비자에게 보이는 최신성이다.
• downstream_mart_count: warehouse 변경 영향 범위다.
• metric_rule_change_count: mart 지표 정의 변경 빈도다.

개인 프로젝트 기준

개인 프로젝트에서는 warehouse와 mart를 같은 DB schema 안에서 나눠도 된다.

예를 들어 dw_fact_order_payment와 mart_sales_daily처럼 prefix만 나눠도 학습 효과가 있다.

중요한 것은 공통 기반과 소비자용 집계를 섞지 않는 것이다.

기업 운영 기준

기업에서는 warehouse와 mart의 owner, 배포 주기, 품질 gate가 분리된다.

warehouse 변경은 여러 팀에 영향을 주므로 schema evolution과 downstream 영향 분석이 필요하다.

mart 변경은 지표 정의 변경이므로 소비자 공지와 과거 데이터 재계산 여부를 함께 결정해야 한다.

실전 팁

• mart를 만들기 전에 어떤 warehouse fact와 dimension을 기준으로 삼을지 정한다.
• mart SQL 안에 복잡한 원천 보정 logic이 반복되면 warehouse 모델을 보강한다.
• mart table에는 refreshed_at과 build id를 남긴다.
• warehouse schema 변경은 consumer 목록과 함께 리뷰한다.
• dashboard stale 여부를 사용자가 볼 수 있게 표시한다.

위험 신호!

• 모든 분석 요구가 SELECT ... FROM orders로 시작한다.
• mart가 여러 원천 table을 매번 직접 join한다.
• warehouse fact의 grain을 설명하지 못한다.
• mart build 실패를 dashboard 사용자가 먼저 발견한다.
• schema 변경 후 데이터 팀이 어떤 column 의미가 바뀌었는지 알지 못한다.

확인 질문

확인 질문

• warehouse와 mart를 나누는 핵심 기준은 무엇인가?
  • warehouse는 공통 분석 기반이고, mart는 특정 소비 목적에 맞춘 지표 모델이다.
• mart build 실패와 warehouse 적재 실패는 영향 범위가 어떻게 다른가?
  • warehouse 적재 실패는 여러 mart에 퍼질 수 있고, mart build 실패는 특정 소비자나 dashboard에 국한될 수 있다.
• 백엔드 팀이 warehouse 품질을 위해 제공해야 할 정보는 무엇인가?
  • key, status 의미, 삭제/취소 표현, event 시각, 테스트 데이터 기준, schema 변경 계획이다.

참고 문서

• AWS Analytics Guidance
• Kimball Group, Dimensional Modeling Techniques
• dbt Documentation
• Martin Kleppmann, Designing Data-Intensive Applications