[기고] 천천히 변경되는 디멘젼 설계 방법

▣ 디멘젼 & 팩트

DW 세상은 디멘젼과 팩트로 구성된다.

디멘젼과 팩트는 DW 내에서 각각 서로 다른 역할을 맡고 있고, 이로 인해 주로 관리하는 속성도 서로 다른 특징을 가진다. 

팩트는 비즈니스 이벤트별로 측정/분석하려는 값(Measure)를 관리한다. 비즈니스 이벤트란 우리가 관심을 가지는 업무적인 사건이나 행위를 말한다. 주문, 배송, 계약, 서비스 가입, 상담 등이 대표적인 비즈니스 이벤트의 종류이다. 팩트는 주로 건수, 금액, 비율과 같은 측정이나 연산이 가능한 정량화된 속성을 가진다.

디멘젼은 비즈니스 이벤트의 상황(Context)을 설명하는 관점의 역할을 한다. 이벤트의 상황이란 이벤트를 발생시킨 주체, 대상, 시기, 장소, 방법, 사유 등을 말한다. 예를 들면, 주문(이벤트)을 발생시킨 고객, 상품, 판매점, 판매지역, 판매 일자, 배송방법, 취소 사유 등이 대표적인 디멘젼이다.

관리하는 속성도 수치 데이터 보다는 상황을 “설명”하기 위한 속성이 대부분이다.

디멘젼과 팩트는 데이터 발생과 관련해서도 서로 다른 특징을 가진다.

팩트는 비즈니스 이벤트에 종속적이다. 팩트는 비즈니스 이벤트의 발생 없이 데이터가 발생하지 않는다. 주문의 발생 없이 주문 팩트의 데이터 발생이나 변경이 있을 수 없다. 주문의 변경이나 취소가 발생할 수 있지만 이런 경우도 이벤트 발생으로 본다면 이벤트 없이 데이터가 변경되는 일은 없다고 할 수 있다.

반대로, 디멘젼은 비즈니스 이벤트에 종속되지 않는 독립적인 데이터이다. 주문 데이터가 발생하지 않아도 고객 데이터가 생길 수 있다. 주문 이벤트와 무관하게 고객의 성명이 변경되고, 거주지 주소가 바뀔 수 있으며, 시간이 지남에 따라 연령이 높아진다.

DW시스템은 장기간의 데이터를 시계열 별로 분석하기 위한 시스템이다. 주문 데이터가 발생하던 시점의 고객이나 상품 같은 상황을 설명하기 위한 디멘젼의 데이터 구조를 필요로 한다. 즉 동일한 고객, 상품의 시점별 정보를 관리하기 위한 변경 이력 관리 구조를 적용해야 한다.

▣ Slowly Changing Dimensions 

변경되는 디멘젼을 관리하기 위한 모델링 방법으로 Slowly Changing Dimensions (이하 SCD)라는 방법이 있다. 이 방법은 대표적인 DW 아키텍처 중 하나인 BUS 아키텍쳐로 유명한 Ralph Kimball을 통해 알려졌다. 

SCD방법에서 말하는 ‘천천히(slowly)’는 절대적인 수치나 빈도의 기준으로 판정할 수 있는 것은 아니다. 일반적으로 디멘젼이 팩트(이벤트)에 비해 천천히 변경(발생)되기 때문에 붙인 이름으로 생각된다. 물론 모든 디멘젼이 천천히 변경되는 것은 아니고, 팩트와 비교해서도 빨리, 자주 변경되는 경우도 존재한다.

그럼 지금부터 각각의 SCD 유형을 살펴보도록 하겠다.

▣ SCD Type 1 : 최종 값만 유지 (Overwrite)

쿨(?)하게 변경 전 값은 보관하지 않고, 변경 후 값으로 덮어쓰는 방식이다.

만일 아래와 같이 상품명이 ‘상품명A’에서 ‘상품명B’로 변경된 경우 ‘상품명B’만 관리한다.

상품명 변경 전에 판매된 상품이 존재하는 경우, 판매 당시의 상품명은 조회할 수 없는 제약이 발생한다. 장점이라면 다른 방법에 비해 적용이 간단하다는 것이며, 시계열에 따른 분석이 필수적인 DW에서 범용적으로 사용하기에는 무리가 있다.

간혹 이벤트 시점의 디멘젼 조회를 위해, 디멘전은 Type 1을 유지하면서 팩트 테이블에 상품명 속성을 만들고, 이벤트 발생 당시의 상품명을 입력하는 경우도 있다. 하지만 변경이 가능한 모든 속성을 팩트에 포함시키는 것은 현실적으로 불가능하며, 경우에 따라 팩트 테이블의 물리적 사이즈가 감당하기 어려울 정도로 커지는 경우도 있다. 

▣ SCD Type 2 : 변경 데이터를 Row로 추가

변경 전 데이터는 Row를 유지한 채로, 변경 후 데이터에 해당하는 Row를 추가하는 방식이다.

변경되는 모든 데이터를 가지고 있으므로, 원하는 시점(주로 비즈니스 이벤트가 발생한 시점)의 디멘젼 정보 조회가 가능한 장점이 있다.

