빅데이터 관리와 분석을 위한 활용 사례 conference _ big data platform...

빅데이터 관리와 분석을 위한

플랫폼 융합 활용 사례

BI Forum

1 2012 DATABASE GRAND CONFERENCE BI Forum

분석 시스템 구축 Review(1/2)


분석 시스템 구축 Review(2/2)

정보요구사항이 변하거나

추가된다면?

데이터 량이 너무 많다면?

분석 속도가 느리다면?


과거의 빅데이터 저장

데이터 량이 너무 많다

그러나 RDBMS에서 관리하는 것은

막대한 비용 소요

지금까지의 처리방안

1. 데이터 간에 우선순위 부여

• 신용카드 데이터>상품 데이터>웹로그 데이터

• 수집하지 않거나(버리거나) 상세수준으로 저장하지 않는다

2. 데이터 시점에 우선순위 부여

• 최근 3년치만 RDBMS에 나머지는 테이프에

3. 데이터 접근 수준 차등화

• 집계 데이터만 전사 공유, 세부 데이터는 각 부서별로 보관


최근의 빅데이터 저장

RDBMS를 벗어나서 비용 부담 없고 확장성 있는 방식을 찾자!

데이터 저장 방향

그냥 모든 데이터를 (있는 그대로) 저장하자

• 원래 형태 그대로 상세수준 그대로 저장

• 문서, 동영상과 같은 비정형 데이터도 그대로 저장

가장 현실적인 대안은?

Hadoop

• Hadoop은 무료이고 필요한 머신과 SW는 저렴

• 검증된 성능 - 하둡의 최대 이용자인 야후는 5만개의 노드로 구성

된 하둡 네트워크를 배치하여 사용 중


Hadoop Review - Hadoop Framework

출처: Brian Proffitt, ITWorld

HDFS: 하둡 분산형 파일

시스템

HCatalog: 하둡 데이터용

테이블 및 스토리지 관리

서비스

Pig: 맵리듀스용 프로그래

밍 및 데이터 플로우 인터

페이스

Hive: SQL과 유사한 언어

인 HiveQL을 이용해 하둡

데이터 쿼리를 생성하는 솔

루션(DW)


Hadoop Framework - HDFS

RDBMS를 벗어나서 비용 부담 없고 확장성 있는 방식을 찾자!

HDFS?

하둡 네크워크에 연결된 아무 기기에나 데이터를 밀어넣는 분산형 파

일 시스템(Brian Proffitt)

다수의 노드로 이루어진 하둡 시스템에 데이터가 자동적으로 중복되

게 만듦. 따라서 하나의 노드에서 고장이 발생하거나 느려지더라도 여

전히 그 데이터에 접근할 수 있다

Cloudera의 제시 스펙

중간 수준의 프로세서, 4~32 GB의 메모리

각 노드에 대한 1 GbE 네트워크 연결 및 10 GbE의 탑-오브-랙(Top-

of-Rack) 스위치

하둡이 네트워크를 포화상태로 만들지 못하도록 하는 전용 스위칭 인

프라

장비당 4~12개의 드라이브 및 비 RAID 방식


Hadoop Framework – 다양성의 인식

하둡은 오픈소스 구성 요소는 모두 가변적이며 core라도 다른

SW로 대체 가능하다

아마존의 EC2(Elastic Compute Cloud)는

S3 채용

DataStax의 brisk는 하둡 배포판에서

Cassandra FS로 대체

120여종의 NoSQL 제품

Column Family DB: Hbase, Cassandra

Document DB: MongoDB, CouchDB

Key/Value DB: Scalaris, Membase

Graph DB: Neo4J, Dynomite


Hadoop 재검토

시스템 도입 책임자로서 질문

하둡 기술자를 확보할 수 있는가?

하둡 요소기술은 다양하고 계속 변화하는데 우리 IT담당자들이

계속 따라갈 수 있을까?

(중저가 라고는 하지만) 서버를 도대체 몇 대나 구매해야 하는가?

기존 RDBMS의 기능과 성능을 대체 가능한가?

정말 저렴한가? (서버 면적, 전기료, 인건비, …)


최근의 동향

Hadoop 도입 동향

IDC, 대형 포털, 클라우드 서비스 제공 기업에서는 Hadoop을

적용

일반 기업에서는 도입 사례 적으며, 특히 금융권에서는 찾아보

기 어려움

