빅 데이터 기술현황과 시장전망

윤석찬

channyun

목차

• 데이터 폭증과 빅데이터 – 글로벌 데이터의 증가 추세와 빅데이터의 등장

• 빅데이터 기술 현황 – Hadoop / NoSQL

– 실시간 분석

– SQL on Hadoop

• 새로운 기술 동향 – Spark

– Hadoop 2.0 및 Yarn

– 클라우드 기반 분석 플랫폼

• 기술 활용 프랙티스

웹 2.0 및 소셜웹의 성장

• 웹 2.0: Platform as a Web – 데이터와 API를 통한 다양한 서비스 증가

– 오픈 API 플랫폼의 및 As-a-Service의 증가

• API Billion Club의 탄생

© programmableweb, 2012

모바일을 통한 데이터 폭증 시대

웹서비스 비교 빅데이터

1990년대 시기 2010년대

X86급 서버 장비 중형급

상용 유닉스 잠식 시장 DW(데이터웨어하우징)

Redhat 대표 회사 Cloudera

리눅스 토발즈 대표 영웅 더그 커팅

Linux 소프트웨어 Hadoop

인터넷 포털 웹 스타트업

혁신 주체 소셜네트워크 모바일

저렴한 웹서버 구축 변화 요인 저렴한 데이터 분석

–빅데이터와 웹 서비스 열풍 비교도 © Channy’s Blog

빅 데이터 열풍!

@mdennis, datastax

데이터 폭증 시대의 두 가지 문제

빅 데이터란?

다양한 빅데이터 기술

분석 도구

비관계형(Non-releational) 관계형(Relational)

Teradata IBM InfoSphere

Aster HP Vertica

EMC SAP Hana Oracle

Greenplum SAP

Oracle IBMDB2 SQLServer 운영 도구

NoSQL

키/값

Redis

Membrain

BerkeleyDB 빅테이블

HyperTable

Hbase

문서기반

CouchDB

MongoDB

그래프

FlockDB

Neo4j

NewSQL

Drizzle

MySQL Cluster

NimbusDB

ScaleBase

VoltDB

Data as a Service

AppEngine Amazon RDS

SimpleDB SQL Azure

실시간 Storm/Shark

Apache S4/Kafka

Apache Drill

Apache Tazo

Hadoop

Horton

Cloudera

MapR

Intel/EMC

Cloudera Impala

Google BigQuery

시각화

D3

Pentaho

CouchBase

Cassandra

Modified © Inforchimps. 2012

Input

1. Hadoop 기술 batch analytics

…

…

Output

…

MA

P

RE

DU

CE

복잡한 문제를 작은 문제로 쪼갠다

문제를 여러 서버에 나누어서 해결한다

결과를 모아서 합친다

Why Hadoop?

• 데이터 분석을 위한 오픈 소스 스택 제공 가능

© Cloudera, 2012

Hadoop 기반 로그 분석 사례

• 일 로그 사이즈 70TB

• Daum 서비스 내 발생하는 모든 트래픽을 수집하여 분석 및 리포팅 – 주요 분석 데이터: Pageview, Clickstream, User

Analysis

• 데이터 처리 스택 – Hadoop: 데이터 전처리

– Hive (UDF, M/R): SQL 기반 데이터 분석

– Pentaho Kettle (ETL): 데이터 저장

– Greenplum: 병렬 데이터베이스

• 기존방식에 비해 데이터 처리 속도 향상 및 데이터 적재기간 증가

적용 결과

• 더 빠른 분석 (10분 단위 실시간 로그 확인 가능)

• 더 쉬운 분석 (Hive) selelct serviceId, count(distinct uuid)

from web_log

where dt='20120101' group by serviceId

고객 분석 일 로그 분석

Hadoop 도입 전

Hadoop 도입 후

Hadoop의 장단점

• 장점 : 기존 분석 기술에 비해 저렴하게 데이터 분석 가능 – 데이터를 바라 보는 관점의 차이 (저렴한 처리 비용)

– 샘플링이 필요 없음 (대용량 처리 가능)

– 운영 비용이 적음 (인프라 운영이 관리 가능)

– 분석도구나 프로그래밍 언어에 독립적임

– 다양한 개발 도구 (오픈 소스 지원)

• 단점: 분석 방식의 변화 및 내재화 비용 – 개념의 변화가 필요 (Map/Reduce식 사고 전환 필요)

– Hadoop은 진화 중(벤더 배포판 사용 기회 늘어남)

– 아직 구현되지 않은 부분이 많음(버전 호환성이 낮은 편)

– 장애에 대한 대비 필요(메모리 및 네트웍 관련 시행착오)

– 실시간 분석에 대한 필요성 (대안 기술 선택적 사용)

2. NoSQL 활용 not only SQL

