개요
데이터 웨어하우스를 설계할 때 가장 중요한 원칙 중 하나는 단순하고 효율적인 데이터 모델링입니다. 하지만 종종 설계 과정에서 너무 많은 차원(Dimension)을 포함하는 비효율적인 팩트 테이블, 즉 센티피드 팩트 테이블(Centipede Fact Table)이 생성되기도 합니다.
센티피드 팩트 테이블은 불필요하게 많은 차원을 포함하는 팩트 테이블을 의미하며, 이는 데이터 모델을 복잡하게 만들고 쿼리 성능을 저하시킬 수 있습니다. 하지만 컬럼 기반 데이터베이스와 같은 특정 환경에서는 예외적으로 허용될 수도 있습니다.
이번 글에서는 센티피드 팩트 테이블이 무엇인지, 데이터 웨어하우스에서 피해야 하는 이유, 그리고 컬럼형 데이터베이스에서 예외적으로 사용할 수 있는 경우를 살펴보겠습니다.
본론
1. 센티피드 팩트 테이블이란?
센티피드 팩트 테이블은 팩트 테이블에 필요 이상으로 많은 차원을 포함하는 비효율적인 설계 방식을 의미합니다.
센티피드 팩트 테이블의 특징
- 과도하게 세분화된 차원: 제품 브랜드, 카테고리, 부서(Department) 등을 개별 차원으로 분리
- 불필요한 날짜 차원: 주(Week), 월(Month), 분기(Quarter), 연도(Year)를 별도 차원으로 추가
- 팩트 테이블의 크기 증가: 과도한 차원으로 인해 테이블의 행(Row) 수가 급격히 늘어남
잘못된 예제 (센티피드 팩트 테이블)
| Product Key (FK) | Brand Key (FK) | Category Key (FK) | Department Key (FK) | Date Key (FK) | Week Key (FK) | Month Key (FK) | Quarter Key (FK) | Year Key (FK) |
| PROD1001 | BRAND001 | CAT001 | DEPT001 | 20240215 | WK07 | FEB | Q1 | 2024 |
✔ 과도한 차원 분리로 인해 쿼리 복잡도가 증가하고, 테이블의 크기가 비효율적으로 커짐
2. 센티피드 팩트 테이블을 피해야 하는 이유
① 차원의 과도한 분리로 인한 문제
- 불필요한 차원 분리는 팩트 테이블을 지나치게 넓게(Wide Table) 만들어 성능을 저하시킴
- 예를 들어, 제품 차원(Product Dimension)에 브랜드, 카테고리, 부서(Department) 등의 속성을 개별 차원으로 분리하면,
→ 기본적인 제품 키(Product Key) 하나만으로 해결할 수 있는 관계가 불필요하게 복잡해짐
② 쿼리 성능 저하
- 너무 많은 조인(Join)이 필요하여 쿼리 실행 시간이 증가
- 테이블이 비정상적으로 넓어지면서 인덱싱 최적화가 어려워짐
- 팩트 테이블이 커질수록 디스크 사용량 증가 및 쿼리 성능 저하
③ 사용자 경험(UX) 및 가독성 저하
- 너무 많은 차원이 존재하면 사용자가 데이터 모델을 이해하기 어려움
- 차원 간 상관관계를 고려하지 않고 개별적으로 분리하면 데이터 탐색(Browsing)이 불편해짐
- 예를 들어, 제품 차원의 브랜드와 카테고리를 개별 차원으로 분리하면,
→ "브랜드별 제품"을 쉽게 조회할 수 없게 됨
➡ 대안: 차원 간 상관관계가 높다면, 하나의 차원 테이블로 통합하는 것이 바람직함.
3. 센티피드 팩트 테이블을 피하는 방법
① 관련 차원 결합
- 차원 간 상관관계가 높다면, 하나의 차원 테이블로 결합하는 것이 좋음
- 예를 들어, 제품 차원(Product Dimension)에 브랜드, 카테고리, 부서 속성을 포함
✅ 올바른 차원 모델 예제
| Product Key (PK) | Product Name | Brand | Category | Department |
| PROD1001 | 상품 A | 브랜드X | 전자제품 | 가전 |
✔ 제품 차원 테이블에서 필요한 속성을 한 번에 조회할 수 있음
② 비정형 분석을 위한 별도 팩트 테이블 설계
- 분석 목적이 다른 데이터를 하나의 팩트 테이블에 포함하는 것은 지양
- 필요한 데이터만 포함된 전용 팩트 테이블을 분리하여 성능을 최적화
✅ 팩트 테이블 분리 예제
| POS 판매 데이터 (Retail Sales Fact) | 프로모션 효과 분석 데이터 (Promotion Fact) |
| Transaction ID (PK) | Promotion Event ID (PK) |
| Product Key (FK) | Product Key (FK) |
| Store Key (FK) | Store Key (FK) |
| Date Key (FK) | Date Key (FK) |
| Sales Amount | Promotion Type |
| Quantity Sold | Promotion Effectiveness |
✔ 목적에 맞는 팩트 테이블을 분리하여 분석 성능을 최적화
4. 컬럼형 데이터베이스에서 예외적으로 사용할 수 있는 경우
전통적인 관계형 데이터베이스에서는 센티피드 팩트 테이블을 피하는 것이 일반적이지만, 컬럼형 데이터베이스(Columnar Database)에서는 예외적으로 사용할 수 있습니다.
① 컬럼 기반 저장 구조
- 컬럼형 데이터베이스는 행(Row) 단위 저장 방식이 아니라 컬럼(Column) 단위로 데이터를 저장
- 즉, 다소 많은 차원을 포함하더라도, 불필요한 컬럼을 로드하지 않으므로 성능 저하가 최소화
② 빠른 집계 및 분석 지원
- 컬럼 스토리지는 NULL 값을 효율적으로 처리 가능
- 특정 차원(Column)만 조회할 경우, 센티피드 팩트 테이블의 단점을 보완 가능
③ OLAP 최적화
- OLAP 시스템에서는 특정 속성(Column)에 대한 집계를 빠르게 수행하는 것이 중요함
- 컬럼 기반 저장 방식에서는 특정 컬럼만 조회하는 것이 가능하여 불필요한 데이터 로드를 방지
➡ 기능적으로 문제없으나 현실적인 문제는 존재
- 컬럼 개수가 많아질수록 관리 복잡도가 증가
- 트랜잭션 처리보다는 분석(Analytics) 목적에 한정하여 활용하는 것이 바람직
결론
센티피드 팩트 테이블은 반드시 피해야하는 테이블 구성 방식으로 알려져 있고 DW 모델링을 하다보면 자연스럽게 의식하게 되는 포인트 이기도 합니다. 이런저런 이유로 모델링을 하다보면 덕지덕지 차원들이 붙어버린 테이블을 보게 되고 그것을 정리하기에는 이미 늦어버린 상황도 많이 보게 됩니다. 따라서 가능한한 연관된 차원끼리 묶어서 잘 분리하여 활용도를 높일 수 있도록 하는 게 중요합니다. 여기서 또 하나 공부를 하던 저에게 새롭게 다가온 사실이 있는데 센티피드 팩트 테이블을 무조건 피할 필요는 없다는 점입니다. 특히 HANA DB와 같은 컬럼형 데이터베이스를 쓴다면 굳이 성능 때문에 센티피드 팩트 테이블을 피할 필요는 없다는 말이죠. 그야 컬럼 기반의 저장 구조를 가지고 있다면 컬럼이 아무리 늘어나더라도 불필요한 컬럼은 로드하지도 않으니 성능 저하가 유의미하게 있지는 않다는 것이니 말입니다. SAP위주 개발을 하고 HANA DB에 익숙해지고 있는 저로서는 신경쓰지 않을 수 없는 부분이기도 하였습니다. DW의 기능에 대해서 한층 더 깊이 이해하게 된 것 같아 기쁘네요.
'DW' 카테고리의 다른 글
| SCD(Slow Change Dimension) 유형 정리 (0) | 2025.03.17 |
|---|---|
| SAP DataSphere 데이터 플로우에서 테이블 삭제 후 재생성 불가 이슈 해결 방법 (0) | 2025.02.19 |
| 재고 팩트 테이블 처리 방식 (0) | 2025.02.16 |
| Surrogate Key 개념 정리 및 SAP에서의 활용 비교 (2) | 2024.12.18 |