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


Archive»


 

'아키텍쳐 /BI'에 해당되는 글 5

  1. 2012.10.14 데이타 분석 계층 아키텍쳐
  2. 2010.05.27 OLAP 종류
  3. 2010.05.26 OLAP 튜토리얼
  4. 2010.05.24 데이타 웨어하우스 프로젝트 프로세스
  5. 2010.05.19 BI에 대한 링크 모음
 

데이타 분석 계층 아키텍쳐

아키텍쳐 /BI | 2012.10.14 01:52 | Posted by 조대협

Data Analysis Layer Architecture


데이타 분석 계층에 대한 아키텍쳐를 공부하면서 간단하게 정리해서 올리기는 했습니다만, 이쪽 분야에서는 전문성이 상대적으로 떨어져서 아래 글에 잘못된 설명이 다소 있을겁니다. 특히 OLAP이나 BI 전문가 분들이 보시면 아주 초보적인 수준일텐데.. 혹시 잘못된 부분이 있다면 피드백 주시면 매우 감사하겠습니다.

일반적인 시스템들은 application server들을 중심으로 하여 클라이언트가 요청한 request에 대한 처리를 위한 구조이고, 지금 부터 설명하는 Analysis Layer는 트렌젝션 처리에 의한 결과와 로그를 분석하는 Layer이다. Anlysis Layer 또는 BSS(Business Support System) 그리고 은행에서는 정보계라는 용어를 사용한다.



전통적인 Analytics 계층은 위와 같은 모습을 갖는다.

Transaction Processing 계층에서 생성된 각종 로그와 비지니스 데이타를 Gathering 컴포넌트에서 수집한 후에, Transform 컴포넌트에서 이를 분석을 위한 저장소에 저장하기 위해서 포맷을 변경한다. 예를 들어 웹서버의 텍스트 로그를 수집해서 RDBMS에 저장한다.

분석을 위한 데이타는 이 Store 컴포넌트에 정제된 형태로 저장된 후에, 사용자가 보고 싶은 리포트 형태로 VIEW 컴포넌트에 의해서 리포트나 dash board 형태로 출력 한다.

이러한 개념적인 분석을 실제 소프트웨어 컴포넌트로 어떻게 구현할까? 여러가지 방법이 있겠지만 트렌드에 따라서 크게 아래와 같이 3가지 정도로 분리해볼 수 있다.


1. 전통적인 OLAP 방식의 분석 시스템

전통적인 기업형 업무에서는 RDBMS 기반의 분석 시스템을 사용해왔다. OLAP (OnLine Analytics Processing) 이라는 형태의 분석에 최적화된 데이타 베이스를 사용하여 데이타를 분석하여 리포트를 생성한다. 구조는 다음과 같다



  (1) ETL

ETL(Extract Transform Loading) 여러 데이타 소스로 부터 수집해서 변환 및 저장하는 역할을 한다.

E Extract의 약자로, 다양한 데이타 소스로 부터 데이타를 추출한다. 텍스트 기반의 로그 파일에서 데이타를 추출하거나, 다른 RDBMS로부터 데이타를 추출하는 기능등을 수행한다.

T Transform은 추출된 데이타를 수신 변환하는 역할을 수행하는데, 필요한 데이타만 선별 추출하거나, 필드를 합치거나 특정 룰에 따라서 데이타를 변환한다.

L Loading의 약자로, 이렇게 변환된 데이타는 수신쪽 데이타 베이스에 저장된다.


  (2) Data ware house & data mart

이렇게 데이타를 저장하는 장소를 OLAP (OnLine Analytics Processing) 형태의 데이타 베이스에 저장된다. 기업내의 모든 OLTP 시스템에서 수집된 모든 데이타는 먼저 data ware house 라는 중앙 집중화된 데이타 베이스에 저장된다. 이렇게 저장된 데이타는 리포트를 보고자하는 각 부서에 따라 다시 정제 되서 저장된다. 이렇게 각 부서별로 데이타가 저장되는 장소를 data mart라고 한다.

Data mart를 사용하는 이유가 몇가지가 있다.

부서의 업무 성격에 따라서, 테이블 구조나 데이타 베이스 구조 변경이 필요하고 이러한 구조 변경은 타 부서 업무에 영향을 줄 수 있다. 그래서 데이타베이스에 대한 변경을 자유롭게 하기 위해서 부서간에 공유되는 data ware house가 별도의 분리된 data mart를 사용한다.

또한 data warehouse에서 직접 데이타를 분석하게 되면, 부서간 리포팅 성격에 따라서 시스템에 부하를 주기 때문에 부서간의 분석 업무의 성능에 영향을 받을 수 있다.

