2014 ACE Conference & Academy 발표 자료

1. 빅 데이터 기술현황과 시장전망
윤석찬
channyun

2. 목차
•데이터 폭증과 빅데이터
–글로벌 데이터의 증가 추세와 빅데이터의 등장
•빅데이터 기술 현황
–Hadoop / NoSQL
–실시간 분석
–SQL on Hadoop
•새로운 기술 동향
–Spark
–Hadoop 2.0 및 Yarn
–클라우드 기반 분석 플랫폼
•기술 활용 프랙티스

3. 웹 2.0 및 소셜웹의 성장
•웹 2.0: Platform as a Web
–데이터와 API를 통한 다양한 서비스 증가
–오픈 API 플랫폼의 및 As-a-Service의 증가
•API Billion Club의 탄생
© programmableweb, 2012

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

5. 웹서비스
비교
빅데이터
1990년대
시기
2010년대
X86급
서버 장비
중형급
상용 유닉스
잠식 시장
DW(데이터웨어하우징)
Redhat
대표 회사
Cloudera
리눅스 토발즈
대표 영웅
더그 커팅
Linux
소프트웨어
Hadoop
인터넷 포털
웹 스타트업
혁신 주체
소셜네트워크
모바일
저렴한 웹서버 구축
변화 요인
저렴한 데이터 분석
–빅데이터와 웹 서비스 열풍 비교도 © Channy’s Blog
빅 데이터 열풍!

6. @mdennis, datastax
데이터 폭증 시대의 두 가지 문제

7. 빅 데이터란?

