DATOR


효과적인 데이터 접근을 위한 데이터 마트 설계 기법 4가지 Data Modeling


최근 빅데이터와 관련된 기술이 증가하면서 기존에 존재하던 데이터웨어하우스 시장에 대한 관심이 많이 줄어들었다. 빅데이터가 모든 데이터 시장을 재편성하고 기존의 데이터 시장이 빅데이터로 모두 처리가 가능한 것처럼 말이다. 마치 기존에 있던 휴대폰, MP3, PMP시장을 스마트폰으로 인하여 재편성되는 것처럼 사람들은 느끼고 있다. 하지만 개인적인 생각으로는 빅데이터에 대해서 너무 과대평가 하고 있는 것이다. 빅데이터는 다른 시장의 발전과 맞물려 함께 성장하고 있기는 하지만 기존의 시장을 대체하기에는 현재 부족한 점이 많다는 것이다. 물론 이후에 시장이 어떻게 변하게 될지는 모르겠지만 현재의 시점을 기준으로 데이터웨어하우스 시장을 빅 데이터만으로는 대체하기에는 어렵다는 것을 말하고 싶다.

이러한 이야기를 먼저 하는 이유는 데이터웨어하우스 설계에서 활용할 수 있는 '효과적인 데이터 접근을 위한 데이터 마트 설계 기법' 에 대해 설명하기 위함이다. 여기서 말하는 '효과적인 데이터 접근'이란? 사용자가 데이터를 엑세스 하는데 있어서 성능상의 이익을 갖을 수 있도록 하며, 이로 인해 발생하는 데이터의 비효율을 최소화 하는 것을 의미한다성능상의 이익이란 사용자가 접근하는 데이터의 양을 최소화 할 수 있도록 설계하는 것을 의미하며, 데이터의 비효율을 최소화 한다는 것은 위를 구현하기 위해 집계되고 중복된 데이터 마트를 생성하는 것을 의미한다.

또한 이 설계 기법은 비즈니스의 성과 지표를 충실하게 지원하고자 하는 것 역시 목표이다. 이야기가 벗어나기는 하지만 기업의 전략을 뒷받침하는 구체적인 목표와 이를 어느 정도 달성하고 있는지에 대한 성과 측정은 정련(Alignment)는 필수적이기 때문에 제대로 설계되어 있는 데이터웨어하우스의 데이터는 어떠한 전략을 지원하고 있는지는 알아야 한다. 이러한 정련의 프로세스를 부분적으로 지원하기도 한다. 그렇기 때문에 이 설계 기법은 성과 지표를 정확하게 이해되지 못한다면 부실한 결과를 가져올 것이다. 하나의 데이터 마트가 지원하는 성과 지표가 100개라면 이를 분류하여 n개의 데이터 마트가 100개의 성과 지표를 분할하여 지원하도록 바꾸는 것이다. 위에서 말했던 데이터 비효율은 바로 n개의 데이터 마트를 생성해야 한다는 것을 의미한다.

이 데이터 마트 설계 기법은 앞 단계의 슈퍼 데이터 마트 설계에서부터 시작이 된다. 슈퍼 데이터 마트라는 것은 기업 수준에서의 요구 사항을 수집하여 만든 데이터 마트를 의미한다. 이는 매우 큰 사이즈의 데이터 마트이며, 특정 요구 사항만을 만족시키기 데이터 마트가 아니라는 것이다. 기업의 핵심적인 기능과 핵심 데이터를 기준으로 생성이 된다. 전사적인 분석의 관점에서 접근하기 하는 것이기 때문에 차원 테이블은 최대한 공유되어야 하고 사실 테이블은 중복을 방지하는 것에 중점을 둔다. 이러한 슈퍼 데이터 마트의 설계가 선행되어야 하는 것이 옳기는 하나 본 내용의 접근 방법은 반드시 이러한 상태가 아니어도 진행을 할 수 있기 때문에 다음 기회에 다시 설명하도록 하겠다. 좀 더 자세한 내용을 원한다면 Ralph Kimball의 'The Data Warehouse Toolkit'을 보면 참고하면 된다.

