V. 빅데이터 적용 방법론

소프트웨어의 경우 관리 방법론이 많이 제시되어 왔으나 빅데이터의 경우에는 기술이 워낙 빨리 발전해 온

관계로 전체를 일관하는 이론이 정립되어 있지 않다. 몇가지 유력한 모델과 프레임워크를 살펴본다.

1. 빅데이터 성숙 모델

빅데이터 프로젝가 일반 개발 프로젝트와 많은 공통점이 있지만 데이터 중심의 프레임워크라는 면에서 몇

가지 다른 요소가 추가적으로 적용한다. 여기서는 IDC 의 보고자료와 Sprenger 의 성숙모델을 소개한다.

(1) IDB의 빅데이터 분석 성숙모델

다음은 IDC 의 초기 자료에 제시된 그림1을 일부 수정한 것이다.

빅데이터 성숙모델

한편 이미 선진 기업에서는 객관적 데이터 분석을 중심으로 한 합리적 의사결정을 하는 조직과 그렇지

못하고 직관에 의해 움직이는 조직 사이에는 커다란 차이가 불가피한 것으로 내다보고 있다.

1 Big Data Analytics: Future Architectures, Skills and Roadmaps for the CIO. (2011/9)

2

최근 IDC 는 "Big Data and analytics (BDA) maturity model"라는 보고서를 발간하였다.2 여기서

단계를 나누고 각각의 특징을 나열하면서 요구되는 대응방안을 밝히고 있다. 여기서는 조직으로 하여금

다음 사항을 추진하도록 제반 항목을 정리하였다.

데이터분석능력과 성숙도 (BDA competency & maturity)를 분석

단기 및 중장기 목표를 향한 개선방안 수립을 위한 기준점 (baseline)을 제시한다

BDA 관련 기술, 전문인력 충원 및 기타 투자의사결정의 순위를 정함

현업부서간 또는 현업부서와 IT부서 간의 성숙도 차이 (maturity gaps)를 드러내고 해소하는 것.

이를 위해 현재 상태와 지향하는 목표 사이의 갭을 측정하고 BDA 관련 성숙도(maturity)와

수용능력(competence)을 높이기 위한 방안을 제시한다. 5 개의 stages 별로 핵심조처항목, 성과목표,

행당방안을 제시하고 있다.

IDC 의 BDA 성숙모델은 발전단계에 따라 다음의 5 가지로 분류하였다.

Stage 1 — Ad Hoc: 조직이 하나의 사업상 이슈에 대해 실험적으로 분석에 착수한다. 이때는

BDA 를 위한 전략도 없고 경영층으로부터 특별한 지원을 받지도 못하는 상태이다. 단지 기존의

기술에 의존하면서 비용절감을 위해 오픈소스 또는 클라우드 기술을 조금 활용할 뿐이다.

Stage 2 — Opportunistic: 조직이 앞서의 파일롯 프로젝트의 수행경험으로부터 교훈을 얻고

이를 새로운 사업상 요구사항에 적용한다. 이제 새로운 프로젝트에 대해서는 별도의 예산지원을

받게 되며 중간 관리자의 지원도 받을 수 있게 된다. 그러나 아직도 전사적 지원은 받지 못하는

상태이며 성과에 대한 객관적 측정기준도 가지지 못한다.

Stage 3—Repeatable: 이제 조직은 예산지원이 되는 중소규모의 BDA 프로젝트를 반복적으로

실행하며 사업본부 단위 정도에서 지원과 지휘를 받게 된다. 즉, 데이터의 수집, 감도, 통합

프로세스가 사업본부 단위에서는 발생한다. 그러나 전사적인 data governance 나 보안정책

상의 지침을 받지는 못한다. 내부직원에 더하여 외부의 전문가의 서비스도 받는 정도가 된다.

Stage 4 —Managed: 조직 자체에서 BDA 프로그램의 표준이 제정되며 여러 사업본부를

포함하는 수준의 BDA 전략도 수립되고 고위 임원으로부터 지원과 지시도 받게 된다. 전사적

성과측정 도구와 방법론이 제정되어서 투자의사결정에 영향을 주게 된다.

Stage 5— Optimized: 조직에서는 지속적이면서도 사전 조율된 전사적 BDA process

개선작업과 가치실현이 진행된다. 전사적으로 절차를 정의하는 전략지침이 만들어지고 강력한

경영진의 지원을 받는다.

2 IDC Maturity Model: Big Data and Analytics — A Guide to Unlocking Information Assets, Mar 2013 (Doc #

239771 )

3

(2) Sprenger의 데이터 성숙모델

Markus Sprenger 가 제안한 BI 관점에서의 데이터 성숙모델이다.3

가. 1단계: 적절히 이용할만한 데이터가 없다

데이터가 축적되지 않거나 아예 데이터에 대한 관리기준조차 정립되지 않은 상태이다. 오늘날 이 단계에

머무르고 있는 조직은 거의 없다.

나. 2단계: 데이터가 폭주한다

내부는 물론 외부에서도 많은 데이터가 발생하고 있지만 이를 분석해서 유용한 정보로 만들어 낼 줄은

모르는 상태이다.

특정 사안이 발생했을 때 관련 데이터를 찾는데 오랜 시간을 소모해서 정작 분석할 여유를 가지지 못한다.

정작 의사결정을 할 때는 직관에 의해서 결정을 하고 객관적 데이터가 뒷받침되지는 못한다. 따라서 전략의

