DW 모델링: Star와 Snowflake로 분석 계층 설계하기
DW 모델링에서 Fact와 Dimension을 설계하고 Star Schema와 Snowflake Schema를 레이어별 요구에 맞게 선택하는 방법을 다룬다.
2026-08-14 · 최초 발행 2025-10-14
분석 모델은 Fact의 Grain에서 출발한다
데이터웨어하우스 모델링은 분석 목적과 질의 패턴에 맞춰 사실(Fact)과 차원(Dimension)의 관계를 설계하는 작업이다. 비정규화와 정규화 중 하나를 일괄적으로 선택하는 문제가 아니라, 성능·일관성·운영 편의성 사이의 균형을 모델에 반영하는 일에 가깝다.
Fact는 매출액, 수량, 비용처럼 비즈니스 이벤트에서 측정되는 값의 집합을 담는 중심 테이블이다. Dimension은 고객, 상품, 날짜처럼 Fact를 해석할 분석 관점을 제공한다. Dimension의 Attribute는 필터링, 그룹핑, 정렬에 쓰이는 속성이다.
여기서 먼저 정해야 할 것은 Grain이다. Grain은 Fact 테이블이 표현하는 사건의 단위이며, 키와 측정값 설계 전체의 기준이 된다. Grain이 불명확하면 중복이나 누락이 생기기 쉽고, 측정값의 가산성(Additivity)도 판단하기 어려워진다.
여러 Fact 또는 데이터 마트에서 같은 기준으로 재사용하는 차원은 Conformed Dimension으로 관리한다. 차원 변경 이력은 SCD(Slowly Changing Dimension) 방식으로 다루며, Type 1/2/3 등을 선택할 수 있다. 비즈니스 키와 분리된 내부 식별자인 Surrogate Key는 이력, 일관성, 성능을 위한 기반이 된다.
데이터 흐름은 일반적으로 Staging, DW Core(Conformed), Data Mart, Semantic Layer로 나뉜다. Staging은 원천 데이터를 보존하고 전처리하는 곳이고, DW Core는 공통 차원과 참조 무결성을 관리한다. Data Mart와 Semantic Layer는 주제영역별 분석과 셀프서비스 사용을 위해 집계와 파생 지표를 제공한다.
조회 경로가 짧은 Star Schema
Star Schema는 Fact와 Dimension을 한 계층으로 분리하는 비정규화 중심 모델이다. 조인 수를 줄일 수 있어 실행 계획이 단순해지고 BI·OLAP 질의에 잘 맞는다. 모델을 이해하기도 비교적 쉽다.
반면 차원 속성이 중복될 수 있어 데이터 일관성을 관리해야 하며, 차원 변경이 넓게 퍼질 위험이 있다.
차원을 분리하는 Snowflake Schema
Snowflake Schema는 차원을 하위 차원으로 나누어 정규화하는 방식이다. 중복을 줄이고 데이터 일관성과 변경 관리를 강화할 수 있으며, 차원 재사용성도 높아진다.
대신 조인이 늘어나면 쿼리 비용이 커질 수 있다. 사용자 입장에서는 모델이 복잡해지고, 운영 과정에서 문서화와 교육 부담도 커진다.
| 관점 | Star Schema | Snowflake Schema |
|---|---|---|
| 성능 | 조인 수가 적어 스캔을 줄이기 유리 | 조인이 많아지면 비용이 증가할 수 있음 |
| 확장성 | 요약 테이블·파티션을 통한 수평 확장이 쉬움 | 구조 확장은 유연하지만 조인 비용 관리가 필요 |
| 일관성 | 중복 갱신 리스크가 존재 | 정규화로 일관성을 확보하기 유리 |
| 안정성 | 단순한 구조로 장애 영향 범위를 제한 | 스키마 변경의 전파 영향이 클 수 있음 |
| 운영 편의 | 모델이 단순하고 사용자 친화적 | 모델이 복잡해 문서화·교육이 필요 |
조회 성능과 단순성이 우선인 마트나 서빙 레이어는 Star Schema를 중심으로 둘 수 있다. 엔터프라이즈 공통 차원 관리가 중요한 코어 레이어에서는 Snowflake Schema를 혼합하는 하이브리드 구성이 적합하다.
적재 과정에서 차원과 사실을 맞추는 방법
원천 데이터의 스키마 버전, 변경 데이터 캡처(CDC), 추출 윈도우를 먼저 정의한다. Staging에서는 원형을 보존하면서 타입을 정규화하고 기본 품질 점검을 수행한다. 이후 차원을 빌드하고, Fact 적재와 마트 생성을 이어간다.
차원 빌드에서는 SCD1/2 머지, Surrogate Key 매핑, 서브디멘전 분리 여부를 결정한다. Fact를 적재할 때는 Late-arriving Fact를 처리하고, 누락된 차원은 보강 레코드 또는 지연 큐 전략으로 다룬다.
출력은 코어 차원과 Fact, 데이터 마트와 시맨틱 계층으로 구성된다. 집계 테이블과 인덱싱 전략도 이 단계에 포함된다. 차원 Merge에서는 파티션 또는 키 범위 잠금을 최소화하고, 멱등성(Upsert)과 배치 재실행 가능성을 보장해야 한다. 트랜잭션 경계는 파티션 단위로 설정한다.
분석 목적에 따라 달라지는 Fact와 Dimension
리테일 매출 분석에서는 Fact_Sales와 Dim_Date, Dim_Store, Dim_Product, Dim_Promotion을 구성해 프로모션 효과, 지역별 매출, 장바구니 분석을 수행할 수 있다.
구독·결제 코호트 분석에는 Fact_Billing, Fact_Usage와 Dim_Customer, Dim_Plan, Dim_Date가 쓰인다. 유지율, 업그레이드 전환, LTV 계산을 위한 모델이 된다.
제조 품질과 공정 모니터링은 Fact_Production, Fact_Defect와 Dim_Machine, Dim_Shift, Dim_Material을 기반으로 결함 원인과 공정별 불량률을 분석한다. 마케팅 퍼널과 어트리뷰션에서는 Fact_Events, Fact_Impressions, Fact_Clicks, Dim_Channel, Dim_Campaign을 사용해 멀티터치 어트리뷰션과 ROAS 최적화를 지원한다.
성능 최적화와 운영 통제의 균형
Star Join 최적화, Columnar Storage, Z-Order 또는 클러스터링, 통계 수집은 스캔과 조인 비용을 줄이는 데 사용된다. 요약 테이블과 물질화 뷰도 활용할 수 있으며, 조인 수·스캔 범위·데이터 재사용률을 기준으로 비용을 모델링해야 한다.
Star 최적화와 요약 테이블을 도입하면 대용량 필터·집계 쿼리의 평균 응답시간이 30~70% 단축된 사례가 다수 있다. 파티셔닝과 프루닝은 스캔 바이트를 50% 이상 절감할 수 있고, 물질화 뷰와 컬럼너 스토리지는 BI 대시보드 초기 로딩 시간을 40% 내외 줄일 수 있다.
요약 테이블과 캐시는 비용을 높일 수 있으므로 액세스 패턴을 보고 핫쿼리에만 선별 적용한다. 파티셔닝 키는 프루닝 효과와 스큐 위험을 함께 고려해 선택한다.
민감정보는 적재 전에 비식별화하거나 토큰화하고, 시맨틱 계층에서는 행·열 수준 접근제어를 적용한다. 감사 로그와 계보 관리는 접근 추적을 강화하지만 비용과 복잡도를 높이는 트레이드오프가 있다.
스키마 진화는 버전드 컨트랙트와 마이그레이션 플레이북으로 관리한다. 다운타임을 줄이는 대신 일시적인 이중 쓰기 부담이 생길 수 있다. SCD Type 2 역시 저장량과 조인 비용을 늘리지만 시점 재현성을 제공하므로, Type 1과 Type 2를 혼합하는 전략을 적용할 수 있다.