효과적인 데이터 접근을 위한 데이터 마트 설계 기법은 데이터 마트를 다양하게 조정한다고 볼 수 있다. 설계 기법은 차원 테이블에 대한 3개의 방법, 사실 테이블에 대한 1개의 방법 등 총 4개의 기법으로 구성되어 있다.

 

Key Descirption 1

 

차원 분할, 차원안에 존재하는 다양한 요소를 파악하여 계층 구조를 기준으로 차원을 분할한다

 

Detail Explanation

 

거대한 차원의 다양한 속성에는 서로 간의 연관 관계로 인하여 다양한 계층 구조로 이루어지게 된다. 이러한  계층 구조를 기준으로 여러 개 차원으로 나누는 이유는 사실 테이블의 사이즈 감소 시키기 위한 과정이기 때문이다. 계층 구조로 분리된 차원 중 성과 지표에 사용되지 않는 차원은 제거하여 사실 테이블을 감소시킬 것이기 때문이다. 이 과정속에서 사실테이블의 행의 수가 증가할수도 있다. 왜냐하면 차원의 실제 행의 수와 계층 구조간의 곱이 더 많이 존재할 수 있기 때문이다. 이러한 문제점에 대해서는 다시 다루도록 하겠다. 반드시 모든 계층구조를 누락없이 파악하고 개별 차원 테이블로 만든다.


그림1-1.jpg


그림 1. 고객의 차원에 존재하는 다양한 계층 구조 1 >


그림1.jpg


그림 2.  고객의 차원에 존재하는 다양한 계층 구조 2 >


계층 구조에 대한 파악 요소는 첫번째로 계층 구조의 형태가 균형적인 계층적인 구조인지, 비대칭적인 계층 구조인지 확인한다. 두번째로 이 계층 구조로 만들어진 차원 테이블의 예상 깊이를 파악하여야 하며, 마지막으로 계층 구조 마다 몇 개의 행으로 구성이 될지 파악해야 한다.


그림2.jpg


그림 3. 일자를 구성하는 계층 구조의 형태 >


이렇게 파악된 계층 구조는 차원 테이블의 분할에 바탕이 된다. 분할된 차원 테이블은 반드시 이력 관리에 대한 방법을 정해야 한다. 반드시 원(Raw)데이터의 규칙을 반드시 따를 필요는 없고, 새롭게 정의해도 무방하다. 차원 테이블의 이력관리는 일반 업무처리의 데이터 모델에서 사용하는 이력관리보다는 고려할 사항이 많다. 그 중에 가장 문제점은 업무처리의 모델에서는 작성된 쿼리자체가 고정적이기 때문에 이는 개발의 문제가 되며 사용상의 문제는 크게 발생되지 않는다. 하지만 데이터웨어하우스에서는 다양한 사람이 직접 데이터에 접근하는 경우가 많고, 이에 따라 즉석에서 작성된 쿼리(ad hoc query)가 다수 발생되기 때문에 이력관리 방법은 단순히 개발의 문제가 아니라 사용상의 문제에서도 발생할 가능성이 있기 때문이다. 그렇기 때문에 질의에 대해 간단하게 접근하고 데이터의 일관성을 보장하는 방법으로 차원의 이력관리 방법은 정의되어야 한다.

앞서 설명한 슈퍼 데이터마트의 개념에서 보면 차원과 차원간의 존재가능성으로 본다면 매우 많은 사실이 발생해야 하지만 실제 업무에서의 발생 빈도는 이보다 적을 가능성이 매우 높다는 것이다. 예를 들어, 식품 체인점을 다루는 본사가 있다고 가정하자. 우리가 슈퍼 데이터마트의 개념에서 설계한 차원은 상품, 상점, 일자로 구성이 된 차원 테이블과 이에 따른 사실 테이블로 구성이 된다. 300개의 상점과, 각 상점에서 40,000 상품들을 다루고 있다면, 5년간 또는 1,825일 동안 레코드를 유지한다고 가정하면 사실 테이블 행들의 최대 개수는 220억건 일것이다. 하지만 각 상점에서 일간 판매되는 상품의 개수는 4,000개정도만이 실제로 판매 되므로 사실 테이블의 예상치는 20억건정도에 해당이 된다. 최종 시점에 집계된 형태를 이용할지, 원 자료(Raw data)형태의 마트를 이용할지 판단을 용이하게 한다.