수립 내지 자원의 전략적 배분에서도 합리성이 극대화되지 못한다.

무엇보다 어려운 것은 의사결정의 소재가 될 정확하고 유용한 정보의 원천을 확인하는 일이다. 여기에는

내부 데이터뿐만 아니라 외부 데이터도 포함된다. 그리고 일단 데이터 소스를 확보하였다면 이를 한 곳으로

모아서 적절하게 관리할 수 있는 장치(절차와 방법론 그리고 필요한 기기)를 구축해야 한다. 즉, 분석을 위한

기반을 구축하는 일이다.

다. 3단계: 의사결정에 유용한 데이터의 발견

이 단계에서 기업은 고급의 데이터를 이용해서 각자 올바른 데이터 모델에 적용한다. 그리고 이때 객관적

데이터를 이용하면서도 상황에 맞도록 이를 해석하고 적용할 수 있다.

전사 차원에서는 분야별 (또는 제품별, 직능별, ...)로 전사적용 분류기준 (corporate taxonomies )와

메타데이터를 이용해서 해당 데이터를 분류하고 의미있는 방식으로 해석할 줄 알게 된다.

여기서 중요한 요소는 조직 내에서 기술적용과 함께 데이터를 다루는 전반적인 문화의 확산이다. 즉,

컨텐츠를 사용하는 사람이 동시에 데이터를 생성하는 역할의 중요성을 인식하고 이들 전체를 포괄하는

시야를 가져야 한다는 점이다.

라. 4단계: 데이터를 예측에 활용

여기서는 단순히 과거 데이터 또는 지난 실적을 분석하는 데에서 한걸음 나아가 예측분석까지 수행할 수

있게 된다. 이 단계가 되어야 시장수요와 고객의 행동이 어떻게 될지를 데이터에 근거하면서도 독창적으로

3 http://www.b-eye-network.com/view/15105

4

예측할 수 있게 된다. 예컨대 제약회사나 자동차 회사에서 예측분석을 통해 대 고객 서비스의 질을

향상시키기 위한 예측모델을 수립하거나, 생산품질 향상을 위한 시뮬레이션을 올바르게 할 수 있게 된다.

마. 5단계: 데이터를 전략에 활용

여기서는 전사적인 사업모델이 분석모델에 기초하여 객관적으로 수립되며 이용된다. 즉, 과거 데이터를

활용하되 미래의 사업모델은 분석과 예측이 결합된 미래지향적인 것이 된다.

한가지 중요한 점은 그때 그때의 유행에 휩쓸리지 않기 위해서는 다양한 예측모델이 개발되고

이용되더라도 한쪽 발은 과거 데이터에 대한 분석작업이 지속적으로 추진되어야 한다는 점이다.

이처럼 분석모델, 예측모델이 하나로 통합되어 위험요소와 기회를 가급적 빨리 분류하고 대응방안을 수립

집행하도록 해야 한다.

(3). 실시간 예측분석 프레임워크

David Smith 는 데이터와 이에 대한 실시간 분석을 중심으로 하는 프레임워크를 다음과 같이 제시하고

있다. 4

4 Mike Baralow, Real-Time Big Data Analytics, O'reilly Strata, 2013 의 page 14 에서 재인용

5

위 그림에서 모든 항목의 기초가 되는 것은 데이터 계층이다. 여기에는 RDBMS, NoSQL, Hbase, Impala

등에서 관리되는 구조적 데이터, Hadoop MapReduce 중심의 비구조적 데이터, 웹, 소셜 미디어, 센서 및

운영시스템 등을 통한 스트리밍 데이터가 포함된다. 또한 기본적인 분석 작업이 이 계층에서 이루어지는

것으로 보았고 아울러 Hive, HBase, Storm 및 Spark 도 여기에 속한다고 보았다. (일부에서 저장계층과

질의처리 계층을 나누어야 한다는 의견도 있다.)

다음은 분석 계층으로서 실시간 평가 (scoring) 및 동적 분석 즉, 모델수립을 위한 개발환경이 포함된다.

이곳에는 또한 주기접으로 업데이트되는 데이터마트도 포함된다.

세번째 계층이 통합 계층으로서 최종사용자용 응용프로그램과 분석 엔진이 함께 자리하는 곳이다.

여기에는 규칙엔진 내지 CEP (complex event processing) 엔진 그리고 프로그래머와 데이터분석가

사이를 연결시켜주는 (broker) API 가 포함된다.

최 상위에는 의사결정 계층으로서 데스크 탑, 모바일, 웹 환경의 모든 응용프로그램이 자리잡고 있다.

실제로 대부분의 사용자는 의사결정 계층만을 접하게 되고 실제 분석작업 및 그 작업의 결과를 보고,

대화한다.

계층구조에 입각한 프레임워크가 가지는 의미는 각각의 계층이 고유한 특성을 가지며 계층간에 고유한

개발자, 책임자, 사용자가 있다는 것이다.

흥미로운 것은 우리가 빅데이터라고 할 때의 데이터의 크기가 계층마다 큰 차이를 가진다는 점이다.

데이터 계층에서는 peta 또는 exabyte 급의 거대 데이터가 입력된다고 가정해 보자. 이 경우에도

분석계층에서는 gaga 급을 넘어서는 경우는 흔하지 않고, 통합계층에 이르면 대상이 되는 데이터 셋의

