데이타 분석 계층 아키텍쳐

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와 같은 제품들이 있다.