그림3.jpg


그림 4. 차원에 존재할 수 있는 모든 경우의 수와 실제 존재하는 경우의 수에 대한 차이 >

 

Key Descirption 2

 

차원 제거, 차원안에 존재하는 다양한 요소를 파악하여 계층 구조를 기준으로 차원을 분할한다  분석View에서 불필요한 차원을 제거한다

 

Detail Explanation

 

차원이 각 계층 구조를 기준으로 분할하게 되면, 많은 차원이 만들어지게 된다. 이러한 차원들 중에는 특정 분석 View관점에서 보면 필요한 것도 있고, 불필요한 것도 있을 수 있다. 이러한 차원들에 대해서 불필요한 차원들을 제거함으로써 사실 테이블에 대해 사이즈 감소로 이르게 된다.

 

차원의 제거에는 두 가지 부류가 있는데, 하나는 완전히 사용되지 않는 차원을 제거하는 것이다. 이러한 차원은 성과 지표 또는 분석 View 관점에서 분석의 Fact에서 사용되지 않거나 별다른 의미를 가지고 있지 않기 때문에 제거하더라도 무방하다. 하지만 반드시 알아야 할 것은 추후에 필요할 수 있기 때문에 아예 삭제해버리기 보다는 사용하지 않는다는 처리로 해놓는 것을 권하는 바이다. 앞에서 애써 분석해 놓은 것을 버릴 필요는 없다.


그림4.jpg


< 그림 5. 분석 View별 차원 테이블의 표현 >


두 번째 경우는 특정 분석의 관점에서는 사용이 되지만 또 다른 특정의 분석 관점에서는 사용되지 않을 때이다. 슈퍼 데이터마트는 분석의 관점이 아니라 기업의 전사적인 요구 사항 수준에서 생성이 되었기 때문에 매우 크다. 이 설계 기법의 여러 이점 중 하나인 특정 분석의 관점을 만족시키는 데이터 마트를 설계하는 기법을 제공하는 것이기 때문에 친밀도가 높은 분석의 관점끼리 모으다보면 불필요한 차원이 생기게 되어 있다. 이러한 차원을 제거하여 사실 테이블의 사이즈를 감소시키는 것이다. 성과 지표와 분석 View의 친밀도를 계산하는 과정은 다음 기회에 준비하도록 하겠다.

이러한 차원 제거를 하기 위해서는 기업의 전략에서부터 목표, 성과 지표까지의 연결이 되어 있어야하며, 이러한 성과 지표와 데이터를 연결하는 과정이 이루어지는 것이기 때문에 앞선 전략과 목표, 성과 지표까지의 이해가 반드시 선행이 되어야 위의 작업이 가능하다.

 

Key Descirption 3

 

차원 병합, 차원 테이블 중에 선택적인 성격의 차원이 아니라 분리하여 보는 성격의 차원 테이블에 대해 사실 테이블의 구성 요소로 병합하는 방법이다.

 

Detail Explanation

 

차원이 분할되고 제거되는 과정을 거치고 나면 실제 필요한 차원과 사실 테이블만이 남게 된다. 이러한 차원들은 실제 성과 지표와 분석 View의 관점에서 보면 필요한 테이블만 남기 때문에 데이터의 사이즈를 줄이는 것에 한계가 있다. 그리고 차원의 개수가 많으면 데이터 간의 연결과정, 즉 조인(Join)이 늘어나기 때문에 성능상의 문제점이 발생하게 된다. 이러한 문제점을 해결하는 방법 중에 하나인 차원의 병합은 차원을 사실 테이블에 전체 또는 부분적으로 합치면서 성능상의 이점을 가져가게 된다.


그림7.jpg


< 그림 6. 차원 테이블의 전체 병합과 부분 병합 >


차원의 전체 병합이란 차원테이블에 존재하는 모든 차원이나 사용되는 차원에 대하여 사실 테이블의 사실로 지정하고 해당 차원 테이블을 완전히 사라지게 하는 것이다. 이는 개별의 하나하나의 차원이 하나의 속성으로 표현이 되기 때문에 속성의 개수가 많아진다는 단점이 있다. 하지만 이 데이터 마트를 조회할 때 반드시 구분하고 같이 보는 애플리케이션이 많다면, 성능상의 이점이 발생하게 된다.