크기는 메가바이트 급으로 줄어들며 마침내 의사결정 계층에서는 킬로바이트로 줄어들게 된다. 마치 우리

인간이 수많은 데이터와 신호에 노출되지만 이를 인지하고 최종처리될 때는 순간적 판단이 일어나듯이 계층

상으로 상향이동될수록 분석의 결과만이 전달되는 것이다.

6

2. 프로젝트 방법론

(1) 빅데이터 주요 프로세스

(2) 빅데이터 프로젝트 방법론

아래에 프로젝트 방법론이 제시되어 있다. 이와 관련하여 몇 가지 추가 사항을 아울러 제시한다.

1) Agile 기법5을 제안한다. 여기에는 Scrum 또는 Kanban 기반의 산출물 전달기법이 포함된다.

2) 소프트웨어 솔루션 그 자체의 개발프로젝트는 물론 서비스 상품에 대한 프로젝트에도 적용이 가능하다.

6

5 소프트웨어 개발방법론의 하나로서 기본적으로 "S/W 를 빨리 개발하여 업무에 적용한다는 것"이다. 기존 단계별 완성을

중시하던 폭포모델의 문제점에 대한 반성에서 출발하였다. 한편 Agile 방법론에서는 짧은 개발주기를 반복(iterate)하고 의도된

대로 진행되는지를 수시로 확인하도록 하면서 동시에 실시간 커뮤니케이션을 강조한다. 세부적으로는 다음의 방법론을 포함한다.

(1) RUP (Rational Unified Process) (2) XP (Extreme Programming) (3) SCRUM

6 이 것은 hadoopshere 에서 제시한 방법론이다. http://www.hadoopsphere.com/2012/11/delivery-methodology-for-

hadoop-projects.html Creative Commons Attribution 3.0

7

8

3. 빅데이터 로드맵

(1) 보완관계로서의 Hadoop과 DW

기존 DW 에 Hadoop 을 추가시키는 형태로 비정형 데이터를 추가시켜 분석의 범위를 넓히려는 형태이다.

(2) Hadoop을ETL/전처리 기능으로 이용

데이터를 구조화하고 저장시키는 방법론으로서 Hadoop 을 이용한다.

(3) Hadoop을 ETL 기능으로 이용

Hadoop 을 Ad-hoc query 지원기능으로 활용하려는 형태이다.

9

이외에 MapReduce 를 전제로 하되 이를 기존 DW 에서 데이터를 가져와서 처리할지 또는 기존의 DW 를

빅데이터의 HBase 나 Hive 가 완전히 대체할 수 있을가 주된 관심사이다. (이에 대하여는 다음 장에서

중점적으로 살펴 본다.)

(4) Cloud서비스로서의 빅데이터 분석

최근 빅데이터 분석서비스를 독립된 사업영역으로 보고 이를 Big Data Analytics-as-a-Service 로

제공하려는 움직임이 나타나고 있는데 그 전형적 서비스 아키텍쳐를 다음 그림에서 볼 수 있다.

10

4. Hadoop과 데이터웨어하우스

(1) 문제의식

적어도 당분간 Hadoop 이 데이터웨어하우스를 대체하기는 어려워 보인다. 그러나 Hadoop 의 가격은

물론 성능과 기능상의 이점이 워낙 커서 이미 빅데이터 도입의 문제가 플랫폼 전략의 문제가 되었고 따라서

기존 시스템과의 기능영역을 어떻게 나눌 것인가가 중요한 화두가 되었다.

(2) 양자의 비교

가. DW

DW 란 주로 의사결정에 이용하기 위해 주제별로 잘 정리하고 통합한 물리적 데이터 저장소(data

repository)이며 정형 데이터를 중심으로 다차원적 속성(cube)을 가진다. 따라서 이들 문제를 효율적으로

해결하고자 오랜기간 발전해 왔는데7 주로 다음 항목에 주력하였다.

(1) 성능문제 – DW 의 성능향상을 위해 적용된 기술은 다음과 같다.

Index 기술 - aggregate join index, cube index, sparse join index 등

cost 기반의 optimizer - DB 설계와 사용통계를 바탕으로 입력 SQL 을 검사하여 가장 효율적인

SQL 실행계획을 수립한다.

기타 - materialized view 등

(2) 데이터 통합의 문제 – 여러 소스로부터 여러 주제별 데이터를 통합하기 위한 도구가 ETL

(Extraction/Translation/ Loading) 이고 이와 함께 Metadata/data cleansing 도구를 통해 전사

공통의 언어 (common vocabulary)을 구성한다.

나. Hadoop과 전통적 DW의 비교와 장단점 분석

다음 표에서 Hadoop 을 전통적 DW 와 비교하였다.

7 I. 배경 ▶ 3. BI 와 데이터베이스 ▶ (1) BI ▶ 나. DW/OLAP 과 분석

항목 전통적 데이터웨어하우스 Ｈａｄｏｏｐ

반응의 신속성과 손쉬운

질의처리

신속한 반응 (low latency), 대화형 보고서,

OLAP 분석

Ｂａｔｃｈ 처리 중심이나 Ｐｉｇ／Ｈｉｖｅ

등을 이용하여 해결

표준 ＳＱＬ 여부 표준 ＳＱＬ 사용 ＭａｐＲｅｄｕｃｅ 프로그램 작성이 기본．

일부 자체의 질의언어 （ＨｉｖｅＱＬ 및

Ｐｉｇ） 또는 비 표준 ＳＱＬ