서마다 분석 데이타에 대해서 유지해야 하는 주기가 다르다. 물론 data ware house에 데이타 저장 기간을 가장 긴 기간으로 하향 평준화하여 맞추는 방법도 있지만, 문제는 data ware house machine data mart보다 비싸다각 부서별로 데이타 저장 기간과 정책을 자유롭게 정할 수 있다.

마지막으로, 부서의 데이타 분석 스타일에 따라서 원하는 데이타 리포팅 도구를 사용할 수 있다.

물론 기업의 크기가 크지 않고, 데이타 분석을 필요로 하는 부서의 수가 그리 많지 않다면 별도의 data mart를 사용하지 않고 data ware house 하나로 데이타 저장소를 대신할 수 있다.

Data mart에 저장된 데이타는 Reporting 도구를 이용하여 업무의 특성에 맞게 적절한 분석을 통해서 가시화된 리포트로 제공된다. Reporting RBMS Join Query 등의 기능을 이용하여 구현되며, 저장된 데이타에 대해서 다차원 분석 수행한다. 다 차원 분석이란 우리가 흔히 보는 그래프 형태인데, 흔히 X,Y 값 기반의 2차원 분석이나 X,Y,Z 값 기반의 3차원등 다차원 분석을 사용한다.


2. Map & Reduce 기반의 분석 시스템

근래에 Google, Facebook 과 같은 대규모 B2C 서비스를 중심으로, 대용량 데이타의 분석에 대한 요구 사항이 생기게 되었고, 기존의 전통적인 OLAP RDBMS를 이용한 데이타 분석이 용량상의 한계로 인하여 다른 접근 방법을 사용하게 되었다. 대표적인 방법으로 Map & Reduce라는 방법을 사용한 데이타 분석 방법이다.

Map & Reduce는 프로그래밍 아키텍쳐의 개념으로, Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계(Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 


예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후그 결과를 하나로 더하면조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce 아키텍쳐의 대표적인 구현체로는 Apache 오픈소스 커뮤니티의 Hadoop이 있다.  Map & Reduce는 저가의 일반적인 하드웨어로 대용량 분석 처리를 할 수 있다는 장점을 가지고 있으나, 데이타의 수집,변환 및 분석 리포팅의 전 과정을 직접 구현해야 하는 단점을 가지고 있다. 그래서 Map & Reduce를 사용해서 데이타를 분석하는 조직은 일반적인 개발자나 시스템 엔지니어 보다는 데이타 분석에 대한 알고리즘을 만들어낼 수 있는 data scientist와 같은 특화된 데이타 분석 역할을 필요로 한다.

3. Map & Reduce + OLAP 형태의 데이타 분석 시스템

B2C 서비스를 중심으로 Map & Reduce가 데이타 분석에 대한 주류로 자리 잡게 되었고, 점점 증가하는 고객의 데이타에 대한 분석 대응 능력이 고객에게 요구 되기 시작했다. 흔히 근래에 이야기 하는 빅데이타라는 이름이 이러한 데이타 분석의 이름인데, 일반적인 기업 입장에서는 다양한 형태의 데이타 분석과 리포팅 필요하고, 주로 개발과 시스템 엔지니어를 보유한 일반적인 기업 입장에서는 일반적인 기업에서는 data scientist와 같은 역할의 사람을 고용하기가 어렵다그래서 OLAP Reporting Tool과 같이 자동화된 도구를 사용해왔는데, 이러한 RDBMS 기반의 OLAP으로는 빅데이타 분석을 위한 충분한 용량을 확보하기 어렵고 더불어 근래에 생성되는 고객의 데이타는 기업 내부의 정형화된 데이타 뿐만 아니라 Face Book, Twitter등과 같은 SNS등에서 수집되는 비 정형화된 데이타에 대한 분석이 필요하게 되었다.

그래서 Map & Reduce의 장점과 OLAP 기반의 분석을 융합한 형태의 솔루션을 벤더에서 출시하고 있다.



기존의 OLAP의 앞단에 Hadoop과 같은 Map & Reduce Framework을 붙인 형태인데, Hadoop은 정형화되지 않은 형태의 대용량 데이타를 수집하여 Map & Reduce를 이용하여 정제하고 OLAP에 저장한다. 이렇게 저장된 OLAP의 데이타는 기존의 OLAP 인프라와 프로세스를 그대로 이용하기 때문에 기업의 입장에서는 기존 OLAP 기반의 데이타 분석 구조와 인력 구조를 변경하지 않고도 빅데이타에 대해서 대응이 가능하다. 같은 DBA, 같은 OLAP Reporting 툴들을 그대로 사용할 수 있다.

여기에 하나 더해서 데이타 분석 성능을 높이기 위해서 appliance 제품을 사용하는데, appliance 제품은 소프트웨어 솔루션 뿐만 아니라 소프트웨어에 최적화된 하드웨어와 함께 패키지된 형태의 제품이다. SQL 쿼리 엔진을 하드웨어 칩으로 만들어서 서버에 장착하거나, 해당 DBMS에 대한 쿼리를 최적화 하기 위해서 DISK 구조나 IO 구조등을 최적화 해놓은 제품들이다.

대표적인 제품으로는 Oracle ExaData IBM Nettiza와 같은 제품들이 있다.



저작자 표시
신고

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

데이타 분석 계층 아키텍쳐  (0) 2012.10.14
OLAP 종류  (0) 2010.05.27
OLAP 튜토리얼  (0) 2010.05.26
데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
BI에 대한 링크 모음  (0) 2010.05.19

OLAP 종류

아키텍쳐 /BI | 2010.05.27 17:48 | Posted by 조대협

MOLAP(Multidimensional OLAP) : 다차원 데이터베이스에 기반한 OLAP 아키텍처. 다차원 데이터의 저장과 프로세싱에 MDB가 사용된다. 타 아키텍처에 비해 네트워크 상의 데이터 이동이 최소화. ⇒ 다차원 데이터의 저장과 프로세싱에 동일한 엔진이 사용
대표적인 제품 : 하이페리언 솔루션의 에스베이스, 오라클의 익스프레스, 파일롯 소프트웨어의 디시젼 서포트 등


ROLAP(Relational OLAP) : 관계형 데이터베이스에 기반한 OLAP 아키텍처. 관계형 데이터와 클라이언트 사이의 연결역할을 수행.
대표적인 제품 : 인포믹스의 메타큐브, 인포메이션 어드벤티지의 디시전 쉬이트, 마이크로스트래 티지의 DSS에이젼트 등이 있다.


DOLAP(Desktop OLAP) : 다차원 데이터의 저장 및 프로세싱이 모두 클라이언트에서 이루어지 는 데이터베이스.
장점) 타 OLAP제품에 비해 비교적 설치와 관리가 쉽고 유지 보수가 용이
단점) 필요한 데이터가 모두 클라이언트로 이동될 필요 대용량 데이터 처리에 한계
대표적인 제품 : 코그노스의 파워플레이, 브리오 테크놀러지의 브리오쿼리 등이 있다.