• 대용량 데이터 업데이트 및 조회 시, 기존 RDBMS에 비해 빠른 성능 제공

• 구조가 간단한 대량 이벤트 및 로그 데이터 저장 및 조회 시 유용

© Yahoo! Research. 2010

아고라 대량 데이터 수집 사례

• 마이아고라는? – 토론, 청원, 즐보드 등 아고라의

모든 글을 모아서 제공

– 총 데이터 6천만건 (2012.1)

• 문제점 – 짧은 시간에 너무 많은 데이터가

추가 되고 있음

• 해결 방법 – 데이터 입력 시간이 훨씬 짧은

NoSQL 솔루션 도입

Select Insert Update Delete

MySQL 355sec 250sec 317sec 310sec

MongoDB 294sec 60sec 153sec 123sec <1백만건 MySQL과 MongoDB 데이터 처리 실험 결과>

NoSQL의 장단점

• 장점: 빠르고 유연한 데이터 저장 및 조회 능력

– 데이터가 증가함에 따라서 노드의 갯수만 늘리면 됨(확장성과 가용성)

– Key-Value 형식으로 저장하므로 유연한 데이터 구조(Schemaless)

– 데이터 인덱싱으로 빠른 응답 가능(고성능)장점 : 기존 분석 기술에 비해 저렴하게 데이터 분석 가능

• 단점: 분석 방식의 변화 및 내재화 비용 – 스키마 설계, 서버 네트워크 구성, 메모리/IO 등에 시행착오

– 데이터 무결성(integrity)을 위한 처리 비용이 큼

• 트랜잭션과 같은 복잡한 처리에 적합하지 않음

• 장애시 데이터 복구에 드는 노력이 많이 듦

– Schemaless라서 Join 과 같은 복잡한 쿼리 사용 어려움 • MongoDB 같은 경우, 빠른 인덱싱 및 SQL 친화적인 지원 가능

3. 실시간 분석 기술 이벤트 데이터 분석

• 분석에 포함 되지 못하는 실시간 데이터 파악 오픈소스 기술명

구현 방식 구현 언어 문서화 즉시 Rule 추가 기능

성숙도 커뮤니티

Scale-up 방식

Esper 선언적 SQL Like Java 매우 좋음 가능 높음 중간

Droools Fusion

선언적 SQL Like 및 Rule

Java 좋음 가능 높음 작음

Scale-out 방식

Storm Job 설계 Cloujure 있음 Zoopkeeper 이용

중간 빠르게 성장중

Apache S4 Job 설계 Java 평균 Zoopkeeper 이용

낮음 중간

Apache Kafka

Job 설계 Java 좋음 Zoopkeeper 이용

중간 작음

김병곤(2013), 데이터를 실시간으로 모아서 처리하는 다양한 기법

http://www.youtube.com/watch?v=HmVegCGWbsU

• 실시간 분석의 어려움 – Hadoop은 배치(Batch) 처리 방식이라 실시간에 적합하지 않음

– NoSQL은 데이터 저장만 빠르지 분석 데이터를 걸러내기 어려움

• 실시간 분석 엔진의 등장 (Storm이 대표적)

– 트위터에서 직접 개발해서 오픈소스화

– Data Stream을 바라보고 실시간으로 데이터를 바라보는 로직을 구현

– 로직(Topology)를 Storm Cluster로 던지면 적절히 실행해서 분석

Spout Bolt

Data Stream NoSQL

Node.js Data Stream

실시간 분석이 필요할 때…

• 활용 대상 영역 – 쇼핑몰 사이트의 사용자 클릭 스트림을 통해 실시간 개인화

– 사용자 위치 정보 기반 광고 및 추천 기능

– 시스템 이벤트를 이용한 실시간 보안 감시

– 차량 추적 및 위치 정보 수집을 이용한 도로 교통 상황 파악

– 사용자의 액션 수집을 이용한 이상 행위 탐지

• 기획자의 요구 사항 – 데이터가 변화되는 모습을 화면에서 바로 보고 싶다!

– 간결한 차트와 선택 및 실시간 변화를 보고 싶다!

• 기술 요구 사항 – 로그 수집, 실시간 분석 및 장기 분석을 위한 저장소 필요

– 주기적 차트 생성 및 쿼리에 대한 브라우저 기반 기능도 구현 필요

미디어 다음 실시간 로그 수집 사례

• 미디어 콘텐츠에 대한 실시간 현황 파악 – ‘나는가수다’, ‘K팝스타’ 같은 특정 콘텐츠(디지털 브랜드)에 대한 변

화 측정 필요

– 이벤트 및 이슈에 대한 실시간 상황 파악을 위한 관리 도구 제공

Storm을 이용한 분석 순서

실시간 분석 구축 시 유의 사항

• 정말 필요한가? – Storm/S4 같은 기술을 도입하기 전에 정말 필요한지 확인해야함