구조 상 특이한 부분은 디멘전은 원천 시스템에서 정의한 식별자가 아닌, DW에서 정의한 대리Key(Surrogate Key)를 식별자로 사용하는 것이다. 예를 들면, 상품ID는 변하지 않는 속성으로 고정시키고, 상품 디멘젼의 속성이 변경될 때마다 상품의 새로운 대리KEY 값을 만들어 디멘젼의 PK로 사용한다. 팩트 테이블과는 상품대리KEY를 통해 연결하여, 이벤트 발생 시점의 상품 디멘젼 정보를 조회할 수 있도록 한다.

Type 2는 데이터의 모든 변경 사항을 저장하고 이용할 수 있는 반면, 데이터 변경이 매우 빈번한 경우에는 사이즈의 증가로 인한 관리 부담이 발생할 소지가 있다. 대리KEY 사용으로 인해 팩트 테이블의 변경이 반드시 필요하여, 이미 구축된 시스템에 적용할 때 상대적으로 많은 비용이 발생한다.

▣ SCD Type 3 : 변경 전 값을 속성으로 관리

별도의 Row는 추가하지 않고, 이전 값을 관리하기 위한 속성을 추가하는 방식이다.

디멘젼의 고유 레벨을 변경하지 않고 적용 가능한 것이 가장 큰 장점이다. 팩트와 연결이 간단하고, 한 번의 데이터 연결로 디멘젼의 현재와 이전 속성 모두를 조회할 수 있는 것도 장점이다. 기존 데이터 모델이 운영 중인 경우에도 팩트의 변경 없이 적용이 가능하다.

그리고, Type2의 부작용 중 하나인 디멘젼의 사이즈 증가도 거의 걱정할 필요가 없다.

다만, 추가한 속성 수 만큼만 과거 이력을 관리할 수 있는 한계를 가지며, 전체 이력을 완전하게 보유할 수 있는 방법은 아니다. 예를 들면 이전상품명만 관리하는 경우 1차 변경까지는 변경 내용을 가지고 있으나, 2차 이후 변경은 가장 최근 2개 상품명만 관리할 수 있다. 속성을 추가하면 보관 가능한 변경 범위가 늘어나기는 하나, 컬럼 추가를 통한 확장이므로 한계가 있다.

참고로, 반드시 이전 속성만 추가할 필요는 없고, 최초 속성이나 업무적으로 의미를 가지는 시점의 속성을 추가하기도 한다.

▣ SCD Type 4 : Mini-디멘젼 추가

값의 변경 내용을 관리하려는 속성만 모아서 별도의 디멘젼을 구성하는 방법이다.

변하지 않는 값이나, 변화를 추적할 필요 없는 속성은 원래의 디멘젼에 남겨두고 (Base 디멘젼), 변화를 관리하려는 속성만 모아서 별도의 디멘젼을 구성한다.

Base 디멘젼의 속성이 많고, 상대적으로 변경 관리할 속성이 적은 경우에는 불필요하게 발생하는 데이터를 최소화고, 물리적인 증가 부담을 줄일 수 있다.

다만, 디멘젼 테이블이 2개 이상으로 분리되고, 조회 시 디멘젼과 팩트 연결이 많아지는 부담이 발생할 수 있다.

데이터 구조 관점에서는 Mini-디멘젼은 Type 2 방법와 동일하게 대리KEY를 사용한다.

원래의 Base 상품디멘젼은 변경 속성이 분리된 것을 제외하면 기존의 데이터 구조와 발생 규칙이 동일하다.

팩트 입장에서는 기존의 상품Base디멘젼과의 연결 이외에 상품Mini 디멘젼과 연결이 추가되며, Type2와 마찬가지로 상품Mini와는 상품대리KEY(Surrogate-Key)로 연결한다.

지금까지 SCD의 기본 유형 4가지를 살펴보았다. SCD 방법론 상으로는 Type 7까지 존재하나, 나머지 방법들은 위에 소개한 방법을 2~3가지 혼합해서 사용하는 하이브리드 방식이므로 별도의 설명은 생략하기로 한다. 

▣ 완벽한 방법은 없다.

지금까지 여러 가지 방법을 소개했지만 모든 상황에 맞는 완벽한 방법은 없다. 위의 방법은 각각의 용도가 있고 장단점이 있어 만들어진 방법인 만큼 각자의 상황에 맞는 방법을 선택하면 그 방법이 가장 좋은 방법이 될 것이다. SCD또한 여러 가지 방법의 한 종류일 뿐이다.

SCD Type 2는 모든 비즈니스 이벤트 시점 별로 분석이 가능한 멋진 방법이다. 하지만 기존 시스템이 존재하는 상황에서는 관련된 팩트에 대해 변경 영향도가 크다. 또한 업무와 관계없는 인조 속성을 사용함으로 인한 사용자의 거부감도 적지 않다. 이를 해결하기 위해서 대리KEY없이 시작/종료 선분이력 형태의 Type2 모델로 DW를 구성하는 경우도 있다. 물론 이 경우 사용자 편의성, BI 구현 가능성, 조회 성능 확보 등의 다른 어려움이 발생할 수 있다. 

모든 상황에 맞는 완벽한 방법은 없다. 참조 모델이나 방법론에 너무 얽매이지 말고 각자 자신의 요구 사항과 환경에 맞도록 변형하고 발전시키는 것이 올바른 방법론 사용이 아닐까 생각해본다.