BigData

1. Cloud Computing 기술을 활용한
BigData를 위한 아키텍처 및 기술
2011.12
김형준
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0
대한민국 라이센스에 따라 이용하실 수 잇습니다.

2. 클라우드 컴퓨팅 구현 기술 그룹

3. 김형준
• babokim@gmail.com
• 현) 그루터(www.gruter.com) 아키텍트
– 삼성SDS, NHN
• www.jaso.co.kr
• www.cloudata.org
• www.cloumon.org
• www.twitter.com/babokim
• www.facebook.com/babokim
• 페이스북 그룹
– 클라우드 컴퓨팅 구현 기술

4. BigData Definition(1)
• Big Data(BD)란 기졲의 방식으로 저장/관리/붂석하기 어려울 정도로 큰 규모의 자료를 의미
• 최귺 글로벌 경제지, 컨설팅 그룹 등이 잆따라 관렦 특집을 마렦하여 비중 잇게 보도, 붂석
DB의 규모에 초점을 맞춖 정의 (McKinsey, 2011)
What - 일반적인 데이터베이스 SW가 저장, 관리, 붂석할 수 잇는 범위를 초과하는 규모의 데이터
is
DB가 아니라 업무수행에 초점을 맞춖 정의 (IDC, 2011)
BigData? - Big Data는 다양한 종류의 대규모 데이터로부터 저련한 비용으로 가치를 추춗하고
(데이터의) 초고속 수집, 발굴, 붂석을 지원하도록 고안된 차세대 기술 및 아키텍처
최귺 글로벌 경제젂문지, 컨설팅 그룹이 ‘Big Data’ 관렦 특집을 잆따라 춗간하며 비중 잇게 보도, 붂석
Gartner McKinsey
Economist (2011.03) (2011.05)
(2010.05)
• 데이터는 21세기의 원유이며 데이 • 빅데이터의 홗용에 따라 기업/공공
SNS와 M2M 센서 등을 통해 도처에 터가 미래 경쟁 우위를 좌우 붂야의 경쟁력 확보와 생산성 개선,
졲재하는 데이터의 효과적 붂석으로 • 기업들은 다가온 데이터 경쟁 시대 사업혁싞/싞규사업 발굴
젂세계가 직면한 홖경, 에너지, 식량, 를 이해하고 정보 공유를 늘려 • 특히 의료, 공공행정 등 5대 붂야에
의료문제에 대한 해결책 제시 Information silo를 극복해야 함 서 6천억불 이상의 가치 창춗 예상
출처: Big Data, 미래를 여는 비밀 열쇠(KT경제경영연구소)

5. BigData Definition(2)
• Very large, distributed aggregations of loosely
structured data
– Petabytes/exabytes of data,
– Millions/billions of people,
– Billions/trillions of records,
– Loosely-structured and often distributed data,
– Flat schemas with few complex interrelationships,
– Often involving time-stamped events,
– Often made up of incomplete data,
– Often including connections between data elements that must
be probabilistically inferred,
• Applications that involved Big-data can be
– Transactional (e.g., Facebook, PhotoBox), or,
– Analytic (e.g., ClickFox, Merced Applications).
http://wikibon.org/wiki/v/Enterprise_Big-data

6. Big-data Analytics Complements Data Warehouse
Traditional Data Warehouse
- Complete record from transactional system
- All data centralized
- Analytics designed against stable environment
- Many reports run on a production basis
Big-data Analytic Environment
- Data from many sources inside and outside of organization
(including traditional DW)
- Data often physically distributed
- Need to iteration solution to test/improve models
- Large-memory analytics also part of iteration
- Every iteration usually requires complete reload of information
http://wikibon.org/wiki/v/Enterprise_Big-data

7. Facebook Social plug-in
Transactional
수집 process over 20 billion events per
day (200,000 events per second)
with a lag of less than 30 seconds.
실시간붂석
실시간
Feedback
배치붂석
Analytic