– 실시간 분석은 빅데이터 분석의 일부분이며, 명확한 업무 정의가 된 경우에만 수행 해야 함

– Batch/Query/Realtime에 대한 이해 파악 필요

• 고난을 각오해라! – 잘 알려진 케이스는 많으나 실제로 구현하다 보면 어려움 봉착

– 시스템 엔지니어링 운영 기술 및 대용량 메모리(~98GB) 기반 서버팜 등이 필요함

• 역시 오픈 소스! – 오픈 소스 커뮤니티의 규모와 문서화 케이스 등으로 지원 가능한지

확인 후에 진입하는 것이 좋다.

4. SQL on Hadoop

• 분석 전처리 작업 없이 데이터 현황 파악 필요 시 – 인메모리/파일 기반 분산 기술을 활용한 쿼리 엔진

– Map/Reduce를 사용할 필요가 없는 질의 조건일 때 활용

• 주요 오픈 소스 기술 – Impala: Cloudera Hadoop 배포판 및 HiveQL 호환

– Apache Tajo: HDFS 지원 및 표준 SQL 호환

– Apache Dremel: MapR에서 주도하며, 아직 초기 개발 단계

• 상용 서비스: Google BigQuery – Dremel 기술을 활용한 상용 서비스

Cloudera Impala

Horton Hawq

MapR Stinger

Apache Tajo

Apache Drill

Why SQL-on-Hadoop?

• Needs의 변화 – ‘투자대비 저렴한 가격으로 대용량 데이터 처리에 만족’

-> ‘보다 높은 처리 성능 및 빠른 반응’ 요구

– 많은 사용자가 Ad-hoc 질의를 위해 DB 병행 사용에 불만

• 대화형 질의 (Interactive Query) – 발견은 ‘질의 -> 결과 분석과 사고 -> 질의’의 순환

• 시스템의 빠른 반응 속도가 데이터 분석의 생산성

– 빠른 의사 결정 가능

• 성능 보장 및 사람에 의한 오류 방지 – MapReduce 프로그래밍: 개발자 역량에 의존적 (버그 가능성 높음)

– 질의 언어: 적절한 성능은 시스템이 보장 (버그 가능성 낮음)

–http://www.slideshare.net/gruter/07-gruter-tajosqlonhadoop

http://jaso.co.kr/480

현재 SQL-On-Hadoop 진영에서 제시하는 대부분의 성능 수치는 일반적인 질의나

전체 질의에 대해서 평균 몇 배 빠르다가 아닌 자신들이 유리한 조건에서 테스트한 결과만을 언급하는 경우가 많다. 필자의 테스트 결과를 보면 대략 평균 3 ~ 5배 정도이고 질의의 종류에 따라 수 십배 정도 빠를 수도 있고, 더 느릴 수도 있다.

자신의 데이터 속성과 질의 속성에 맞는 플랫폼을 선택하는 안목이 필요할 때이다. 미국산 벤더, 블로그, 언론에서 제시한 수치라고 맹신하는 것은 금물이다.

SQL on Hadoop 100배, 200배 성능의 진실 (김형준) 중에서…

SQL on Hadoop 100배, 200배 성능의 진실

• Hadoop = Function (All Data) – Cloudera, Horton, MapR, Intel, EMC

• Realtime Event = Function (Data Stream) – Storm, S4, Kafla

• SQL on Hadoop = Query (All Data) – Impala, Dremel, Tajo, BigQuery

• NoSQL = Query (Data Store) – Mongodb, Hbase, Cassandra…

요약하면…

Hadoop Storm Impala MongoDB

일괄 처리(Batch) 실시간 준 실시간 실시간

Map/Reduce (Job)

Spout/Bolt (Topology)

- -

HDFS - HDFS 호환 데이터저장소

작업 중심 작업 중심 질의 중심 질의 중심

일회 작업 단위 연속 작업 일회 쿼리 단위 쿼리 단위

Berkeley Spark Apache S4/Kafka Apache Dremel/Tajo Berkeley Shark Google BigQuery

Cassandra Hbase/Mongodb

주요 빅 데이터 분석 기술 방식 비교

• 대용량 데이터 분석 및 저장 방식에 따라 다양한 분석 기술 선택 가능

• Scale-out 방식의 병렬 처리 및 In-Memory 기반 기술이 오픈 소스에서 적용이 계속 되고 있음

새로운 동향1: Berkeley Stack

• 주요 특징

– 인메모리 기반의 새로운 오픈소스 분석 기술로 특정

데이터의 경우, Haoop에 비해 수 십배 빠른 처리 속도

– 기존 Hadoop 기술과 호환성 극대화하여 개발자 지원,

But 인메모리 가지는 한계 있음

• Spark http://spark-project.org