Hadoop을 전면적으로 도입하기보다는 보완적으로 도입

업계 동향

5~30테라 수준 & 빠른 속도의 Appliance

확장성 높은 RDBMS (티베로의 TMC, 100테라 이상)


빅데이터 저장 사례

사례 1

국내 Global 가전 업체

전세계 Smart TV의 프로그램(앱, 비디오) 이용 데이터 수집

(서버 로그, 서비스 로그)

전세계 기기 별 데이터의 통합

사례 2

국내 Global 게임 서비스 업체

국내서버 외에 유럽, 미주 서버에서 게임 서비스

게임 이용 통합 분석을 위한 데이터 취합

상기 사례는 현재 프로젝트 진행 중인 내용이며, 진행에 따라 내용이 변경될 수 있음


국내 Global 가전 업체 사례(1/2)

Global Public Cloud

OLAP Cube

Global Public Cloud

로그 생성 및 저장

ODS

내부 시스템

매출, 서비스

메타 정보

DW

Mart

Mart

OLAP

Reporting

http://shopping.naver.com/detail/detail.nhn?query=%EC%8A%A4%EB%A7%88%ED%8A%B8tv&cat_id=40009492&nv_mid=6225681422&frm=NVSCPRO




국내 Global 가전 업체 사례(2/2)

Why Global Public Cloud?

데이터 증가에 대한 유연한 대처

데이터 이중 백업 (다른 대륙에 위치한 IDC에 백업)

보안 위험성 낮음 (특히 DDoS)

플랫폼 변경에 유연 (Hadoop 적용, 고성능 업그레이드 등)


국내 Global 게임 서비스 업체 사례(1/3)

Global Public Cloud

Global Public Cloud

Cloud Storage

지역별 게임 서비스

데이터 (국내, 유럽,

미주)

DBMS DW /DM

Cube

HDFS

HIVE DW

DB

Log

In-Memory

DM Cube

SaaS BI

OLAP

EIS

SNS Mart

Social Analytics



Why Global Public Cloud?

Cloud 없이는 국내 서버로의 데이터 취합부터 어려움

저렴한 비용

Why Cloud BI?

유연한 라이선스

저렴한 비용

특정 제품(Tool)에 종속적이지 않음



서버 구매 방식과 비교하여 Cloud는 얼마나 저렴한가?

직접 비용

국내 데이터 규모, 5년 기준

실 서버 구매(DW용 서버와 Storage, DBMS/OS 포함)와 비교

Public Cloud 비용은 서버 구매 대비 40% 이하

기타 비용

실 서버 구매 시 추가 SW(보안, 백업 등) 구매 필요

서버설치 관련 비용(임대면적, 네트웍 공사, 전기료)

인건비(서버관리자), …

데이터 저장량이 예상보다 늘어날 경우, Cloud에서는 아주 적

은 비용으로 바로 대처 가능


기존 BI 환경과 Hadoop의 융합(1/2)

기존 RDBMS에서 하둡으로 데이터를

옮기려면?

클라우데라의 Sqoop(SQL-to-Hadoop) 툴이 대표적

JDBC 인터페이스를 통해 RDBMS의 데이터를 불러올 수 있게 함

Sqoop을 이용해 RDBMS 데이터를 곧바로 Hive DW로 불러올

수도 있음

쿼리 분석을 하려면?

Hive

하이브 쿼리언어(Hive QL)를 이용해 쿼리 수행하고 분석

주의사항: 하둡은 배치 처리 시스템이기 때문에 하이브 쿼리 시

상당한 지연이 발생할 수 있음

기존 RDB 플랫폼을 유지하면서 Hadoop을 도입하고자 할 경우


데이터저장

(HDFS)

Hadoop

ODS

(Hbase/MySQL)

DW(DM)

(Hive)

DW(DM)

(기존 RDBMS)

Source

Map/Reduce

Sqoop

BI Tool SQL

HQL

기존 BI 환경과 Hadoop의 융합(2/2)


Hadoop DW 기반 기존 BI 활용 사례

JAVA Web Service

ROLAP Report

Name node

Data node

HADOOP

HIVE HIVE

SERVER

Meta DB (MySQL)

Hive Table의 Meta정보

Cloud Local System(기존 BI System)

ODBC 또는 JDBC

Hive는 외래키가 없어서 기존 BI Tool

에서 직접 연결 시 분석 안됨

테이블 정보 입력, 가상의 기본키와 외

