블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


데이타 웨어하우스 프로젝트 프로세스

아키텍쳐 /BI | 2010. 5. 24. 23:23 | Posted by 조대협
배경
Dataware house (이하 DW)도 다른 첨단 기술 프로젝트와 마찬가지로, 기술이름이 붙은 프로젝트로 시작했다가 결국은 원하는 성과를 이루지 못하는 경우가 허다하다. SOA 프로젝트가 실제 서비스화를 통한 재사용성과 유연성등을 확보해야 하는데, 웹서비스만 구축하면 SOA라고 이름 붙여지고 결국 실패하는 모양새와 유사하다.
이처럼 DW도 DW DBMS만 도입되고 데이타만 한군데 모아놓고 제대로 활용되지 못하고 천덕 꾸러기 형태가 되는 경우가 많다.

1단계. 왜 DW를 도입하는지에 대해서 이유를 찾을것
DW는 기본적으로 경영진에 필요한 비지니스 데이타를 적재적시에 가공하여 의사결정을 도와주고자 하는데 그 목적이 있다. 즉 최종 사용자는 의사결정자가 되는 것이다. 고로, DW를 도입할때, 어떤 의사 결정 자료를 얻는지가 제일 중요하다. 이때. 조직내에서 DW가 시작되게 된 이유를 갖은 사람을 찾는것이 중요하고 그 사람이 어떤 데이타를 원하는지를 알아내야 한다.
 일반적인 요구 사항 분석이다. 그런데 이때, "어떤 테이블을 원하세요?"라고 막연하게 물어보면 답이 안나온다. 상대방은 기술자가 아니라 대부분 비지니스쪽의 사람일 경우가 많기 때문에, "어떤 데이타를 보고 싶고, 그게 왜 중요하세요?", "지금 시스템으로 무슨 데이타를 찾을 수 가 없어서 DW를 도입하는 건가요?" 와 같이 비지관점에서 질문이 이루어져야 한다.
사실 첫단추를 잘 끼어야 한다고.. DW를 도입하는 이유가 가장 중요하다. DW를 기껏 구축했는데, 사용되지 않는다면 자리만 차지하고 있는 비싼 데이타베이스 일뿐이다. 즉 최종 사용자가 어떻게 활용하고 싶은지를 잡아내는 것이 가장 중요하다.

2단계. 실제 데이타를 가지고 있는 사람을 찾을것
1단계에서 최종사용자가 어떤데이타가 필요한지를 찾았으면 이제 그 데이타를 생성하기 위해서 실제로 그 데이타가 저장되어 있는 곳을 찾아내야 한다. 주로 고객사의 DBA가 그 대상이 되는데, 여러 부서가 있는 경우, 각 부서별 DBA가 필요하다. 이 사람들이 1단계에서 정의된 데이타를 생성하기 위한 원천 데이타들을 찾아줄 수 있다.

3단계. 디자인
2단계까지 진행되었으면, 어떤 데이타를 출력해야 하고, 입력데이타는 어떤것인지가 나왔다. 그러면 DW를 구축하기 위해서 실제 DW를 디자인해야 한다.
DW 디자인은 크게 DW 저장구조에 대한 디자인과, 원천 데이타 시스템으로 부터 데이타를 연계하는 것 그리고 DW부터 데이타를 추출하여 비지니스 목적에 맞게 분석 및 리포팅 하는 3단계로 이루어진다.
DW디자인은 크게 아래 3가지 패턴으로 일반적으로 디자인이 이루어지며
  • Relational online analytical processing (ROLAP)
  • Multidimensional online analytical processing (MOLAP)
  • Hybrid online analytical processing (HOLAP)
  • 데이타 연계는 ETL(Extract Transform Loading)또는 CDC(Change Data Capture)를 이용해서 이루어진다. 데이타 연계 과정은 송신 시스템을 실제로 건들여야 하기 때문에 인터페이스 테이블등의 개발이 필요하고 실제 송신 시스템의 개발이나 시스템 변형을 유발할 수 있기 때문에 기간이나 리소스 산정시에 이를 충분히 반영해야 하며, 연계 과정중 데이타에 대한 Cleansing (불필요한 데이타를 걷어내고, 데이타간의 sync 를 맞추는 작업)이 동반되어야 한다.

    DW가 구축되면 이 데이타들을 기반으로 비지니스 의사결정에 필요한 분석 및 리포트를 뽑아줘야 하는데 기존에는 IT부서들이 비지니스의 요구에 따라서 그때그때 리포트를 뽑아주는 형태였다면 현재 형태는 비지니스 부서들이 템플릿 기반으로 자신이 직접 필요한 데이타를 그때그때 뽑아보거나 (실시간성과, Self-Service), 액셀등과 같은 사용자에 친숙한 도구로 데이타를 Export하여 리포팅및 분석을 할 수 있도록 지원하며, 이에 더해서, 모바일을 통해서 장소와 시간 제약이 없이 의사결정에 필요한 데이타를 접근할 수 있도록 지원하고, 해당 리포트에 대한 접근 권한 및 열람 기록 관리 (DRM등의 보안)기능이 고려 되어야 한다.

    4단계. 구축
    디자인이 끝났으면 실제적으로 구축이 들어가야 한다. 구축 과정은 개발>Staging>Production 환경과 Infrastructure등에 대한 고민이 뒤 따라야 하며, Iterative 방식으로 개발이 완료되기 전에 어느정도 가시성(리포트를 뽑아낼 수 있는 단계)이 확보되면 비지니스쪽과 협의하여 요구사항에 충족하는지를 지속적으로 확인하면서 프로젝트를 진행해 나가야 한다.

    5단계. 반복
    구축이 완료된후에 DW는 고정된 형태로 끝나는 것이 아니라, 비지니스 환경 변화에 따라서 해당社의 DW에 대한 요구 사항도 계속해서 변해간다. 이러한 변화를 따라잡기 위해서 1~4단계를 반복하면서 비지니스와 유기적으로 연계해서 움직여야 한다.

     

    '아키텍쳐  > BI' 카테고리의 다른 글

    데이타 분석 계층 아키텍쳐  (0) 2012.10.14
    OLAP 종류  (0) 2010.05.27
    OLAP 튜토리얼  (0) 2010.05.26
    데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
    BI에 대한 링크 모음  (0) 2010.05.19
    본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

    댓글을 달아 주세요