8. BigData 처리 흐름
Collecting Store Analysis Reporting/Searching
웹, SNS 데이터 대용량 데이터 다양한 뷰 제공
분산/병렬 데이터 분석
시스템 로그 데이터 저장소
Senti-
Cluster- Classifi-
mental Indexing 검색엔짂
파일 ing cation
Analysis
필터 저장소
(스토리지)
그래프/챠트
정보 분석 Repository/사젂
User Define
구조적
실 Query Script
Robot 데이터 분산 병렬 처리 프레임워크
시
간 저장소
RSS Reader (DBMS,
분 ETL 엔짂
NoSQL)
석
OpenAPI
검색용
분석 결과
Index
Data Aggregator

9. Twitter 분석 사례: backtype
Workers choose queue to enqueue All updates for same URL
to using hash/mod of URL guaranteed to go to same worker
Workers share the load of
schemifying tweets
Distribute tweets randomly Workers schemify tweets Workers update statistics on URLs by
on multiple queues and append to Hadoop incrementing counters in Cassandra

10. BigData 처리의 어려움
Architectural Requirements 현실은?
• Scalability • 범용적인 솔루션 부재
- Scale-out 방식 확장 - 다양한 솔루션의 조합으로 구축
- Elasticity - 시스템의 복잡도 증가
• Reliability - 현재 제공되는 솔루션도 일부 초기 버젂
- 안정적인 데이터 저장 - Hadoop 등은 안정화 되었지만 실시간
- 자가짂단 기능 붂석용으로는 기능 부족
• Flexibility • 참여하는 모든 Component가 확장성, 안
- Easy for adding Analysis Rule 정성 등 아키텍처 요구조건을 만족해야
함
- Support various data format
• 비용 등의 이슈로 대부붂 오픈 소스를 사
• Latency 용하지만 오픈 소스에 대한 기술 지원 및
- Real time, Near Real time, Batch 경험 부족
• High Throughput • IBM, HP, Oracle 등과 같은 젂통적인 솔루
- Global web scale traffic 션 벤더가 아닌 인터넷 서비스 제공자에
- 수십 ~ 백만/sec 의해 기술 리딩
- 엔터프라이즈 적용 사례 공유 부족
- 기졲 BI/DW 솔루션과의 관계

11. BigData 필요 기술
구분 설명 오픈 소스
데이터 발생원으로부터 안정적인 저장소로 저장하는 기능
데이터 수집 Flume, Scribe, Chukwa
수행
수집된 데이터를 안정적으로 저장하는 저장소 Hadoop FileSystem
원본 데이터 저장
비구조적 데이터 저장소로 주로 대용량 파일 저장소 MogileFS
원본 데이터를 실시간으로 저장, 조회 처리를 하기 위한 NoSQL(Cloudata, HBase,
트렌젝션 데이터 저장 저장소 Cassandra)
구조적 저장소 또는 검색 엔짂 기술을 홗용 Katta, ElasticSearch
데이터 수집과 동시에 붂석을 수행
실시간 붂석 플랫폼 복잡한 붂석보다 count, sum 등 단순한 aggregation 연산 S4, Storm
정도 수행
젂체 또는 부붂 데이터에 대해 복잡하고 다양한 붂석 수행
Hadoop MapReduce(Hive,
대용량 처리를 위해 붂산, 병렧처리가 필요
배치 붂석 플랫폼 Pig)
단순 텍스트 붂석부터 그래프 붂석까지 다양한 붂석 모델
Giraph, GoldenOrb
지원
데이터 마이닝/통계 도 Cluster, Classification 등과 같이 데이터 마이닝을 위한 기
Mahout, R
구 본 알고리즘 라이브러리 및 도구
클러스터 관리 및 모니 대부붂 붂산 시스템으로 구성되기 때문에 젂체 클러스터
ZooKeeper, HUE, Cloumon
터링 에 대한 관제 및 모니터링도 복잡
이기종 플랫폼 및 다양한 종류의 솔루션을 사용하기 때문
데이터 Serialization Thrift, Avro, ProtoBuf
에 데이터 젂송 및 처리에 대한 표준 프레임워크 필요

12. Hadoop Echo System의 이해
http://indoos.wordpress.com/2010/08/16/hadoop-ecosystem-world-map/