– 스토리지 In/Out 대신 주요 데이터셋을 메모리에 올려

서 Iteration에 최적화 시킴 (머신러닝/그래프 탐색)

– Interactive Data Mining에 대한 최적화

(R/Excel/Python 등)

– 기존 HDFS 호환 및 Scala, Java, Python 기반 프로그래

밍 가능

• Spark Streaming

– 스트리밍 데이터에 대한 분석 기능 제공

• Shark http://shark.cs.berkeley.edu/

– HiveQL 기반의 분석 기능 제공

UC BERKELEY

새로운 동향2: Hadoop 2.0과 Yarn

• Hadoop 1.0의 단점 – 한 노드에서 실행할 수 있는 Map과 Reduce용 작업숫자가 제한되어, 노

드에 여유 자원이 있어도 그 자원을 활용 하지 못하는 상황이 발생. (자원 분배 및 작업 관리의 비효율성)

• YARN (Yet Another Resource Negotiator) – 자원 관리, Job 상태 관리를 ResourceManager와 ApplicationMaster로

분리하여, 기존 Job Tracker에 몰리던 병목을 제거 – MapReduce 외에 다양한 어플리케이션을 실행할 수 있으 며, 어플리케이

션마다 자원(CPU, 메모리)을 할당 받음

새로운 동향3: Analytics as a Service

• 분석 플랫폼 구축의 문제 – 대용량 데이터 분석에 필요한

확장성의 어려움

– 일회적 분석에 대한 비용 증가

– 상용 클라우드 플랫폼의 등장

• 클라우드 기반 분석 플랫폼 – Amazon EMR

– Google Big Query

– Microsoft HDInsight

클라우드 컴퓨팅의 장점

• No Up-Front Investment – 데이터센터의 공간을 사거나 하드웨어/소프트웨어 등의 직접 살 필

요가 없다

• No Provisioning Delay – 용량증대등으로 인해 서버를 늘려야할 경우 주문, 설치등으로 인한

지연이 없다

• No Idling Computing Resource – 쓴만큼 지불하기 때문에 리소스 관리를 적절히 하 면 비용을 최소화

할 수 있다.

• Easy to start an online service start-up – 클라우드 컴퓨팅으로 인해 초기 시작비용이 대폭 감소 –오픈소스로

인해 개발에 드는 비용도 대폭 감소

Amazon ElasticMapReduce

• AWS에서 제공해주는 Managed On-Demand 하둡서비스 – AWS 내의 EC2, S3 등을 이용하여 서비스 제공

• 서비스 특징 – 필요한 때 필요한 노드 만큼 하둡 클러스터를 셋업하고 사용이 끝나

면 클러스터를 셧다운하며, EC2 서버를 실행하여 이용

– 입력데이터와 최종출력데이터는 S3에 저장.

– S3가 HDFS의 역할을 수행.

– 스크립트, JAR 파일등도 S3에 저장되어 있어야 함

• 활용 방법 – 짧은 시간에 대용량 데이터를 분석해야 하는 경우

– 하둡 설치 및 관리가 번거러운 경우

AWS를 이용한 로그 분석 사례

– Amazone EMR: http://aws.amazon.com/ko/elasticmapreduce/

Google BigQuery

–https://developers.google.com/bigquery/

대용량 Dataset(최대 몇 십억 개의 행)를 대화식으로 분석하는 데 사용할 수 있는 웹 서비스

Lessons for Big Data

• 기술 내재화가 중요 (No Vendors!) – 개발자들이 직접 Hadoop을 활용할 수 있는 환경 필요

– 오픈 소스의 적극 활용 및 개발 잉여력 제공

– 필요하다면, 클라우드 플랫폼 적극 활용

• 데이터 분석 및 처리의 역할 파괴 (No Data Scientist!) – 개발자들이 직접 실시간 분석을 위한 다양한 도구 활용 가능

– 문서, 이미지 등 다양한 형태의 데이터 처리를 위한 토대 마련

• Small Data를 활용 강화 (No Big Mistakes!) – Small Data라도 실시간으로 저렴하게 데이터를 처리하고,

– 처리된 데이터를 더 빠르고 쉽게 분석하도록 하여,

– 이를 비즈니스 의사결정에 바로 이용하는 것

Try it!

• 교육 프로그램 – Bigdata University

• http://bigdatauniversity.com/wpcourses/

– 빅데이터 아카데미

• http://www.dbguide.net/bigacademy.db

• 활용 예제 – Amazon EMR을 이용한 단어 카운트 예제

• http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-get-started-count-words.html

– Google Bigquery를 위한 샘플 테이블 예제

• https://developers.google.com/bigquery/docs/sample-tables

Q&A

• E-mail: channy@creation.net • Twitter: http://twitter.com/channyun • Facebook: http://fb.com/channyblog • Blog: http://channy.creation.net