처리 가능한 데이터 구조적 데이터에 한하며 사전에 Ｃｕｂｅ

설계를 통해 일관성 있는 데이터 제공

주로 비구조적／Ｓｅｍｉ－ｓｔｒｕｃｔｕｒｅｄ

데이터를 대상으로 함．

동시 사용자 수 수 백 ～ 수 천명의 동시 사용자 Ｈａｄｏｏｐ만으로는 어려우나 ＨＢａｓｅ를

통해 많은 동시 사용자를 지원할 수 있음

지원 하드웨어 성능보장을 위해 통상 고성능

서버／ＨＰＣ 등을 이용

다수 저가의 서버를 클러스터로 연결．

클라우드 서비스 이용 시 서버 구입 없음．

다양한 프로그램 언어의 사용 미리 지정됨． 여러 다양한 언어 사용 가능．

데이터 관리주체 (governance)

및 보안. 규제 준수 (regulatory

compliance) 등

미리 전제되어 있고 관리 방안이 제공됨 별다른 기능이 제공되지 않음

12

항목 전통적 데이터웨어하우스 Ｈａｄｏｏｐ

무제한 (unrestricted,

ungoverned) sandbox 의 데이터

탐사

불가능 가능

임시 (provisional)데이터 분석 및

저장공간／Ａｒｃｈｉｖｅ활용

목적에 맞지 않음 활용에 적합함

처리의 단위와 범위 거래처리 (transaction) 시스템에서 record

단위로 처리 및 분석

기존 DW 에 내부/외부 데이터 소스가 추가됨.

(정형/비정형 데이터)

중앙 집중식 ｖｓ． 분산형 처리와 관리가 모두 중앙집중식 처리는 분산식이나 관리는 중앙관리

운영형태 － 정적 vs. 동적 흔히 안정된 환경에서 분석이 이루어짐．

시스템 설치 및 안정화된 후 다수 보고서 생성

지속적인 분석 (iteration)을 통해 개선.

분석작업 시 매번 전체 데이터를 적재

앞서 표에서 본 바와 같이 양자는 각각의 장단점을 가진다.

정리하자면 DW 의 한계는 다음과 같다.

기본적으로 중앙처리 집중식이어서 하드웨어 플랫폼 구축과 대형 DBMS 및 ETL, 분석도구 등의

구입 및 관리에 많은 비용이 든다.

구조적이고 정형적인 데이터 밖에 처리하지 못한다.

확장 또는 성능개선 시 또 다시 엄청난 비용이 든다.

그런데 Hadoop 은 DW 가 가진 이러한 한계와 문제점을 다음과 같이 해결해 준다.

비용이 저렴하다. 많은 도구가 오픈소스이고, 하드웨어 경우에는 저가 서버를 필요한 대로

연결하거나 클라우드 서비스를 이용할 수도 있어서 통상 전통적인 DW 에 비해 비용이 1/50 ~

1/100 에 불과한 것으로 알려져 있다.

비정형 데이터에 탁월하면서도 HBase 등을 통해 정형데이터 처리가 가능해졌다.

Hadoop 는 저장능력, 분석능력이 탁월하다.

그러나 Hadoop 내지 MapReduce 역시 문제점이 없지 않다.

Hadoop 이 확장성이 좋기는 하지만 MapReduce 이용은 Batch 처리 중심이다.

수 많은 job 의 관리 가정에서 복잡한 pipeline 이 형성되며 많은 중간산출물 (intermediate

data)이 발생한다.

HDFS 에서의 local read 작업을 위해서는 mapper 작성이 필수적이다.

아직 사용자 편의를 위한 도구가 완전치 않으며 상당부분을 사용자 측에서 직접 처리해야 한다.

(소위 DIY mindset)

물론 기존의 DW 측에서는 MapReduce 기능을 적극 수용하고 있고 Hadoop 측에서도 SQL 의 적용이나

Hive, Pig 등을 통해 MapReduce 프로그래밍 없이 Hadoop 의 데이터를 손쉽게 분석할 수 있도록 하는

여러 방안을 제시하고는 있다. 그러나 본격적인 EDW (Enterprise DW)의 구축을 Hadoop 등의 빅데이터

솔루션만으로 구축하기에는 아직 완전치가 않은 것이 사실이다.

못지 않게 중요한 점은 아무리 Hadoop 시스템이 좋은 기능을 가지고 있어도 기존 시스템을 급격히 새

시스템으로 전환하는 것에는 많은 위험이 수반된다는 점이다.

결론적으로 양자의 기능이 상당부분 겹치면서도 또한 여전히 각자 고유의 영역과 특장점을 가진다는 점을

감안할 때 이들을 아우르는 공존 전략이 필요한 것으로 보인다.

14

(3) 공존 전략 – 최소한의 Hadoop DW

Hadoop 과 DW 는 조직 내 정보의 흐름 (supply-chain) 속에서 각각 나름의 역할을 하면서 공존할

것으로 보여진다. 편의상 Hadoop 이 DW 관련하여 맡을 영역과 활용방안을 Hadoop DW (Hadoop Data

Warehouse)라 명명하자.

가. 임시 데이터 준비 장소로서의 Hadoop

우선 임시데이터의 운영에 Hadoop 이 적합하다. 즉, 작업을 수행하다 보면 DW 에 적합하지 않은 임시의

데이터 집합(provisional data set)이 생기는데 이런 형태의 데이터는 다른 데이터와 연결되지 않고 고립된