8. 다양한 빅데이터 기술
분석 도구
비관계형(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

9. Input
1. Hadoop 기술 batch analytics
…
…
Output
…
MAP
REDUCE
복잡한 문제를 작은 문제로 쪼갠다
문제를 여러 서버에 나누어서 해결한다
결과를 모아서 합친다

10. Why Hadoop?
•데이터 분석을 위한 오픈 소스 스택 제공 가능
© Cloudera, 2012

11. Hadoop 기반 로그 분석 사례
•일 로그 사이즈 70TB
•Daum 서비스 내 발생하는 모든 트래픽을 수집하여 분석 및 리포팅
–주요 분석 데이터: Pageview, Clickstream, User Analysis
•데이터 처리 스택
–Hadoop: 데이터 전처리
–Hive (UDF, M/R): SQL 기반 데이터 분석
–Pentaho Kettle (ETL): 데이터 저장
–Greenplum: 병렬 데이터베이스
•기존방식에 비해 데이터 처리 속도 향상 및 데이터 적재기간 증가

12. 적용 결과
•더 빠른 분석 (10분 단위 실시간 로그 확인 가능)
•더 쉬운 분석 (Hive)
selelct serviceId, count(distinct uuid)
from web_log
where dt='20120101' group by serviceId
고객 분석 일 로그 분석
Hadoop 도입 전
Hadoop 도입 후

13. Hadoop의 장단점
•장점 : 기존 분석 기술에 비해 저렴하게 데이터 분석 가능
–데이터를 바라 보는 관점의 차이 (저렴한 처리 비용)
–샘플링이 필요 없음 (대용량 처리 가능)
–운영 비용이 적음 (인프라 운영이 관리 가능)
–분석도구나 프로그래밍 언어에 독립적임
–다양한 개발 도구 (오픈 소스 지원)
•단점: 분석 방식의 변화 및 내재화 비용
–개념의 변화가 필요 (Map/Reduce식 사고 전환 필요)
–Hadoop은 진화 중(벤더 배포판 사용 기회 늘어남)
–아직 구현되지 않은 부분이 많음(버전 호환성이 낮은 편)
–장애에 대한 대비 필요(메모리 및 네트웍 관련 시행착오)
–실시간 분석에 대한 필요성 (대안 기술 선택적 사용)

14. 2. NoSQL 활용 not only SQL
•대용량 데이터 업데이트 및 조회 시, 기존 RDBMS에 비해 빠른 성능 제공
•구조가 간단한 대량 이벤트 및 로그 데이터 저장 및 조회 시 유용
© Yahoo! Research. 2010

15. 아고라 대량 데이터 수집 사례
•마이아고라는?
–토론, 청원, 즐보드 등 아고라의 모든 글을 모아서 제공
–총 데이터 6천만건 (2012.1)
•문제점
–짧은 시간에 너무 많은 데이터가 추가 되고 있음
•해결 방법
–데이터 입력 시간이 훨씬 짧은 NoSQL 솔루션 도입
Select
Insert
Update
Delete
MySQL
355sec
250sec
317sec
310sec
MongoDB
294sec
60sec
153sec
123sec
<1백만건 MySQL과 MongoDB 데이터 처리 실험 결과>

16. NoSQL의 장단점
•장점: 빠르고 유연한 데이터 저장 및 조회 능력
–데이터가 증가함에 따라서 노드의 갯수만 늘리면 됨(확장성과 가용성)
–Key-Value 형식으로 저장하므로 유연한 데이터 구조(Schemaless)
–데이터 인덱싱으로 빠른 응답 가능(고성능)장점 : 기존 분석 기술에 비해 저렴하게 데이터 분석 가능
•단점: 분석 방식의 변화 및 내재화 비용
–스키마 설계, 서버 네트워크 구성, 메모리/IO 등에 시행착오
–데이터 무결성(integrity)을 위한 처리 비용이 큼
•트랜잭션과 같은 복잡한 처리에 적합하지 않음
•장애시 데이터 복구에 드는 노력이 많이 듦
–Schemaless라서 Join 과 같은 복잡한 쿼리 사용 어려움
•MongoDB 같은 경우, 빠른 인덱싱 및 SQL 친화적인 지원 가능

17. 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

18. •실시간 분석의 어려움
–Hadoop은 배치(Batch) 처리 방식이라 실시간에 적합하지 않음
–NoSQL은 데이터 저장만 빠르지 분석 데이터를 걸러내기 어려움
•실시간 분석 엔진의 등장 (Storm이 대표적)
–트위터에서 직접 개발해서 오픈소스화
–Data Stream을 바라보고 실시간으로 데이터를 바라보는 로직을 구현
–로직(Topology)를 Storm Cluster로 던지면 적절히 실행해서 분석
Spout
Bolt
Data Stream
NoSQL
Node.js
Data Stream

19. 실시간 분석이 필요할 때…
•활용 대상 영역
–쇼핑몰 사이트의 사용자 클릭 스트림을 통해 실시간 개인화
–사용자 위치 정보 기반 광고 및 추천 기능
–시스템 이벤트를 이용한 실시간 보안 감시
–차량 추적 및 위치 정보 수집을 이용한 도로 교통 상황 파악
–사용자의 액션 수집을 이용한 이상 행위 탐지
•기획자의 요구 사항
–데이터가 변화되는 모습을 화면에서 바로 보고 싶다!
–간결한 차트와 선택 및 실시간 변화를 보고 싶다!
•기술 요구 사항
–로그 수집, 실시간 분석 및 장기 분석을 위한 저장소 필요
–주기적 차트 생성 및 쿼리에 대한 브라우저 기반 기능도 구현 필요

20. 미디어 다음 실시간 로그 수집 사례
•미디어 콘텐츠에 대한 실시간 현황 파악
–‘나는가수다’, ‘K팝스타’ 같은 특정 콘텐츠(디지털 브랜드)에 대한 변화 측정 필요
–이벤트 및 이슈에 대한 실시간 상황 파악을 위한 관리 도구 제공

21. Storm을 이용한 분석 순서

22. 실시간 분석 구축 시 유의 사항
•정말 필요한가?
–Storm/S4 같은 기술을 도입하기 전에 정말 필요한지 확인해야함
–실시간 분석은 빅데이터 분석의 일부분이며, 명확한 업무 정의가 된 경우에만 수행 해야 함
–Batch/Query/Realtime에 대한 이해 파악 필요
•고난을 각오해라!
–잘 알려진 케이스는 많으나 실제로 구현하다 보면 어려움 봉착
–시스템 엔지니어링 운영 기술 및 대용량 메모리(~98GB) 기반 서버팜 등이 필요함
•역시 오픈 소스!
–오픈 소스 커뮤니티의 규모와 문서화 케이스 등으로 지원 가능한지 확인 후에 진입하는 것이 좋다.

23. 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

24. Why SQL-on-Hadoop?
•Needs의 변화
–‘투자대비 저렴한 가격으로 대용량 데이터 처리에 만족’ -> ‘보다 높은 처리 성능 및 빠른 반응’ 요구
–많은 사용자가 Ad-hoc 질의를 위해 DB 병행 사용에 불만
•대화형 질의 (Interactive Query)
–발견은 ‘질의 -> 결과 분석과 사고 -> 질의’의 순환
•시스템의 빠른 반응 속도가 데이터 분석의 생산성
–빠른 의사 결정 가능
•성능 보장 및 사람에 의한 오류 방지
–MapReduce 프로그래밍: 개발자 역량에 의존적 (버그 가능성 높음)
–질의 언어: 적절한 성능은 시스템이 보장 (버그 가능성 낮음)
–http://www.slideshare.net/gruter/07-gruter-tajosqlonhadoop

25. http://jaso.co.kr/480
현재 SQL-On-Hadoop 진영에서 제시하는 대부분의 성능 수치는 일반적인 질의나 전체 질의에 대해서 평균 몇 배 빠르다가 아닌 자신들이 유리한 조건에서 테스트한 결과만을 언급하는 경우가 많다. 필자의 테스트 결과를 보면 대략 평균 3 ~ 5배 정도이고 질의의 종류에 따라 수 십배 정도 빠를 수도 있고, 더 느릴 수도 있다.
자신의 데이터 속성과 질의 속성에 맞는 플랫폼을 선택하는 안목이 필요할 때이다. 미국산 벤더, 블로그, 언론에서 제시한 수치라고 맹신하는 것은 금물이다.
SQL on Hadoop 100배, 200배 성능의 진실 (김형준) 중에서…
SQL on Hadoop 100배, 200배 성능의 진실

26. •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…
요약하면…

27. 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 기반 기술이 오픈 소스에서 적용이 계속 되고 있음

28. 새로운 동향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

29. 새로운 동향2: Hadoop 2.0과 Yarn
•Hadoop 1.0의 단점
–한 노드에서 실행할 수 있는 Map과 Reduce용 작업숫자가 제한되어, 노드에 여유 자원이 있어도 그 자원을 활용 하지 못하는 상황이 발생. (자원 분배 및 작업 관리의 비효율성)
•YARN (Yet Another Resource Negotiator)
–자원 관리, Job 상태 관리를 ResourceManager와 ApplicationMaster로 분리하여, 기존 Job Tracker에 몰리던 병목을 제거
–MapReduce 외에 다양한 어플리케이션을 실행할 수 있으 며, 어플리케이션마다 자원(CPU, 메모리)을 할당 받음

30. 새로운 동향3: Analytics as a Service
•분석 플랫폼 구축의 문제
–대용량 데이터 분석에 필요한 확장성의 어려움
–일회적 분석에 대한 비용 증가
–상용 클라우드 플랫폼의 등장
•클라우드 기반 분석 플랫폼
–Amazon EMR
–Google Big Query
–Microsoft HDInsight

31. 클라우드 컴퓨팅의 장점
•No Up-Front Investment
–데이터센터의 공간을 사거나 하드웨어/소프트웨어 등의 직접 살 필요가 없다
•No Provisioning Delay
–용량증대등으로 인해 서버를 늘려야할 경우 주문, 설치등으로 인한 지연이 없다
•No Idling Computing Resource
–쓴만큼 지불하기 때문에 리소스 관리를 적절히 하 면 비용을 최소화할 수 있다.
•Easy to start an online service start-up
–클라우드 컴퓨팅으로 인해 초기 시작비용이 대폭 감소 –오픈소스로 인해 개발에 드는 비용도 대폭 감소

32. Amazon ElasticMapReduce
•AWS에서 제공해주는 Managed On-Demand 하둡서비스
–AWS 내의 EC2, S3 등을 이용하여 서비스 제공
•서비스 특징
–필요한 때 필요한 노드 만큼 하둡 클러스터를 셋업하고 사용이 끝나면 클러스터를 셧다운하며, EC2 서버를 실행하여 이용
–입력데이터와 최종출력데이터는 S3에 저장.
–S3가 HDFS의 역할을 수행.
–스크립트, JAR 파일등도 S3에 저장되어 있어야 함
•활용 방법
–짧은 시간에 대용량 데이터를 분석해야 하는 경우
–하둡 설치 및 관리가 번거러운 경우

33. AWS를 이용한 로그 분석 사례
– Amazone EMR: http://aws.amazon.com/ko/elasticmapreduce/

34. Google BigQuery
–https://developers.google.com/bigquery/
대용량 Dataset(최대 몇 십억 개의 행)를 대화식으로 분석하는 데 사용할 수 있는 웹 서비스

35. Lessons for Big Data
•기술 내재화가 중요 (No Vendors!)
–개발자들이 직접 Hadoop을 활용할 수 있는 환경 필요
–오픈 소스의 적극 활용 및 개발 잉여력 제공
–필요하다면, 클라우드 플랫폼 적극 활용
•데이터 분석 및 처리의 역할 파괴 (No Data Scientist!)
–개발자들이 직접 실시간 분석을 위한 다양한 도구 활용 가능
–문서, 이미지 등 다양한 형태의 데이터 처리를 위한 토대 마련
•Small Data를 활용 강화 (No Big Mistakes!)
–Small Data라도 실시간으로 저렴하게 데이터를 처리하고,
–처리된 데이터를 더 빠르고 쉽게 분석하도록 하여,
–이를 비즈니스 의사결정에 바로 이용하는 것

36. 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

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