이후 장들을 위해서 초석을 쌓는다.
상위 관점에서 데이터 웨어하우스 및 비즈니스 인텔리전스(DW/BI) 시스템을 살펴보는 것으로 시작한다.
1. 비즈니스 중심의 DW/BI 목표
2. 팩트와 디멘션 테이블을 포함하는 다차원 모델링 핵심 개념와 용어
3. 킴벌 DW/BI 아키텍처의 구성요소와 사상
4. 다른 DW/BI 아키텍처와의 비교, 각 아키텍처에서 다차원 모델링의 역할
5. 다차원 모델링에 대한 오해
데이터 수집과 데이터 분석이라는 서로 다른 세계
정보는 대부분 두가지 목적 1)운영상 기록의 보관과 2)의사결정을 위한 분석 으로 사용된다.
데이터 웨어하우스와 비즈니스 인텔리전스의 목표
- DW/BI의 목표는 회사 복도를 걸으면서 현업 관리자들이 하는 이야기를 들으면 쉽게 알아낼 수 있다.
"우리는 엄청난 데이터를 수집하지만, 거기에 접근할 수가 없다"
"우리는 데이터를 사방으로 자르고 쪼개서 분석하길 원한다"
"비즈니스 사용자도 쉽게 데이터에 접근할 수 있어야 한다"
"단지 나에게 중요한 것만 보여줘라"
"우리는 의사결정 자체가 아니라, 누가 올바른 숫자를 갖고 있는 지에 대해 논쟁하느라 전체 회의 시간을 허비한다"
"사람들이 정보 활용을 통해 좀 더 사실 기반으로 의사결정하기를 원한다"
- 정리해보면..
1. DW/BI 시스템은 정보에 쉽게 접근 가능하도록 만들어야 한다.
"우리는 엄청난 데이터를 수집하지만, 거기에 접근할 수가 없다"
"우리는 데이터를 사방으로 자르고 쪼개서 분석하길 원한다"
"비즈니스 사용자도 쉽게 데이터에 접근할 수 있어야 한다"
"단지 나에게 중요한 것만 보여줘라"
"우리는 의사결정 자체가 아니라, 누가 올바른 숫자를 갖고 있는 지에 대해 논쟁하느라 전체 회의 시간을 허비한다"
"사람들이 정보 활용을 통해 좀 더 사실 기반으로 의사결정하기를 원한다"
- 정리해보면..
1. DW/BI 시스템은 정보에 쉽게 접근 가능하도록 만들어야 한다.
2. DW/BI 시스템은 일관된 정보를 제공해야 한다.
3. DW/BI 시스템은 변화에 유연해야 한다.
4. DW/BI 시스템은 정보를 적시에 제공해야 한다.
5. DW/BI 시스템은 정보자산을 보호하는 보안 요새가 되어야 한다.
6. DW/BI 시스템은 향산된 의사결정을 위해 권위 있고 신뢰할 수 있는 토대가 되어야 한다.
DW는 의사결정 지원을 위한 올바른 데이터를 가져야 한다. DW/BI 시스템을 통해 기대할 수 있는 갖강 중요한 성과물은 분석 결과로 제시된 증거에 기반한 의사결정이다. 이러한 의사결정은 DW/BI 시스템이 있기에 가능한 것이며, 비즈니스적으로 영향과 가치를 준다. DW/BI이전에 이름 붙여진 '의사결정 지원 시스템'이라는 말은 여전히 여러분이 설계하는 DW/BI에 대한 최고의 설명이다.
DW는 의사결정 지원을 위한 올바른 데이터를 가져야 한다. DW/BI 시스템을 통해 기대할 수 있는 갖강 중요한 성과물은 분석 결과로 제시된 증거에 기반한 의사결정이다. 이러한 의사결정은 DW/BI 시스템이 있기에 가능한 것이며, 비즈니스적으로 영향과 가치를 준다. DW/BI이전에 이름 붙여진 '의사결정 지원 시스템'이라는 말은 여전히 여러분이 설계하는 DW/BI에 대한 최고의 설명이다.
7. DW/BI 시스템이 성공적이라고 생각하기 위해서는 현업이 DW/BI 시스템을 받아 들어야 한다.
다차원 모델링 소개
- 다차원 모델링은 두가지 요구 사항을 동시에 충족하기 떄문에 분석 데이터 제공 시 선호하는 기법으로 널리 바다들여진다.
① 비즈니스 사용자에게 이해하기 쉬운 데이터를 제공
② 빠른 쿼리 성능을 제공
- 다차원 모델링은 데이터베이스를 단순하게 만드는 오래된 기법이다.
- 단순하게 시작한 데이터 모델은 설계 끝까지 단순할 가능성이 있다. 복잡하게 시작한 모델은 결국 복잡하게 끝나서 쿼리 성능은 느리고 현업 사용자에게는 거부 당할 것이다.
① 비즈니스 사용자에게 이해하기 쉬운 데이터를 제공
② 빠른 쿼리 성능을 제공
- 다차원 모델링은 데이터베이스를 단순하게 만드는 오래된 기법이다.
- 단순하게 시작한 데이터 모델은 설계 끝까지 단순할 가능성이 있다. 복잡하게 시작한 모델은 결국 복잡하게 끝나서 쿼리 성능은 느리고 현업 사용자에게는 거부 당할 것이다.
- "모든 것을 더 이상 간단해질 수 없을 만큼 가능한 간단하게 만들어라"
- 갱신 또는 삽입 트랜잭션이 데이터베이스의 한 부분만 건드리기 떄문에 3차 정규화 구조는 운영 업무 처리에 매우 유용하다. 그러나 정규화 모델은 BI쿼리를 처리하기에는 너무 복잡하다.
- 사용자의 예측 불가한 쿼리의 복잡성은 데이터베이스 optimizer를 압도하여 결국 장애 수준의 쿼리 성능을 보이게 된다.
- 갱신 또는 삽입 트랜잭션이 데이터베이스의 한 부분만 건드리기 떄문에 3차 정규화 구조는 운영 업무 처리에 매우 유용하다. 그러나 정규화 모델은 BI쿼리를 처리하기에는 너무 복잡하다.
- 사용자의 예측 불가한 쿼리의 복잡성은 데이터베이스 optimizer를 압도하여 결국 장애 수준의 쿼리 성능을 보이게 된다.
1) 스타 스키마 대 OLAP 큐브
- 관계형 DBMS에서 구현되는 다차원 모델은 별 모양 구조를 닮아 스타스키마라 불린다.
- 다차원 데이터베이스 환경에서 구현되는 다차원 모델은 OLAP큐브라 불린다.
- 스타 스키마와 OLAP큐브 모두 디멘션들로 구성된 공통적인 논리 설계를 갖지만 물리적인 구현은 다르다.
- 일반적으로 상세한 최소단위 정보는 스타 스키마에 적재하고, OLAP 큐브는 그 후에 부가적으로 스타 스키마로
부터 생성하는 것을 권장한다.
- 다차원 데이터베이스 환경에서 구현되는 다차원 모델은 OLAP큐브라 불린다.
- 스타 스키마와 OLAP큐브 모두 디멘션들로 구성된 공통적인 논리 설계를 갖지만 물리적인 구현은 다르다.
- 일반적으로 상세한 최소단위 정보는 스타 스키마에 적재하고, OLAP 큐브는 그 후에 부가적으로 스타 스키마로
부터 생성하는 것을 권장한다.
- 스타 스키마의 두 가지 핵심 요소를 살펴보자.
2) 성과 측정을 위한 팩트 테이블
- 다차원 모델에서 팩트 테이블은 조직의 비즈니스 프로세스 이벤트에서 발생하는 성과 측정값을 저장한다.
- 다차원 모델에서 팩트 테이블은 조직의 비즈니스 프로세스 이벤트에서 발생하는 성과 측정값을 저장한다.
- 가장 유용한 팩트는 판매 금액처럼 숫자이면서 합산 가능한 팩트이다. -> 합산 가능여부는 매우 중요하다.
- 부분적 합산만 가능 : '계좌잔액' , '재고수량' 팩트는 시간 디멘션으로는 합산할 수 없다.
- 아예 합산이 불가능한 팩트 : '단가', '비율'은 어떤 디멘션으로도 합산할 수 없다.
- 팩트의 그레인 : 1)트랜잭션(일반적), 2)주기적 스냅샷, 3) 점진적 스냅샷
3) 배경을 설명하는 디멘션 테이블
- 50~100개의 속성을 갖는 경우가 일반적
- 디멘션 속성은 '~별'로 식별된다. 예를 들면, 사용자가 브랜드별 매출액을 보기 원할 때, 브랜드는 디멘션 속성으로 사용 가능해야 한다.
- 어떤 숫자가 팩트인지 디멘션 속성인지 결정해야 하는 설계자의 딜레마는 대부분의 경우 그리 어렵지 않다. 연속적인 숫자 값이 관찰된다면 거의 팩트일 것이다. 비교적 작은 목록 범위 내에서 이산적으로 끊어지는 숫자라면 대부분 디멘션 속성이다.
- 디멘션 테이블은 3차 정규화하지 않고, 한 테이블 안에 다대일 관계를 납작하게 펼치는 반정규화가 일반적이다.
4) 스타 시크마에서 조인되는 팩트와 디멘션
- 다차원 모델의 단순성은 성능 측면에서도 이점이 있다.
킴벌의 DW/BI 아키텍처
- DW/BI 환경에는 고려해야 할 네 가지 분리된 개별 구성요소가 있는데 이는 1)운영계 원천 시스템, 2)ETL시스템, 3)프레젠테이션 영역, 4)BI애플리케이션
1) 운영계 원천 시스템
- 비즈니스 트랜잭션을 포착하여 기록하는 운영 시스템
- 좋은 데이터 웨어하우스는 과거를 보여주어야 하는 원천 시스템의 많은 책임을 경감시켜준다. 원천 시스템은 다른 운영 시스템에 있는 제품, 고객, 지역, 기간 등 공통 데이터를 공유할 책임이 없는 특정 목적만을 위한 애플리케이션이다.
2) 추출, 변환 및 적재 시스템 (ETL)
- 운영계 원천 시스템가 DW/BI 프레젠테이션 영역 사이의 모든 것이다.
3) 비즈니스 인텔리전스 지원을 위한 프레젠테이션 영역
- 최소단위 데이터는 정규화 모델에 두고 다차원 모델에는 요약 데이터만 저장하는 것은 용납될 수 없다.
4) 비즈니스 인텔리전스 애플리케이션
대안적 DW/BI 아키텍처
- 아키텍처 성향과 관계없이 다차원 모델링은 항상 존재
1) 독립적 데이터 마트 아키텍처
- 아키텍처화 되지 않은 아키텍처
- 이런것도 있다..
2) 인몬의 허브-앤-스포크 기업 정보 공장(CIF) 아키텍처
- EDW : 이 처리로부터 나온 최소단위 데이터는 3차 정규화 데이터베이스에 적재된다. 이 정규화된 최소단위 저장소는 CIF아키텍처에서 EDW라 불린다. 킴벌 아키텍처는 ETL처리를 지원하기 위해 선택적으로 정규화를 허용하지만, CIF에서 정규화된 EDW는 필수 구조이다.
- Data Delivery : CIF방식을 적용한 기업에는 상세 레벨 데이터 또는 가용 데이터 적시성 때문에 종종 EDW에 접근하는 현업 사용자가 있다. 그러나 이후의 데이터 전달 ETL프로세스는 전적으로 후방의 비즈니스 사용자를 지원하는 리포팅과 분석 환경을 생성한다. 분석용 데이터베이스는 다차원으로 구성되기도 하지만 일반적으로 킴벌 아키텍처의 프레젠테이션 영역 구조와 다르다. 그들은 주로 부서 중심적이고(비즈니스 프로세스 중심으로 구성되기 보다), 집계된 데이터를 제공한다(최소 단위 데이터보다는). 데이터 전달 ETL프로세스가 기본적인 요약을 넘어서는 비즈니스 규칙을 적용한다면(부서 차원에서 칼럼명 변경 또는 계산 로직 변경과 같은), EDW에 있는 최소단위 데이터와 분석용 데이터베이스를 서로 연관시키기는 매우 어려울 것이다.
- 킴벌 아키텍처처럼, CIF는 전사 차원의 데이터 중재와 통합을 주장한다. CIF는 정규화된 EDW가 이 역할을 수행하고, 킴벌 아키텍처는 표준 디멘션을 갖는 전사 버스의 중요성을 강조한다.
- 기술적으로 정규화 과정이 곧 통합을 말하는 것은 아니다. 정규화는 단지 다대일 관계를 구현하는 물리 테이블을 생성할 뿐이다. 통합은 서로 다른 원천에서 발생하는 불일치의 해결을 필요로 한다. 분리되어 호환되지 않는 데이터베이스 원천들도 통합과는 전혀 관계없이 정규화될 수 있다. 표준 디멘션에 기반한 킴벌 아키텍처는 이와 반대로, 정규화 여부에 상관없이 데이터 불일치 자체를 해결하는데 초점을 둔다.
- 순수 CIF아키텍처의 극단적인 형태는 데이터 웨어하우스로서 사용될 수 없다. 이런 아키텍처는 최소단위 데이터를 정규화 구조에 가두어 조회하기 어렵게 하고, 서로 다른 현업 사용자 그룹들에게 부서별로 호환되지 않는 데이터 마트를 제공한다.
3) 허브-앤-스포크와 킴벌 하이브리드 아키텍처
- 킴벌과 인몬 CIF 아키텍처의 결합
- CIF 중심의 EDW를 생성하되 분석과 리포팅을 원하는 비즈니스 사용자의 접근은 금지한다. → 프레젠테이션 영역을 생성하는 원천에 불과
- 프레젠테이션 영역의 데이터는 다차원적이고 최소단위이며, 프로세스 중심적으로 전사 데이터 웨어하우스 버스 아키텍처를 준수한다.
- 사용자 쿼리는 전적으로 다차원의 프레젠테이션 영역에서 처리하도록하여 3차 정규화 EDW의 성능과 활용성 문제를 해결하면서 기존에 투자된 통합 저장소를 활용할 수 있다. → 3차 정규화 EDW 생성에 이미 투자를 했는데, 이러한 EDW가 기대하는 만큼 빠르지 않고 유연한 리포팅과 분석을 제공하고 있지 않은 상태라면, 이 하이브리드 방식은 여러분의 기업에 적당할 수 있다.
- 하지만 아무것도 없이 처음부터 시작한다면.... 최소 단위 데이터가 중복적으로 저장되고 이동되기 떄문에 개바로가 유지보수 측면에서 시간과 비용이 많이 든다.
- 사용자 쿼리는 전적으로 다차원의 프레젠테이션 영역에서 처리하도록하여 3차 정규화 EDW의 성능과 활용성 문제를 해결하면서 기존에 투자된 통합 저장소를 활용할 수 있다. → 3차 정규화 EDW 생성에 이미 투자를 했는데, 이러한 EDW가 기대하는 만큼 빠르지 않고 유연한 리포팅과 분석을 제공하고 있지 않은 상태라면, 이 하이브리드 방식은 여러분의 기업에 적당할 수 있다.
- 하지만 아무것도 없이 처음부터 시작한다면.... 최소 단위 데이터가 중복적으로 저장되고 이동되기 떄문에 개바로가 유지보수 측면에서 시간과 비용이 많이 든다.
다차원 모델링에 대한 오해
오해1 : 다차원 모델링은 오직 요약 데이터를 위한 것이다.
- 비즈니스 사용자가 요청한 질문들을 모두 예측할 수 없기 때문에 그들이 가장 상세한 데이터를 조회할 수 있도록 해야 한다. 그래야 그들은 비즈니스 요청에 따라 데이터를 롤업할 수 있다.
오해2 : 다차원 모델은 전사가 아닌 부서단위 모델이다.
- 다차원 모델은 조직의 부서에 기초해 경계를 그리는 것이 아니라 주문, 송장, 서비스 콜과 같은 비즈니스 프로세스를 중심으로 구성되어야 한다.
오해3 : 다차원 모델은 확장성이 없다.
- 정규화 모델과 다차원 모델 모두 동일한 정보와 데이터 관계를 포함한다. 논리적으로 내용은 동일하다.
- 한 모델로 표현된 모든 데이터 관계는 다른 모델로 정확히 표현될 수 있다.
- 난이도는 다르겠지만, 정규화 모델과 다차원 모델 모두 동일 지문에 정확히 대답할 수 있다.
오해4 : 다차원 모델은 예측 가능한 분석 패턴에만 유용하다.
- 다차원 모델은 사전에 정의된 리포트나 분석에 맞춰서 설계하지 말아야 한다.
- 설계는 측정 프로세스를 중심으로 해야 한다.
- 분명히 BI애플리케이션의 조회조건과 레이블을 고려하는 것은 중요하다. 그러나 여러분은 Top 10 리포트 목록을 위해 설계하지는 말아야 한다. 이 목록은 계쏙 바뀌어 다차원 모델이 계쏙 변경되게 만든다.
- 핵심은 항샹 변화하는 분석 패턴이 아니라 안정된 조직이 측정 이벤트에 초점을 맞추는 것이다.
- 쿼리 유연성의 비밀은 팩트 테이블을 가장 낮은 레벨로 만드는 것이다.
- 다차원 모델을 위한 정확한 시작점은 유연성과 확장성을 극대화할 수 있도록 최하위 상세 데이터에서 데이터를 표현하는 것이다.
오해5 : 다차원 모델은 통합되지 않는다.
- 다차원 모델은 전사 데이터 웨어하우스 버스 아키텍처를 준수한다면 반드시 통합된다.
- 표준 디멘션은 ETL 시스템에서 중아아 집중적이고 지속적인 마스터 데이터로서 생성되고 유지된다. 그리고 데이터 통합과 의미론적 일관성을 위해 다차원 모델에서 재사용된다.
오해1 : 다차원 모델링은 오직 요약 데이터를 위한 것이다.
- 비즈니스 사용자가 요청한 질문들을 모두 예측할 수 없기 때문에 그들이 가장 상세한 데이터를 조회할 수 있도록 해야 한다. 그래야 그들은 비즈니스 요청에 따라 데이터를 롤업할 수 있다.
오해2 : 다차원 모델은 전사가 아닌 부서단위 모델이다.
- 다차원 모델은 조직의 부서에 기초해 경계를 그리는 것이 아니라 주문, 송장, 서비스 콜과 같은 비즈니스 프로세스를 중심으로 구성되어야 한다.
오해3 : 다차원 모델은 확장성이 없다.
- 정규화 모델과 다차원 모델 모두 동일한 정보와 데이터 관계를 포함한다. 논리적으로 내용은 동일하다.
- 한 모델로 표현된 모든 데이터 관계는 다른 모델로 정확히 표현될 수 있다.
- 난이도는 다르겠지만, 정규화 모델과 다차원 모델 모두 동일 지문에 정확히 대답할 수 있다.
오해4 : 다차원 모델은 예측 가능한 분석 패턴에만 유용하다.
- 다차원 모델은 사전에 정의된 리포트나 분석에 맞춰서 설계하지 말아야 한다.
- 설계는 측정 프로세스를 중심으로 해야 한다.
- 분명히 BI애플리케이션의 조회조건과 레이블을 고려하는 것은 중요하다. 그러나 여러분은 Top 10 리포트 목록을 위해 설계하지는 말아야 한다. 이 목록은 계쏙 바뀌어 다차원 모델이 계쏙 변경되게 만든다.
- 핵심은 항샹 변화하는 분석 패턴이 아니라 안정된 조직이 측정 이벤트에 초점을 맞추는 것이다.
- 쿼리 유연성의 비밀은 팩트 테이블을 가장 낮은 레벨로 만드는 것이다.
- 다차원 모델을 위한 정확한 시작점은 유연성과 확장성을 극대화할 수 있도록 최하위 상세 데이터에서 데이터를 표현하는 것이다.
오해5 : 다차원 모델은 통합되지 않는다.
- 다차원 모델은 전사 데이터 웨어하우스 버스 아키텍처를 준수한다면 반드시 통합된다.
- 표준 디멘션은 ETL 시스템에서 중아아 집중적이고 지속적인 마스터 데이터로서 생성되고 유지된다. 그리고 데이터 통합과 의미론적 일관성을 위해 다차원 모델에서 재사용된다.
댓글 없음:
댓글 쓰기