형태로 분석을 하는 경우가 많다. 이는 Hadoop 이 적합한데 다음과 같은 것이 대표적 예이다.

인터넷 주소 (URL), 웹 페이지 등에 대한 검색 index 프로그램 및 과학/천체/기상데이터 등의

처리

crawler 를 이용한 수집 데이터는 웹 페이지가 거의 매 순간마다 내용이 수정되는 경우가

대부분이므로 이를 임시 데이터로 보는 것이 타당하다.

조직간 합병이 이루어질 때 각 사에서 운영중이던 데이터 (예: 고객데이터)를 임시 저장형태로

활용하는 경우.

이 경우 Hadoop 은 기존 DW 에 비해 유연성이 높고, 신속한 구축과 적용이 가능하다는 장점이 있다.

반면에 DW 는 데이터와 데이터 모델의 표준화에는 유리하지만 위와 같은 임시 데이터의 저장과 처리에는

적합하지 않다.

나. DW를 위한 데이터의 사전 정제작업

Hadoop 으로 하여금 원 데이터 (raw data)에 대한 데이터 저장소 역할과 함께 이에 대한 1 차 가공 (또는

정제 refiney)의 역할까지 맡게 하고 그 결과물을 DW 에 올리도록 한다.

여기서 저장소란 방대한 데이터를 HDFS 에 고속으로 저장, 축적함으로써 매우 성능이 높으면서도 유연한

시스템을 구축하는 것을 의미한다. 매일 수십~수백 TB 는 손쉽게 모을 수 있고 뿐만 아니라 데이터 폭주

시에도 손쉽게 시스템을 늘리거나 줄일 수 있기 때문이다. 특히 SAN 을 이용하지 않고 로컬 스토리지에

저장하기 때문에 효율이 좋고 네트워크에 부담을 주지 않는다.

15

한편 정제란 Hadoop 로 하여금 다기능 ETL (소위 "ETL engine on steroids")의 역할을 하게 하는

것으로서 결과적으로 기존의 값비싼 ETL 제품의 구입부담이나 또는 수작업으로 처리해야 하는 부담을 줄일

수 있다. 8

Hadoop 을 이처럼 사용하는 대표적 예는 다음과 같다.

로그 (log) 관리: 그동안 무시하고, 회피하고 버리던 것을 적극 활용한다. 로그 데이터는 각종

기기의 경우에 보안, 성능관리 등에 있어 귀중한 정보를 제공하며 웹로그 경우에는 long tail

분석과 SNS 의 활성화에 대응하여 모든 고객을 중요하게 다룰 수 있게 되었기 때문이다.

신규 서비스의 준비: 예컨대 상거래 사이트 회사에서 제품별 이미지를 분류. 패턴인식과 분류와

결합하여 차원 높은 서비스를 할 수 있게 된다.

DW 의 정제(Refinery) 역할은 뒤에서 조금 더 자세히 기술키로 한다.

다. 아카이빙 솔루션으로서의 Hadoop

Hadoop 이 저가의 데이터 저장소 (storage repository) 내지 아카이브 (archive)의 역할을 하게 하는

것이다. 특히 아카이브의 대표주자인 tape 는 데이터 인출(retrieve)이 불편하고 시간 경과에 따라 품질

손상이 매우 컸다.

이제는 과거 데이터를 축적하고 이용하는 것이 더욱 더 중요해졌고 또한 용이해졌다. 검색 기술의 발전은

수 천 개의 디스크를 Hadoop 으로 관리, 검색하는 것을 가능하게 만들었고 많은 데이터를 지하창고에

묻어두거나 버리는 대신 Hadoop 을 통해 신속히 이용할 수 있게 되었다. 이러한 방식의 이용패턴은 이제

Hadoop storage grid 라는 또다른 응용분야를 탄생시키고 있다.

한편 여기서 한걸음 나아가 일종의 기존 DW 의 가치를 높이는 "Active Archive"를 제안하기도 한다. 일부

통계에서는 기존 데이터 중 테이블의 85%, column 기준으로는 50%가 실제로는 활용되지 못하고 있는데

Hadoop 이 이를 실제 분석에 사용할 수 있게 해 준다는 것이다.

(4) Hadoop의 DW 적용 패턴

Hadoop 의 DW 이용 패턴 중 일반화된 것을 소개한다.9

8 최근 ETL 과 ELT 에 대한 논의가 활발하다. 말 그대로 Extraction 과 Loading 의 순서에 대한 것이다. 여기서 ELT 는

데이터 변환을 Hadoop 으로 이관해서 DW 의 부담을 줄일 수 있다는 것이었는데 이로써 Hadoop 은 DW 의 데이터 부담을 덜기

위한 "back end"의 역할과 함께 변환(transformation) 처리의 "전위(front end)" 역할을 담당하게 된다.

9 Hortonworks, Apache Hadoop Patterns of Use, April 2013.

http://hortonworks.com/wp-

content/uploads/downloads/2013/04/Hortonworks.ApacheHadoopPatternsOfUse.v1.0.pdf

16

가. 유형1: 데이터 정제 (Refinery)의 역할

데이터 정제란 새로운 데이터 소스를 기존 BI 또는 분석 시스템으로 합류시키 것으로서 예컨대 ERP,

CRM 등의 기본적 고객정보에 추가하여 홈페이지 방문 및 SNS 정보도 적극 활용하기 위해 다음 작업을

추가한다.

