Star Schema vs. Snowflake Schema: 각각 언제 사용해야 할까

Source: Dev.to

스타 스키마와 스노우플레이크 스키마는 모두 차원 모델입니다. 두 모델 모두 데이터를 팩트 테이블(측정 가능한 이벤트)과 차원 테이블(그 이벤트에 대한 컨텍스트)로 구성합니다. 차이점은 차원을 구성하는 방식에 있습니다.

이 구조적 차이는 쿼리 성능, 저장 효율성, SQL 복잡성, 그리고 BI 도구와 AI 에이전트가 데이터를 해석하는 용이성에 영향을 미칩니다. 선택 방법은 다음과 같습니다.

차원 모델링의 두 가지 패턴

Dimensional modeling separates data into two types:

사실 테이블

Store measurable events — a sale, a page view, a shipment, a login.
Each row represents one event. Columns include numeric measures (revenue, quantity, duration) and foreign keys pointing to dimension tables.

차원 테이블

Provide context for facts — who (customer), what (product), when (date), where (location), how (channel).
Dimensions describe the “business words” people use to filter, group, and label their analysis.

Star and snowflake schemas differ in how they organize those dimension tables.

스타 스키마: 비정규화 차원

스타 스키마에서는 각 차원이 단일 비정규화 테이블입니다. 차원의 모든 속성이 한 곳에 저장됩니다.

예시: 제품 차원은 제품 이름, 카테고리, 하위 카테고리, 부서, 브랜드를 모두 하나의 테이블에 포함합니다. 이는 일부 값이 반복된다는 것을 의미합니다. “Electronics” 카테고리의 모든 제품은 해당 행에 문자열 “Electronics”를 저장합니다.

장점

• 쿼리당 조인 수 감소 – 일반적인 스타‑스키마 쿼리는 사실 테이블을 3‑5개의 차원 테이블에 조인하고 끝납니다.
• SQL 간소화 – 분석가가 더 짧고 가독성 높은 쿼리를 작성합니다.
• 쿼리 성능 향상 – 조인 수가 적을수록 쿼리 엔진의 작업량이 감소합니다.
• BI‑도구와의 호환성 향상 – 대부분의 BI 도구는 스타 스키마를 기대하며, 이에 최적화된 SQL을 생성합니다.

트레이드‑오프

차원에서 데이터 중복이 발생합니다. “Electronics” 부서의 이름이 변경되면, 이를 참조하는 모든 행을 업데이트해야 합니다.

Snowflake 스키마: 정규화된 차원

Snowflake 스키마에서는 차원을 하위 테이블로 정규화합니다. 하나의 제품 차원 대신 Product, Category, Subcategory, Department 테이블을 별도로 두고 외래 키로 연결합니다.

장점

• 저장 중복 감소 – 각 값이 한 번만 저장됩니다. “Electronics”는 Department 테이블의 한 행에만 존재합니다.
• 속성당 단일 진실 원천 – 수천 개의 행을 수정할 필요 없이 한 행에서 부서를 이름 변경하면 됩니다.
• OLTP 정규화 관행과 일치 – 트랜잭션 데이터베이스 배경을 가진 엔지니어에게 친숙합니다.

트레이드‑오프

쿼리당 조인 수가 늘어납니다. 스타 스키마에서 4개의 테이블을 조인하던 것이 스노우플레이크 스키마에서는 8‑12개의 테이블을 조인해야 할 수 있습니다. SQL이 길어지고 복잡해져서 분석가가 도움 없이 작성하기 어려워집니다.

Side‑by‑Side Comparison

언제 어떤 것을 선택할까

스타 스키마를 선택할 경우:

• 주요 작업이 분석 및 보고인 경우.
• 비즈니스 사용자가 즉석 쿼리를 실행하거나 BI 도구를 사용하는 경우.
• 쿼리 성능이 저장 비용보다 더 중요할 때.
• AI 에이전트가 정확한 SQL을 생성하도록 하고 싶을 때(조인이 적을수록 실수가 적음).
• 차원이 충분히 작아 중복이 무시할 수준인 경우.

스노우플레이크 스키마를 선택할 경우:

• 차원이 매우 크고 중복이 실제 저장 비용을 초래하는 경우.
• 규제 요구사항이 속성당 하나의 정규화된 소스를 요구하는 경우.
• 모델에 대한 쿼리를 작성하는 사람이 ETL 엔지니어(분석가가 아님)인 경우.
• 차원 계층 간에 엄격한 참조 무결성이 필요한 경우.

스타 스키마가 보통 승리하는 이유

현대 데이터 플랫폼의 세 가지 변화가 스타 스키마 쪽으로 균형을 기울였습니다:

1. 스토리지는 저렴합니다 – 객체 스토리지는 GB당 월 몇 센트도 안 됩니다. 차원을 정규화함으로 얻는 스토리지 절감 효과는 쿼리 복잡도 비용을 정당화하기 어렵습니다.
2. 컬럼형 포맷은 중복을 잘 압축합니다 – Parquet와 ORC는 데이터를 컬럼 단위로 저장합니다. “Electronics”와 같은 반복 값은 거의 압축되지 않은 것처럼 저장됩니다. 비정규화된 차원의 물리적 스토리지 오버헤드는 행 기반 사고에서 보이는 것보다 훨씬 작습니다.
3. AI와 셀프 서비스는 단순성을 필요로 합니다 – AI 에이전트가 데이터 모델에 대해 SQL을 생성할 때, 테이블이 적고 조인이 적으면 환각 조인 경로가 발생할 가능성이 줄어듭니다. 비즈니스 분석가가 보고서를 만들 때도 조인이 적으면 잘못된 결과가 나올 확률이 낮아집니다.

Dremio와 같은 플랫폼은 이 선택을 더욱 쉽게 만듭니다. 가상 데이터셋을 사용하면 … (content continues).

스타 스키마는 데이터를 물리적으로 복사하거나 비정규화하지 않고도 SQL 뷰로 제공할 수 있습니다.
Reflections는 백그라운드에서 자동으로 쿼리 성능을 최적화합니다. 기본 데이터가 어떻게 저장되든 물리적 성능을 최적화하면서 스타 스키마의 단순성을 얻을 수 있습니다.

다음에 할 일

1. 가장 많이 사용되는 사실 테이블을 식별하세요.
2. 전체 보고서를 만들기 위해 필요한 조인 수를 계산하세요.
   • 다섯 개 이상의 차원 테이블을 조인하거나 차원 테이블 자체에 서브 조인이 필요할 경우, 차원을 스타 스키마로 평탄화하는 것을 고려하세요.
3. 쿼리 성능 차이를 측정하세요.
   • 대부분의 경우 개선 효과가 크고 저장소 증가는 무시할 수준입니다.

30일 동안 Dremio Cloud를 무료로 사용해 보세요