HOLAP(Hybrid OLAP) : 다차원 데이터의 저장 공간으로 다차원 데이터베이스와 관계형 데이터 베이스가 함께 사용될 수 있는 제품. 일반적으로 요약된 데이터나 관계식5에 의해 새로 계산된 데이터는 다차원 데이터베이스에 저 장되며, 상세데이터는 관계형 데이터베이스에 저장.
대표적인 제품 : 오라클의 익스프레스, 마이크로소프트의 SQL서버 OLAP 등이다. 

신고

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

데이타 분석 계층 아키텍쳐  (0) 2012.10.14
OLAP 종류  (0) 2010.05.27
OLAP 튜토리얼  (0) 2010.05.26
데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
BI에 대한 링크 모음  (0) 2010.05.19
TAG MOLAP, OLAP, ROLAP

OLAP 튜토리얼

아키텍쳐 /BI | 2010.05.26 16:21 | Posted by 조대협
http://www.sqlleader.com/mboard.asp?exec=view&strBoardID=SS2005SSAS&strSearchCategory=%7Cs_name%7Cs_subject%7C&intSeq=1713

MS SQL을 이용한 OLAP 강의.
한글이라서 쉽습니다.
신고

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

데이타 분석 계층 아키텍쳐  (0) 2012.10.14
OLAP 종류  (0) 2010.05.27
OLAP 튜토리얼  (0) 2010.05.26
데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
BI에 대한 링크 모음  (0) 2010.05.19
배경
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

    BI에 대한 링크 모음

    아키텍쳐 /BI | 2010.05.19 15:49 | Posted by 조대협
    BI 시장 상황 : http://blog.daum.net/tomayoon/7090507
    BI 개념 설명 : http://msbi.co.kr/16
    저작자 표시
    신고

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

    데이타 분석 계층 아키텍쳐  (0) 2012.10.14
    OLAP 종류  (0) 2010.05.27
    OLAP 튜토리얼  (0) 2010.05.26
    데이타 웨어하우스 프로젝트 프로세스  (0) 2010.05.24
    BI에 대한 링크 모음  (0) 2010.05.19