데이터 획득(capture): 모든 데이터를 획득하는 작업

처리(process): 파싱(parse), 정제 및 구조화 및 변환작업

교환(exchange): 기존 DW 은 기존 분석도구를 이용하도록 함

나. 유형 2: 데이터 실험 (Exploration)에 사용

데이터 실험 (Exploration)에서는 새로운 대량 데이터를 hadoop 에 저장한 후 각종의 데이터 탐사작업을

실시한다. 즉, Hadoop 을 Refinery 경우처럼 단순히 임시장소 (staging area)로 사용하는 것이 아니라

데이터를 Hadoop 에 둔 채로 직접 탐사분석을 하게 한다. 즉, 데이터를 수집하고 반복적으로

검토(investigate)하여 가치있는 정보를 추출한다.

데이터 획득

처리: parse, 정제 및 구조화 시도 및 변환

교환: Hadoop 을 지원하는 분석도구를 이용해서 탐구하고 곧바로 시각화 처리

이는 과거 포기해오던 데이터 (예: web log, SNS 관련 데이터 등)를 수집하고 새로운 응용프로그램을

이용하여 분석, 활용함을 의미한다.

17

다. 유형 3: 응용프로그램 보강

응용 프로그램 보강 (Application Enrichment)에서는 Hadoop 에 저장된 데이터를 활용하여 새로운 가치

창출하고자 한다. 예를 들어 모든 사용자의 모든 web 세션 데이터를 저장하고 이를 분석함으로써 각각의

사용자가 사이트에 방문할 때 그 사용패턴에 기반하여 고객에게 서비스하고 적시에 가능한 새로운 제안하는

등이 그것이다.

(5) Hadoop DW개발동향 – SQL on Hadoop

당초 예상과는 달리 Hive 와 HiveQL 의 처리속도가 일단 데이터베이스의 SQL 처리에 비해 크게 개선되지

못하고 있다. 이는 HiveQL 을 다시 MapReduce 로 번역하여 실행해야 하는 특성에 따른 것으로 쉽게

개선되기는 어려울 것으로 보인다.

반면 전산전문가 특히 MapReduce 프로그래머가 아닌 일반 현업 담당자 또는 분석가의 경우에는 SQL 에

준하는 편리성과 신속한 반응을 기대하고 있다. Hive 가 MapReuce 프로그래밍을 대신한다고는 해도

대용량 데이터를 실시간으로 즉, SQL 에 준하는 정도로 해결책을 제공하지는 못하기 때문이다.

이에 따라 Hadoop 플랫폼과 SQL 을 결합하려는 쪽으로 관심이 모아지고 있는데 그 예가 다음과 같은

프로젝트의 진행이다.

Facebook 의 Presto: Hadoop DW 에 대한 실시간 query 엔진의 개발.

Amazon 의 웹 서비스로서의 RedShift. .

HortonWork 의 Stinger initiative: Hive 를 100 배 더 빠르게 하겠다는 목표를 제시.

IBM 의 BigSQL: SQL query 엔진을 HDFS 위에서 수행하되 MapReduce 를 경유치 않고 직접

수행하게 하며 Transaction 처리는 HBase 를 이용하도록 한다.

Cloudera 의 Impala: Hadoop 에 대한 실시간 ad-hoc query 인터페이스

Tajo: 아직은 Apache 의 예비 (incubation) 프로젝트로서 HDFS 위에서 독립적인 query

engine 을 통해 표준 SQL 을 지원하려는 것

이들 각 프로젝트의 세부사항은 Hadoop 이 엔터프라이즈 시장에 진출하는 관건으로서 매우 중요하므로

진행상황을 지속적으로 점검해야 할 것으로 생각된다.

(6) 결론 - 보충논의

위의 사항에 추가하여 다음 항목들이 아울러 검토되어야 할 것이다.

Hadoop 이외에 Hive, HBase 등 관련 프로젝트를 세밀히 검토할 필요가 있다. 이들이 유기적인

생태계를 구성하면서도 DW 에 관한 한 별도의 추가적 해답을 제시하기 때문이다.

18

제품 이외의 사용자 skill 교육 등 인적자원 문제도 중요하다. 기술도 결국은 사람의 문제로

귀결되기 때문이다.

현업의 요구사항이 의사결정에 결정적으로 중요하다. 따라서 전산과 현업의 활발한 협의가

필요하다. 모든 원동력은 최종 사용자의 문제해결 요구에서 나오기 때문이다.

한편 Hadoop DW 를 구축하는 것은 Hadoop 만으로 부족하다. 기간업무 (mission-critical) 적용을 위해

다음 사항이 고려되어야 한다.

고 가용성 보장을 위해 취약점(single points of failure)을 제거하고 데이터 보안을 강화한다.

이를 위해 snapshots 과 재난복구를 위한 원격 mirroring 기능을 검토할 만 하다.

한편 Hadoop 은 대용량 데이터의 생애주기상 맨 앞부분과 맨 뒷부분에 적합하다. 맨 앞부분이란

데이터가 획득되어 전처리 되는 부분을 말하며 뒷부분이란 데이터를 사용 후 퇴출 (retire)시키는

- 그러나 다시 필요할 수 있는 – 것을 말한다.

신기술 동향을 주시할 필요가 있다. 앞서 언급된 바 있는 Apache 프로젝트는 물로 수 많은

성공사례와 그 동향을 모니터링 할 필요가 있다.