래키 지정 필요


과거의 빅데이터 분석

분석 속도가 느리다

사용자 분석 속도&데이터 적재 속도

모두 빠른 처리 요구 but 속도를 개선하기

보다는 분석 범위를 조정하여 처리


집계 수준 조정

• 일단위에서 주단위로, 주단위에서 월단위로 집계 수준 상향

• 분석 주제를 세분화

• 상세 분석은 특정 영역에 한정

리포트의 배치 생성

• 리포트를 조회하는 시점에서 데이터를 분석하는 것이 아니라 미

리 리포트를 생성해 놓음

• 분석이 아니라 조회 용도로 BI 활용(OLAP을 Report로 사용)


최근의 빅데이터 분석 속도 향상 방법

구 분 Appliance In-Memory

특징 장비+DBMS+OS+Storage 일체화

(전부 또는 일부) 서버 또는 클라이언트의 메모리에 데이터를 업

로드 한 후 분석

비용 매우 높음 높음

분석 매우 빠른 쿼리 조회

(10년간 제품별 평균매출금액 조회)

매우 빠른 분석 (최근 가입한 백만고객에 대해 채널별 캠페인

유형별 성과분석)

DW 구성 DW + Mart + (Cube) 구성

구성요소는 모두 물리적으로 구축

DW(Mart) 만 물리적으로 메모리에 업로드 Mart(Cube) 는 논리적으로 구성

* 규모가 작은 경우는 Raw데이터를 메모리에 업로드하고 분석모델을 모두 논리적으로 구성


Client

인메모리 플랫폼 상의 BI(1/2)

BI Server

Storage

DBMS DW /DM

Cube

HDFS

HIVE DW

In-Memory(Server)

DM Cube (Model)

OLAP

데이터 시각화

In-Memory(Client)

DM Cube (Model)

압축

압축


인메모리 플랫폼 상의 BI(2/2)

인메모리 경향

서버 인메모리, 클라이언트 인메모리 구분은 DBMS와 BI Tool에

좌우되는 경향

대부분의 시각화 Tool은 인메모리를 전제로 함

인메모리 적용 고려사항

여러 차원으로 상세 분석하는 경우 필요

정책적인 결정

인메모리 분석 대상 영역 결정 – 빠른 분석, 상세 분석이 필요한 데

이터 영역만 한정할 것인지

메모리 업로드 정책 결정 – 메모리 상주 또는 필요 시 업로드 여부


과거의 요구사항 변경 대처

분석 요건의 변경&추가

반영하기에는 너무 큰 작업. 적정

선에서 타협


분석 모델 변경이 미미한 경우

• IT담당자(유지보수 담당자)가 작업

• 작업량은 적어도 데이터의 재적재에 많은 시간이 걸릴 수 있음

• 사용자화면(리포트) 상의 오류와 이의 수정작업이 상당할 수 있음

분석 모델 변경이 필요 & 추가사항이 있는 경우

• 요구사항 정리>모델링>데이터추출/적재 전체 작업 수행

• 리포트 위주의 분석시스템인 경우 리포트 재개발까지도 감안

• 2차 개발, 고도화 등의 사업화


빅데이터 분석 변경 대처

인메모리

변경이 잦은 영역을 인메모리로 분석

해당 영역의 Raw 데이터를 메모리에 업로드

자주 변경되는 (논리적) 데이터 모델만 수정 적용

재적재(업로드) 없이 바로 수정 분석

데이터허브

가상의 데이터 통합 구조를 이용하여 필요 시 쿼리를 생성하여

결과 제공

사용자: 쿼리디자인

관리: 데이터 소스와 추출에 대한 메타정보 관리

허브: 사용자 쿼리조건을 실행 가능한 SQL로 변환/실행

메모리, 디스크 최적화, 병렬 서버 등의 기술 기반


데이터허브와 인메모리 융합 사례

In-Memory

결과

데이터 허브

추출

File

File

DM Model

데이터 소스

가공 전송

메타 관리

쿼리 디자인(Client)

쿼리 생성/실행


BI포럼의 빅데이터 플랫폼 접근 방향


BI포럼

2010년 부터 활동하고 있는 전문

중소 SW 포럼으로

지식경제부, 정보통신산업진흥원,

한국소프트웨어산업협회에서 후원

빅데이터 관리와 분석을 위한 활용 사례 conference _ big data platform...

Documents