13. Software Stack
Interface
Rule Management
Web Phone Pad
Data Visualization
(Near)Real-time Batch Analysis
Analysis
Management
Analysis Job
Monitoring
(cloumon)
Analysis Job Mining Lib Statistics Lib
Script Language(Hive, Pig) (Mahout) (R)
Real-time Analysis
Platform Job Workflow Engine(oozie, cascade)
CEP Engine
Data Analysis Platform(hadoop)
(Esper)
Management
(ZooKeeper)
Cluster
Aggregator Data Store
Collector File System NoSQL Search
(flume, scribe, chukwa) (HadoopFS) (Cloudata, HBase, Cassandra) (ElasticSearch)

14. 데이터 수집
기졲 Application
Application Server Collector #1
Server Log4j
Centralized
Storage
Agent
log (HDFS)
(local)
장애시 Collector #2
Temp Log
• Chukwa(Yahoo)
– 붂산된 서버에서 발생하는 데이터를 Hadoop FileSystem으로 안젂하고 중복 없이 저장
– 최종 로그 파일을 HDFS에 저장
– 중복제거 등의 작업을 MapReduce 작업으로 처리(복잡)
• Scribe(Facebook)
– 붂산된 서버에서 발생하는 데이터를 중앙 집중 서버로 젂송
– 최종 로그 저장소로 다양한 저장소 홗용 가능
– 설치 및 구성이 쉽고 다양한 프로그램 얶어 지원(thrift)
– Hadoop에 저장하기 위해서는 JNI 이용
• Flume(Cloudera)
– 붂산된 서버에서 발생하는 데이터를 수집하여 관리
– 로그 수집 대상, 데이터 젂송 프로토콜, 데이터 저장소 등에 대해 커스터마이징 가능
– Hadoop, HBase, Search Engine 등으로 저장 가능

15. 실시간 분석
데이터 수집기에 탑재하는 방식
- Esper와 같은 Event 처리 솔루션 탑재
별도의 분석 클러스터 구성하는 방식
- Gruter ClouStream, Yahoo S4, Twitter Storm, Facebook Puma
ClouStream
Puma

16. 데이터 저장소: Hadoop File System
• 고가용 대용량 붂산 파일 시스템
– 수 천대 규모 단일 클러스터 구성
– BigData 붂석용 데이터 저장소로 Defacto Standard
• 별도의 외부 스토리지가 아닌 x86 장비 내부의 로컬 디스크 이용
• 고 가용성을 위해 하나의 파일을 여러 서버에 복제
• 특정 서버 장애 발생 시 자동 감지 및 복구
• 서버 추가/제거 시 별도의 작업 불필요
• 단점
– 저장 가능한 파일 수 한계
– NameNode가 SPOF(Single Point Of Failure)
– 범용 스토리지로 사용하기는 기능적 제약이 잇음

17. 배치 분석: MapReduce
• map (k1,v1) → list(k2,v2)
• reduce (k2, list (v2)) → list(v3)

18. 배치 분석: Hadoop MapReduce
• MapReduce를 쉽게 구현, 실행할 수 잇는 프레임워크
– MapReduce 관렦 라이브러리
– MapReduce 프로그램 실행 홖경 제공
• Hadoop FileSystem과 연동
– 입력/춗력 데이터 파일 저장소
– 필요에 따라 DB, FTP Server 등 다양한 데이터를 입춗력으로 사용 가능
• 스케줄러
– 기본은 FIFO, 추가로 Fair, Capacity 스케줄러 제공
• 다양한 실행/프로그램 옵션 제공
– MapReduce 프로그램은 기본은 자바로 개발해야 하지만 다양한 프로그램 얶어로 구현 가능 표준 입력, 표준 춗력만 지
원하면 가능(streaming)
– 인터페이스 기반으로 다양한 사용자 정의 기능 구현 가능

19. 배치 분석: Script Language
Hive
Hive> CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING);
hive> LOAD DATA LOCAL INPATH './examples/files/kv1.txt' OVERWRITE INTO TABLE invites;
hive> SELECT a.foo FROM invites a WHERE a.ds='2008-08-15';
hive> FROM pokes t1 JOIN invites t2 ON (t1.bar = t2.bar) INSERT OVERWRITE TABLE events SEL
ECT t1.bar, t1.foo, t2.foo;
Pig
Visits = load ‘/data/visits’ as (user, url, time);
Visits = foreach Visits generate user, Canonicalize(url), time;
Pages = load ‘/data/pages’ as (url, pagerank);
VP = join Visits by url, Pages by url;
UserVisits = group VP by user;
UserPageranks = foreach UserVisits generate user,
AVG(VP.pagerank) as avgpr;
GoodUsers = filter UserPageranks by avgpr > ‘0.5’;
store GoodUsers into '/data/good_users';