결론적으로 DW 에 관련된 Hadoop 의 역할이 급속히 바뀌고 있다. 처음에는 Hadoop 은 ETL 처리를 위한

임시 플랫폼으로서 DW 의 처리능력과 데이터 변환 기능의 부담을 덜어주는 정도의 보조적 기능을

담당했지만 Hadoop 의 총소유비용이 기존 DW 의 1/50 에 불과하고 기존 DW 가 하지 못하던 새 기능을

제시하고 있다.

다른 측면으로는 검색엔진을 위한 Batch 방식의 대규모 데이터 처리라는 Hadoop 의 탄생배경에 의해 때

Hadoop 의 주된 위치가 단기적으로는 DW 의 front-end 와 back end 에 한정될 가능성도 있다. 그러면서

궁극적으로는 “전사데이터의 분석을 위한 중심역할”10로 한걸음씩 나아갈 것으로 예상된다.

10 “an enterprise data management hub in a multi-platform data analytics” 이는 BI 및 DW 교육기관인 tdwi 의 논문에

기술된 용어로서 Hadoop 의 궁극적 목표를 잘 설명하는 것으로 생각되어 인용한다.

19

5. 클라우드 컴퓨팅과 빅데이터

(1) 개요

클라우드 컴퓨팅이란 네트워크 (인터넷)을 통해 컴퓨터 자원을 서비스로서 제공하는 것을 말한다.

사용자입장에서는 초기 인프라 투자비용을 피하고 사업의 진행현황에 맞추어 가변비용으로 대체할 수

있다는 잇점이 있다.

(2) Cloud서비스로서의 빅데이터 분석

최근 빅데이터 분석서비스를 독립된 사업영역으로 보고 이를 Big Data Analytics-as-a-Service 로

제공하려는 움직임이 나타나고 있는데 그 전형적 서비스 아키텍쳐를 다음 그림에서 볼 수 있다.

(3) 빅데이터 플랫폼으로서의 클라우드 서비스

빅데이터를 이용할 때 저가 서버를 기준으로 수 십대만 동원해도 적지 않은 비용이 든다. 거기다

운영체제/DBMS/DW 및 개발도구 등을 설치하고 클러스터 관리를 하려면 인원과 시간소요가 만만치 않다.

이 경우 클라우드 서비스를 이용하면 편리하다. 예컨대 3 개월 예정의 pilot 개발 후 효과가 입증될 때 이를

확산한다면 클라우드 서비스를 통해 월정 비용으로 수행한 후 정식설치 여부를 판단할 수 있다. 이하에서

Amazon 과 KTCloudware 등에 대해 살펴본다.11

11 특정 업체의 소개목적이 아니며 업체별 상품의 변화가 있을 수 있음.

20

가. Amazon의 경우

Amazon Web Service 에서는 12 다음과 같은 서비스를 제공한다.

EC2 (Elastic Computing Cloud) - 컴퓨팅 파워를 제공받는 것

SQS (Simple Queue Service)

S3 (Simple Storage Service) - 일종의 웹 하드

빅데이터의 경우 특히 Elastic MapReduce 라는 서비스 상품으로 제공되며13 서버 이미지를 AMI

(Amazon Machine Image)라는 일종의 가상서버의 daemon 형태로 이용하게 되며 이러한 인스턴스

유형에 대해 웹 서비스 API 및 관리도구를 사용하는 형식으로 이용하게 된다. Amazon 의 장점은 세계

각지에 균질한 서비스가 제공된다는 점이다. 현재 9 개 Region 과 39 개 Edge Location 을 가지는데

최근(2013 년) 한국에 Edge Location 이 구축된 바 있다. 14

나. KTCloudware와 ucloud biz의 예15

일종의 커스토마이즈 된 빅데이터 플랫폼을 제공한다.

NDAP (NexR Data Analysis Platform) - Hadoop 중심의 플랫폼

RHive - Hadoop + R + Hive의 플랫폼

12 http://aws.amazon.com/ko 참조

13 http://aws.amazon.com/ko/elasticmapreduce/ 참조

14 Edge Location 은 일종의 POP (Point-of-Presence)으로서 글로벌망의 접속점 역할을 한다.

15 www.ktcloudware.com 와 http://ucloudbiz.olleh.com

21

VI. 빅데이터 – 결론에 대신하여

MapReduce 가 발표된 지 10 년 남짓만에 큰 발전을 거두었지만 앞으로 더 큰 발전이 기대된다. 결론에

대신하여 몇가지 짚어보고자 한다.

첫째 Hadoop 프로젝트 자체의 발전이다. 예컨대 MapReduce 는 hadoop-0.23 에서 대대적인 수술을

단행했는데 MapReduce 2.0 으로서의 YARN 이 그것이다. 핵심은 JobTracker 의 주된 기능인 자원관리와

Job Scheduling/ Monigoring 을 2 개 데몬으로 나누고 글로벌 자원관리자 (global resource manager)와

애플리케이션 별 관리자인 ApplicationMaster(AM)을 두자는 것이다.

이를 통해 기존 MapReduce 와의 호환성을 유지하면서도 확장성과 cluster 활용이 크게 늘어남은 물론

MapReduce 가 사용자 라이브러리화 하여 안정성이 높아지고 기능추가도 용이해졌다. 요컨대

MapReduce 가 특별한 한 영역이라기 보다 분산컴퓨팅이라는 이름으로 전반적인 컴퓨팅에서 주도적 위치를

차지하는 현상이 지속될 것이다.