차원의 부분 병합이란 차원테이블의 계층 구조중 반복적인 차원에 대하여 사실 테이블의 사실로 지정하고 계층 구조중 상위의 차원을 이용하여 좀 더 작아진 사이즈의 차원 테이블을 유지하는 것이다. 예를 들어 월별로 집계를 하고 있는 사실 테이블이 있다고 가정하자. 이 사실 테이블은 재무분석을 위해 사용이 되기 때문에 집계 단위가 항상 월 단위로 이루어진다. 그리고 계절에 대한 특성을 많이 가지고 있는 영업 조건에 있어서 이전 년도와의 데이터 비교가 많다. 이러한 경우에는 차원 테이블을 월별로 가지고 있는게 아니라 년도로 유지하고 12개의 월을 속성으로 가지고 있을 경우 특정 년도 조회시 앞선 경우보다 적은 로우를 읽어도 된다.

이 차원 병합은 이를 조회하는 애플리케이션의 특성을 어느 정도 이해해야 한다. 그리고 가급적 차원 테이블의 차원의 수가 너무 많을 경우에는 속성이 배로 늘어나기 때문에 부분적으로 적용해야 한다.

 

Key Descirption 4

 

사실 집계, 사실 테이블을 차원 테이블의 계층 구조를 이용하여 상위 단계로 집계하는 방법이다

 

Detail Explanation

 

차원 병합을 거치고 나면 성과 지표 및 분석 View에서 필요한 차원과 사실 테이블만이 남게 된다. 그런데 처음 단계의 사실 테이블은 원 데이터(Raw Data)에 매우 근접한 형태를 가지고 있었지만, 계층 구조별로 분리된 차원으로 인하여 원 데이터에서 집계된 형태의 데이터가 된다. 분리된 차원에 존재할 수 있는 모든 경우의 수는 최초의 차원보다 많을 수 있지만 실제 발생이 없는 데이터를 제외한다면 최초의 형태보다는 많을 수 없기 때문에 그 집계된 크기가 매우 조금 감소했을수도 있고, 아니면 매우 많이 감소된 경우도 있을 것이다. 그러나 성과 지표나 분석 View에서는 이 상태의 데이터 보다는 좀 더 집계된 형태의 데이터를 필요로 할 수 있다. 이유는 사용자는 업무 처리의 관점이 아니라 이를 다양한 각도에서 바라보고, 다양한 차원에서 비교하기 위해서는 집계된 형태의 데이터가 보기에 적합할 것이다. 이러한 집계된 형태의 데이터로 만들어 내는 작업이 이번 단계이다.


그림6.jpg


< 그림 7. 물류 비용 최적화를 위한 분석시 최적의 거점 수를 분석하기 위한 분석의 관점에서 필요한 차원의 계층 >


그림5.jpg


< 그림 8. 다양한 차원 테이블을 다양한 레벨로 집계하는 복합 집계의 형태 >


 사실 집계라는 것은 차원 테이블의 계층 구조를 성과 지표와 분석 View를 고려하여 계층 구조를 상위 단계로 높이고, 이에 따라 사실 테이블을 집계하는 것이다. 단일 집계(Single Aggregates)란 단 하나의 차원에 대해서만 계층 구조를 상위 단계로 조정하여 사실 테이블을 집계 하는 것이며, 복합 집계(Multiple Aggregates)란 여러 개의 차원의 계층 구조를 상위 단계로 조정하여 사실 테이블을 집계하는 것을 의미한다.

 사실 집계시 주의할 점의 원인은 원 데이터가 집계된 형태로 제공되기 때문에 원 데이터를 보고자 하거나 다른 집계된 형태의 데이터를 보고자 할 때 문제가 발생한다. 이를 위해 원 데이터까지 액세스가 가능하도록 관리해야 하며, 집계시에 이를 고려하여 속성을 만들어야 한다. 대부분의 필수 적인 속성으로 개수와 합계가 있어야 하며, 선택적으로 기술적인 통계 요소를 고려하여 추가하면 된다.



TAG

Leave Comments


profile우리는 하나님을 믿는다. 다른 모든 것들은 데이터로 검증해야 한다. 

Recent Trackback