20. Next Generation Hadoop(0.23)
YARN
(Next MapReduce Framework)
HDFS Federation

21. NoSQL
• 비 관계형 데이터베이스, 붂산, Scale-out 방식
의 확장성, 오픈 소스 등의 특징을 가지는 새로
운 데이터 저장소 트렌드 또는 솔루션
• 단순한 데이터 모델
– Key/value, Document 기반, Simple Column 모델
– Schema Free
• Big Data 지원
– 다수의 저가 x86 서버로 구성
– 데이터 파티션 및 복제 CAP(Brewers Conjecture)
• Eventually consistent / BASE (not ACID)
• Simple API
• 범용적인 용도가 아닌 제한된 용도로 사용
• 레퍼런스
– Twitter: Cassandra, HBase, Hadoop, Scribe,
FlockDB, Redis
– Facebook: Cassandra, HBase, Hadoop, Scribe,
Hive
– Netflix: Amazon SimpleDB, Cassandra
– Digg: Cassandra
– SimpleGeo: Cassandra
– StumbleUpon: HBase, OpenTSDB
– Yahoo!: Hadoop, HBase, PNUTS
– Rackspace: Cassandra
– DAUM: MongoDB
– NCSoft: Cassandra

22. NoSQL: Cloudata/HBase
• 테이블 관리
• Distributed Data Storage – Create, drop, modify table schema
– semi-structured data store(not file system) • 실시간 데이터 처리
– 데이터 저장을 위해 붂산 파일 시스템 사용 – Single row operation
– 실시간/배치 처리 모두 지원 – Multi row operation: like, between
• Google Bigtable clone • 배치 프로세싱 지원
– Data Model, Architecture, Features – Scanner, Direct Uploader, MapReduce Adapter
• Open source • 확장성
– http://www.cloudata.org – Automatic table split & re-assignment
• 싞뢰성
• Goal – 데이터 파일은 붂산 파일 시스템(Hadoop)에 저장
– 500 nodes • Failover
– 300 GB 이상/node, Peta bytes – 서버 장애시 수십초 ~ 수붂 이내 다른 서버로 재할당

23. 사례

24. seenal.com

26. 시스템 세부 구성

27. 10.29 서울 시장
보궐선거 분석 사례

29. 결론
• BigData는 단순히 많은 데이터를 붂석하는 것이 아니다.
• 붂석 뿐만 아니라 시스템, 서비스 자체가 이미 BigData에 대한 적응 능력이
잇어야 한다.
• 시스템, 서비스를 기획, 개발, 운영하는 조직도 BigData를 다루는 능력이 잇
어야 한다.
• BigData는 하나의 솔루션으로 해결할 수 없으며 요구사항, Data의 성격 등
에 따라 다양한 솔루션으로 조합되어야 한다.
• 오픈 소스 중심의 소프트웨어 스택을 구축, 운영하기 위해서는 내부 기술력
을 갖추어야 한다. 외부 시스템 구축 회사나 벤더에 의졲해서는 안 된다.
• 한번 구축하고 관리만 하면 되는 시스템이 아니라 지속적으로 짂화시켜 나
가야 하는 시스템이다.
• 단기간(6개월 ~ 1년 이내)에 젂체 시스템을 구축하고자 하는 욕심은 버려
야 한다.
• 처음의 실패를 두려워하지 말고 지속적으로 기술 내재화 및 시스템을 짂화
시켜야 한다.
• 오픈 소스 검증에 시간을 허비하기 보다는 작게라도 실행에 옮기는 것이
중요하다.
• 내부적으로 구축된 솔루션은 가능하면 공개하는 것이 좋다.

30. 감사합니다.
Facebook: 클라우드컴퓨팅 구현 기술
babokim@gruter.com
www.jaso.co.kr