한편 1999 년부터 시작된 Apache 프로젝트는 이미 top-level 프로젝트만 100 개를 훨씬 뛰어 넘었다.

그리고 이들 모두가 빅데이터 관련이라고는 할 수 없지만 거의 대부분이 직간접으로 관련맺으면서 엄청난

시너지를 내고 있다. 대표적인 것에 다음과 같은 것이 있다.

Java 개발도구 (Maven 등 10여 프로젝트)

데이터베이스 관련 (Cassandra, lucene 등 약 20개 프로젝트)

Library (Avro등 50여개 프로젝트)

XML (Cocoon등 30여개 프로젝트) 등등

이들은 이미 엄청난 생태계를 이루어 enterprise 시장을 주도하고 있고 앞으로 가속화할 것이다.

한걸음 더 나아가 Hadoop 자체와 Apache 프로젝트를 뛰어넘는 오픈소스 생태계를 생각지 않을 수 없다.

다음 그림은 이제 도약을 시작한 생태계 모습의 일부를 보여주고 있다.

22

이들 대부분은 MapReduce 프레임워크를 전제로 한 상태에서 이를 둘러싼 개별적 stack 에 대한

솔루션을 제시하고 있음을 알 수 있다.

둘째, MapReduce 는 하나의 프레임워크 내지 컴퓨팅 파라다임이다. 따라서 프로그램으로 구현 시 대상

업무에 따라 여러 가지로 다르게 설계될 수가 있게 되고 이에 따라 성능이나 결과도출에 큰 차이가 발생하게

된다. 이런 점에서 최근 정형적인 디자인 패턴(Design Pattern)을 빅데이터에 응용하여 MapReduce

프레임워크에 유용한 디자인 패턴을 발굴해 내거나16 또는 SOA (Service Oriented Architecture)에

빅데이터를 접목하려는 노력을 기울이는 것은 당연한 현상으로 보인다.

세째, 빅데이터와 데이터웨어하우스의 관계도 관심의 촛점이다. 당초 Hadoop 은 DW 와 별개로

시작되었지만 Hadoop 의 성공과 함께 운영 안정성, 보안 등이 보완되고 Hive, HBase 등의 데이터 스토어와

SQL 류의 질의어 처리기술이 추가되자 DW 에 직접적 경쟁자로 등장하게 되었다. 당초 DW 로서는 단순히

Hadoop 을 자신의 기능확장 정도로 생각했지만 오픈소스로서의 Hadoop 이 DW 를 넘보게 되자 치열하게

경쟁하는 관계가 된 것이다.

넷째, 기술편향의 극복이다. 빅데이터 기술이 성숙단계에 이를수록 더욱 서비스화할 것인데 (예: Big

Data-as-a-Service) 어느 경우이든 현업지식의 이해와 의사소통하는 능력이 중요해진다. 이런 의미에서

data scientist 에게 필요한 덕목 중 하나로 story-telling 능력을 들기도 한다.17 즉, hidden insight 를

찾아내고 직접 행동에 옮길 수 있는 진실(actionable insight)을 파헤친다.

다섯째 한걸음 나아가 빅데이터는 MapReduce 기술 이상의 비즈니스 모델로 자리잡고 있다. 사업모델

측면에서 기업의 의사결정의 실시간화를 통해 과거 생각할 수 없던 혁신이 이루어지는 것이다.

16 예컨대 Miner & Shook, MapReduce Design Patterns, O'reilly, 2013

17 Havard Business Review (Blog), March 2013

23

진부한 얘기지만 기술측면에서의 개방모형도 주목할만 하다. 이제 도구가 아니라 조직지능과 혁신 그

자체가 중심이 되었고 개방형 참여모델을 통해 오픈소스는 기술혁신의 중심 축이 되었다. 기업과 조직이

이를 어떻게 활용하고 참여하는가가 핵심적 중요사항이 되었다.

여섯째, 데이터 중심의 과학적 사고이다. 일종의 value shift 라고 하겠는데 물리적 사물 이외에도 보이지

않고 만질 수 없는 모든 것에서 가치를 찾을 수 있다는 것이다. 특히 데이터가 복잡하고 방대할 때 사람은

의사결정을 할 수 없는 경우가 많다. 이 경우에는 기계를 통해서만 올바른 의사결정이 가능하다.

다음의 문장들은 이러한 객관적 데이터 중시의 한 표현이라 하겠다.

Let the data speak. – 데이터 그 자체가 진실을 말하게 하라!

Datafication – 이 세상 만물에서 정보를 얻을 수 있다. 합리적 측정기준만 설정한다면 과거에는

데이터라고 생각지 못했던 것에서도 그 의미와 정보를 추출할 수 있다.

humanize the data – 데이터를 인간화하라. 데이터를 해석하고 실천 가능하도록 스토리화 하는

것이 중요하다.

From Some to all – 데이터가 있다면 왜 일부분만 가지고 불완전한 의사결정을 하는가? 모든

데이터를 전부 이용하라. 소위 Sampling loses detail! Get everything: N = all

끝으로 빼 놓을 수 없는 건 데이터도 중요하지만 데이터의 질(quality)은 더욱 중요하다는 점이다.

“big garbage data in, big garbage data out.”로 표현되듯이 데이터 품질관리를 위한 전처리 기법과

기준정보관리 (MDM: Master Data Management) 및 메타데이터 관리의 중요성이 더욱 강조되고 있다.