Big data application architecture 요약2

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HP Restricted
C03934969, January 2014
[요약]
BigDataApplicationArchitecture
-NitinSawanti외
HP ES Korea
이성복

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HP Restricted2
내용
Chapter 1 : Big Data Introduction
Chapter 2: Big Data Application Architecture
Chapter 3: Big Data Ingestion and Streaming Patterns
Chapter 4: Big Data Storage Patterns
Chapter 5: Big Data Access Patterns
Chapter 6: Data Discovery and Analysis Patterns
Chapter 7: Big Data Visualization Patterns
Chapter 8: Big Data Deployment Patterns
Chapter 9: Big Data NFRs

[Chapter 1]
BigDataIntroduction

Big Data 참조 아키텍처
BFaaS
Industry Business
Functions
Big data Analysis &
Visualization Tools
DaaS
IaaS
PaaS NoSQL and Relational
Database
Big Data Storage &
Infrastructure Layer
Infrastructure as a Service (IaaS):
• 빅데이터의 기반이 되며 값싼 구성품으로써의 스토리지, 서버, 네트워크
• bare metal 또는 virtual(cloud)로 구성 가능
• 분산 파일 시스템이 이 레이어의 일부
Platform as a Service (PaaS):
• The NoSQL data stores and distributed caches that can be logically
queried using query languages form the platform layer of big data.
• 파일에 저장된 가공되지 않은 비정형 데이터를 위한 논리 모델을 제공.
Data as a Service (DaaS):
• PaaS 레이어와 통합하는데 사용되는 모든 도구들의 집합 : 검색엔진,
integration adaptors, 배치 프로그램 등
• 유연한 컴퓨팅 환경(elastic-computing mode)에 있는 모든 말단 시스템들이 이
레이어에서 제공되는 API들을 사용
Big Data Business Functions as a Service (BFaaS):
• 건강, 소매, e-커머스, 에너지, 금융과 같은 특정 산업에서는 패키지
어플리케이션을 구축하여 특정한 비즈니스 요구에 대응하고 공통된(cross-
cutting) 데이터 기능을 위한 DaaS 레이어를 향상시킬 수 있다.

[Chapter 2]
BigDataApplicationArchitecture

Big Data Application Architecture
A big data
management
architecture should
be able to consume
myriad data
sources in a fast
and inexpensive
manner.
Analytics Engines
Data
Source
Hadoop Platform Management Layer
Visualization Layer
Hadoop Administration
MapReduce
Statistical
Analytics
RelationalDB
IngestionLayer
Monitoring Layer
Security Layer
Hadoop
Infrastructure
Layer
Hadoop
Storage
Layer
Data Warehouses
UnstructuredData
ImagesSocialmediaAudio
Video
Streaming
Data Analyst IDE/SDK Visualization Tools
Text Analytics
Search Engine
Real Time
Engine
Pig Hive Sqoop
Zoo
keeper
NoSQL Database
HDFS
Bare Metal Clustered Workstations
Visualized Cloud Services
Analytics
Appliances
Rack
Node
Disk
CPU
Rack
Node
Disk
CPU
Rack
Node
Disk
CPU
Hadoop 관련 Layer
⑧
②
⑨
③
④
⑤
⑥
⑦
①

① Data Sources
 기업 내/외부의 다양한 원천으로부터 시간당 대량의 데이터를 엄청 빠른 속도로 유입되고 있음
 유입된 데이터는 균일하게 합쳐져서 분석할 수 있도록 넘겨짐
[정말 다양한 data source]
Legacy Data Sources
• HTTP/HTTPS web services, RDBMS, FTP, JMS/MQ based services, Text / flat file /csv logs, XML data sources, IM Protocol requests
New Age Data Sources(Telecom Industry)
• High Volume Sources : Switching devices data, Access point data messages, Call data record due to exponential growth in user base, Feeds
from social networking sites
• Variety of Sources: Image and video feeds from social Networking sites, Transaction data, GPS data, Call center voice feeds, E-mail, SMS
• High Velocity Sources : Call data records, Social networking site conversations, GPS data, Call center - voice-to-text feeds
Social Media Video Audio Email Texts Mobile Transactional
Data
Documents IT/OT Search Engine Images StreamingLegacy
data

② Ingestion Layer
 데이터 감시자
 빠르게 유입되는 다양한 대량의 데이터 중에서 잡 데이터(noise data, 전체 유입 데이터의 90%)를 솎아냄
 들어온 데이터를 검증(validate)/정제(cleanse)/전환(transform)/축소(reduce)/통합(integrate)하여 추가 처리
작업을 할 tech stack에 넘겨줌
• Identification : 알려진 다양한 데이터 포맷이나
비정형 데이터에 할당된 기본 포맷을 식별.
• Filtration : 들어온 정보들을 MDM repository에
따라 관련된 것들을 추출.
• Validation : 새로운 MDM 메타데이터로 데이터
일관성을 검증/분석
• Noise Reduction : 잡 데이터를 제거하고
불필요한 것들을 최소화함으로써 데이터 정제.
• Transformation : 데이터를 나누고, 모으고,
비정규화하거나 요약
• Compression 처리과정에서의 연관성을 해치지
않으면서 데이터의 크기를 줄임. 압축 후에
분석결과에 영향을 미치면 안됨.
• Integration : 최종 정리된 데이터 셋을 Hadoop
storage layer로 전달
Hadoop Storage
Layer
Identification
Filteration
Validation
Noise
Reduction
Compression
Transformation
Integration
NoSQL
Database
HDFS
DataSources

③ Distributed (Hadoop) Storage Layer
 클러스터 안의 여러 대의 기계들에서 아주 대량의 데이터(TB 또는 PB)를 저장하기 위해 설계된 파일시스템
 데이터를 안전하게 보관, runs on commodity hardware, 파일 전부 또는 일부를 저장하기 위해 블록(block)을
사용, 한 번 쓰고 여러 번 읽는 모델(write-once-read-many model) 지원
 숙련된 개발자들만이 HDFS에서 요구하는 복잡한 파일 읽기/쓰기 프로그램을 만들 수 있음  조작 어려움
NoSQL database
NoSQL database의
전형적인 비즈니스
시나리오
Shopping carts
 Web User Data
Analysis(Amazon,
Linkedin)
Analyze Huge Web
user Actions Sensor
Feeds(Facebook,
Twitter)
Real-time Analytics
 Logging
 Document Archive
management
Network Modelling
 Locality
Recommendation
Key-value Data Stores Column-orientedData
Stores
Document Data Stores Graph Data Stores
Cloudant
MarkLogic
OpenLink
Vertica

④ Hadoop Infrastructure Layer
 Storage Layer 밑에 있는 물리적 인프라
 분산컴퓨팅 모델 기반 : 데이터는 물리적으로 서로 다른 위치에 저장하되 네트워크와 분산파일시스템을
통해 서로 연결
 비공유(share-nothing) 아키텍처 : 노드들끼리 서로 의존성이 없이 각자 처리할 레코드만 보고 처리함
 병렬성이 매우 높음
 한 노드에 데이터와 기능이 함께 있어야 함.
 더 이상 데이터를 SQL 처리 기능이 있는
하나의 서버로 이동시킬 필요 없음.
 수많은 서로 다른 출처로부터 들어오는 수많은
데이터를 처리하게 되므로 인프라 차원에서
데이터 중복(Redundancy)은 피할 수 없음
전형적인 빅데이터 하드웨어 topology

⑤ Hadoop Platform Management Layer
 HDFS 스토리지 파일시스템을
사용하여 NoSQL 데이터베이스에
접근할 수 있는 tool과 query
language 제공
 데이터 접근
 쿼리 실행
 하위 영역 관리
 예전에는 무지 비싼 수퍼 컴퓨터로만
처리할 수 있었던 어마 어마한 양의
데이터를 관리할 수 있게 됨.
 컴퓨팅 기술의 진화
 시스템(CPU, RAM, 디스크 등)의 가격
하락
Big Data platform architecture
Hadoop Platform Layer (MapReduce, Hive, Pig)
Hadoop Storage Layer (HDFS, HBase)
High Speed Network
Cache
Solid State Disks
Metadata
Cache
Local Disks
Metadata
Cache
SAN
Metadata
Hadoop Infrastructure Layer… N nodes, Petabytes of Data

MapReduce
 Map : 문제(problem)나 작업(task)을 다수의 시스템에 분산시키고, 부하를 분산시키는 방법으로 작업을
배치하고, 장애 복구를 관리  key-value
 Reduce : 분산하여 할당시킨 컴퓨팅 작업이 완료되면, 모든 출력 값들을 새로운 키 기준으로 다시 하나로
묶어서 결과를 제공
※NameNode의 역할
- HDFS의 모든 메타 데이터 관리
- 클라이언트가 HDFS에 저장된 파일에 접근할 수 있게 함

[참고] Hadoop 시스템 구성 사례
(Sqoop)
Flume
• 로그수집기 도구
• Source-Channel-Sink
아키텍처로 쉽고 다양한
방식으로 로그를 수집
Oozie
• 맵리듀스 잡(Job)을
실행시켜주는 일종의
런처(launcher) 역할을 하는
워크플로우 관리 툴
• 웹서버로 별도로 운용
• 하둡과 연동하여 미리
작성된 워크플로우에 따라
맵리듀스 잡(job)을 실행
• REST API를 제공  자체
웹서버에서 우지 기능을
제어(잡 재실행, 정지 등)
가능

Sqoop
 RDBMS와 하둡간에 대량데이터를
전송하기 위한 도구
 맵리듀스를 통해 출력된
결과(HDFS)를 RDBMS로 Export 또는
RDBMS상에 있는 데이터를 HDFS로
Import할 수 있는 기능을 제공
 개별 테이블, 특정 컬럼, 또는 전체
데이터베이스 파일을 직접 분산 파일
시스템이나 데이터 웨어하우스로
불러올 수 있도록 하는 command-line
tool
 2.0 버전에서는 자체 WAS가 도입되어
REST API 등을 제공
Scoop import process

Zookeeper
 다양한 Hadoop 인스턴스와 노드들을 동기화하고 노드의 장애로부터 보호하기 위한 coordinator
 Coordination은 분산 시스템에서 부분적인 장애를 처리하는데 매우 중요
 장애 처리를 위한 다양한 방법들을 사용 : ordering, notifications, distributed queues, distributed locks, leader
election among peers, a repository of common coordination patterns.
Zookeeper topology
데이터 일관성과 관련하여 Zookeeper가 보장하는
것들:
 Sequential consistency
 Atomicity
 Durability
 Single system image
 Timeliness

⑥ Security Layer
 온라인을 통해 유통/관리되는 수 많은 종류의 사생활 관련 정보는 보호되어야 하고 관련 규제를 준수해야 함
 분석시 적절한 권한 부여와 인증 방법이 필요
 NoSQL의 보안 취약성
 분산 아키텍처는 단순한 프로그래밍 모델을 사용
 오픈 프레임웤 서비스를 사용
NoSQL의 보안 취약성
 NoSQL 기술은 아직 초기 단계이고 해커들의
손쉬운 먹잇감.
 With large clusters utilized randomly for
strings and archiving big data sets, 데이터가
어디에 저장되어 있는지 추적이 어렵게 되거나
불필요한 데이터를 지우는 것을 잊기 쉽다. 
나쁜 사람들의 손에 그런 데이터가 흘러들어가
기업에게 보안상의 위협으로 될 수도 있다.
보안을 위해 필요한 조치들 :
 노드 인증 : Kerberos 같은 프로토콜을 사용
 file-layer 암호화
 Subscribes to a key management service for trusted keys and certificates
 데이터 셋 배포 또는 가상 노드에 패치 적용시 검증 : Chef 나 Puppet 사용
 노드간 통신로그를 남기고, 분산 로그 메커니즘을 사용하여 레이어간
모순(anomalies) 추적
 노드간 모든 통신이 안전함을 보장 - Secure Sockets Layer (SSL), TLS 등을
사용

⑦ Monitoring Layer
 데이터 저장과 시각화를 위한 툴 제공
 빅데이터 tech stack에 관한 전체적인 그림 필요
 모니터링 시스템은 대량의 분산 클러스터들이 federated mode로 배포되어 있는 상황을 파악
 다양한 OS와 하드웨어들을 모니터링  기계들과 모니터링 툴간의 연계를 위해 XML같은 high level protocol
사용
 Overhead는 적으면서 병행 처리는 높은지를 모니터링하려면 성능(Performance)은 핵심 조건.
 Open source tools : Ganglia, Nagios

⑧ Analytics Engine
 빅 데이터와 기존의 BI는 공존
 서로 다른 문제에 적합한 각기 다른 접근법을 사용
 데이터 웨어하우스(DW) : 계속해서 중앙집중화된 환경에서 RDBMS 기반의 트랜잭션 데이터를 관리하게 될 것.
 하둡을 기반으로 한 분석 엔진 : 다양한 출처로부터 들어오는 물리적으로 분산된 비정형 데이터를 관리하게 될 것.
 데이터 웨어하우스와 빅데이터 저장소간에 (예를 들어, Hive/Hbase를 통해) 양 방향으로 서로 데이터 이동이
있을 때, Sqoop 같은 도구를 이용한 중개 작업이 일어남.
 실시간 분석은 웹형 어플리케이션이 만들어내는 데이터를 분석하는데 저지연(low-latency)의 NoSQL
저장소(Cassandra나 Vertica 같은)를 활용
 R이나 Madlib 같은 오픈 소스 분석 소프트웨어를 통해 개발자와 데이터 과학자들이 이 복잡한 통계
알고리즘에 쉽게 접근 가능
Big Data platform architecture

Search Engines
 어마어마한 양의 데이터를 분석하기
위해서는 blazing-fast(전광석화같은)
반복 인지형 데이터 발굴 메커니즘을
갖는 검색 엔진이 필요.
 다양한 어플리케이션으로부터
들어오는 데이터를 분석/처리하기
위해서는 indexing과 검색 필수
 전형적인 검색은 데이터베이스 행(또는
Hbase의 key)만으로는 처리될 수
없으므로 추가 필드를 사용하는 것도
고려할 필요.
Search engine conceptual architecture
DataSource
Result Display
VisualizationLayer
Search Engine
Indexing
Crawling
Hadoop Storage Layer
SearchService
Big Data Storage Layer
• Structured
• Unstructured
• Real Time
Data Warehouse
Spelling Stemming Fecting Highlighing
Tagging Parsing Semantics Pertinence
Query Processing
User Management

Real-time Engines
 웹에서 생성되는 대규모의 데이터는 아주 잠깐 동안만 가용  스키마를 미리 정할 수 없음
 Document-based system은 들어오는 트래픽에 기반하여 메시지를 보낸 다음 (response를 기다리지 않고)
신속하게 다음 기능으로 넘어갈 수 있음
 NoSQL store의 규모와 속도 덕분에 데이터가 가용한 순간에 계산이 가능
In-memory caching In-memory database
• 데이터는 최적화된 접속 알고리즘으로 메모리에서 관리됨
• 로그 파일, 데이터베이스 체크포인트 파일은 디스크에 저장
• 반복해서 접근되는 데이터는 메모리에 캐시한다
• 데이터가 서버간에 복제되거나 서로 영향을 미치지 않는다.
• It harnesses the aggregate memory of many distributed
machines by using a hashing algorithm

⑨ Visualization Layer
 너무 많은 데이터는 오히려 정보 과잉으로 부담만 됨
 빅데이터 tech stack의 통합 부분에서 초기에
시각화를 데이터를 결합함으로써 데이터 분석의
속도를 높이고 분석을 편리하게 함
 Visualization Layer로 가는 절차
① 빅데이터 하둡 처리를 통해 결과 취합
② 취합된 결과는 트랜잭션 단위로 분석하기 위해 ODS, 데이터
웨어하우스, 데이터마트로 퍼나름.
③ 이렇게 통합 정리된 데이터 위에서 visualization layer가
작동
 실시간 분석을 통한 통찰이 필요하면
 complex event processing (CEP)와
 event-driven architectures (EDAs)를 활용.
Visualization conceptual architecture
Traditional BI Tools
Structured Data
Visualization Tools
Big Data Analysis Tools
Big Data Storage layer
Unstructured
Relational Databases NoSQL Databases
Data Lakes
Data Scoop
Operational
Data Stores
Data
Warehouses

[참고] Big Data의 일반적인 Software stack
Layer Component Tools
Ingestion Layer Flume, Storm, S4, Sqoop, Chukwa, Infospehere StreamManagement
Hadoop Storage Layer NoSQL database
(database의 구분은 44쪽 참조)
Netezza, Vertica, Teradata, Google BigTable, Greenplum, Casandra,
Neo4J, OpenLink 등
Hadoop Infrastructure Layer
Hadoop Platform Management
Layer
MapReduce MapReduce, Spark, Nokia Disco
SQL Interface Hive, Impala, HAWQ, Hortonworks Stinger
Coordinator Zookeeper, Oozie
Script Pig
Administration Cloudera, DataStax, Hortonworks, IBM Big Insights
Security Layer Chef, Puppet
Monitoring Layer Ganglia, Nagios
Analytics Engines Statistical Analytics R, Pentaho, SAS, Pega
Search Engine Solr
Text Analysis
Realtime Engine In-memory cache(Terracota, EHCache), In-memory Database
Visualization Layer Hadoop Administration Cloudera, DataStax, Hotonworks, IBM Big Insights
Data Analyst IDE/SDK Talend, Pentaho
Visualization Tools Tableau, Clickview, Spotfire, MicroStrategy, SAS VA, MapR, Revolution R
Data warehouse Hive

[참고] Database Landscape
Data Grid/Cache
Non-Relational Relational
Operational
Analytic
NoSQL NewSQL
‘as-a-Service’
Key-Value
Document
Graph
Big Tables
Cloud
Enabl
ement
Data
Cache
SPRAIN
Riak
Redis
Membran
Voldemort
BerkelyDB
Piccolo Hadoop
Dryad Brisk
InterSystems
Objectivity
Progress
Versant
MarkLogic
McObject
Couchbase
Casandra Hypertable
HBase
CouchDB
MongoDB
RavenDB
Cloudant
InfiniteGraph
GraphDB
Amazon RDS
SQL Azure
Database.com
Xeround FathomDB
Lotus Notes
MapR
Hadapt
Infobright Neteza ParAccel SAP Sybase IQ
Teradata EMC Calpont IBM InfoSphere
Aster Data GreenPlum VectorWise HP Vertica
Oracle IBM DB2 SQL Server JustOne
Neo4J
MySQL Ingres PostgreSQL
SAP Sybase ASE EnterpriseDB
Akiban
MySQL Cluster
Clustrix
GenieDB
ScalArc
CodeFutures
NimbusDB
VoltDB
HandlerSocket
Schooner MySQL
Tokutek
Continuent
ScaleBase
Translattice
Drizzle
Terracotta GigaSpaces Oracle Coherence memcached
IBM eXtreme Scale GridGain ScaleOut Vmware GemFire InfiniSpan CloudTran

[참고] Hadoop Eco-system
메타 데이터 관리
(Hcatalog)
분산
데이터베이
스
(HBase)
실시간 SQL 질의
(Impala, Tajo)
정형 데이터 수집
(Sqoop, Hiho)
비정형 데이터 수집
(Chukwa, Flume, Scribe)
직렬화
(Avro)
분산 데이터 처리
(MapReduce)
분산데이터 저장
(HDFS)
데이터 분석 데이터 마이닝
(Mahout)
분산
코디네이터
(Zookeeper)
워크플로우
관리
(Oozie)
로그수집
(Chuckwa,
Flume)
Hadoop 클러스터 Provisioning, Managing & Monitoring (Ambari)
SQL 질의
(Hive)
Script
(Pig)
데이터 교환(exchange)
(Sqoop, Hiho)
※ HDFS Alternatives : AWS S3, IBM GPFS, EMC Isilon OneFS, MapR MapR File System
Hadoop

Big Data 아키텍처와 데이터 패턴
1.Data Source
5-1. Stage Transform Pattern
5-2. Connector Pattern
5-3. Near Real-Time Access
Pattern
5-4. Lightweight Stateless
Pattern
5-5. Service Locater Pattern
2-1. Multisource Extractor
Pattern
2-2.Protocol Converter pattern
2-3. Multidestination Pattern
2-4. Just-in-Time
Transformation Pattern
2-5. Real-Time Streaming
Pattern
3-1. Facade Pattern
3-2. Data Partitioning/Indexing
& Lean Pattern
3-3. NoSQL Pattern
3-4. Ployglot Pattern
4-1. Traditional Tree Network
Pattern
4-2. Resource Negotiator
Pattern
4-3. Spine Fabric Pattern
4-4. Federation Pattern
4-5. Lean DevOps Pattern
6.Security Layer
8-1. Data Queuing Pattern
8-2. Index based Insight Pattern
8-3. Constellation Search
Pattern
8-4. Machine Learning
Recommendation Pattern
8-5. Converger Pattern
9-1. Big Data Analysis Patterns
9-2. Mashup View Pattern
9-3. Compression Pattern
9-4. Zooming Pattern
9-5. First Glimpse Pattern
9-6. Exploder Pattern
9-7. Portal Pattern
9-8. Service Facilitator Pattern
7.Monitoring Layer
5.Hadoop Platform
Management Layer
8.Analytics Engines 9.Visualization Layer
4.Hadoop Infrastructure
layer
3.Hadoop Storage Layer2.Ingestion Layer

[Chapter 3]
BigDataIngestionandStreaming
Patterns

Data Ingestion(데이터 수집)이란
 나중에 사용하거나 DB에 저장하기 위해
데이터를 취득하고, 받아들이고, 처리하는 과정.
 일반적으로는 대개 여러 데이터 소스에서 처리.
데이터 소스가 늘어나면 프로세스는 더 복잡해짐.
 빅데이터에서는 원천 데이터의 구조가 알려져
있는 않는 경우가 더 많음
 다양한 데이터 유형들을 수집할 때 부딪치는
문제들:
 Prioritizing each data source load
 Tagging and indexing ingested data
 Validating and cleansing the ingested data
 Transforming and compressing before
ingestion
① Multisource Extractor Pattern
다중의 데이터 소스 유형을 수집할 때
② Protocol Converter Pattern
프로토콜 중재기(protocol mediator)를
사용하여 서로 다른 프로토콜 층에서 들어오는
데이터를 추상화할 때
③ Multidestination Pattern
Ingestion layer에서 여러 저장 공간(HDFS,
데이터마트, 실시간 분석 엔진 등)으로 데이터를
이동시킬 때 사용
④ Just-in-Time Transformation Pattern
ETL을 통해 대량의 비정형 데이터를 배치로 적재
⑤ Real-Time Streaming patterns
유입되는 데이터를 즉시 분석해야 할 업무상의
필요가 있을 때
데이터 수집과 스트리밍의 일반적인 패턴

Data ingestion layer and associated patterns
 빅데이터에서는, 수집할
때 마주치게 되는 특정
유형의 문제들을
해결하기 위해 다양한
솔루션을 사용해서
다양한 대상에 데이터를
적재한다.
 Ingestion pattern은
데이터 소스와 ingestion
layer간의 통신에서
통상적으로 마주하게
되는 문제에 대한
솔루션을 기술함
 성능, 확장성, 가용성
요건을 기준으로 솔루션
선택
Hadoop Storage
Layer
Identification
Filteration
Validation
Noise Reduction
Compression
Transformation
Integration
NoSQL Database
HDFS
DataSources
Data Mart /
Data Warehouse
Real Time
Search &
Analytics Engine
Batch Engine
Multi-Source
Extractor
Pattern
Multi-Destination
Pattern
Real-Time
Streaming Pattern
Just-in-Time
Transformation
Protocol Converter
Pattern

① Multisource Extractor Pattern
 다양한 출처, 서로 다른 형태의 데이터를 효과적으로 수집하는 방법
 공통점이 없는 데이터세트와 비관계형 데이터세트를 조사해야 하는 대량의 비정형 데이터를 갖는 기업 :
클레임, 금융거래, telecommunication, 전자상거래, fraud Detection, 소셜 미디어, 게임 등. 특히 CPU와 I/O
강도가 높은 에너지 탐사 장비나 감시카메라 장비
Multisource Extractor Pattern
② 최종 처리 후
목표시스템에 적재
① 1차 데이터 취합/정제 ■ 수집 도구/프레임웤의 기본 전제
1) 고도로 분산되어 있고
2) 대량의 데이터가 여러 노드에 걸쳐
여러 개의 Batch로 분리됨
■ 단점(약점)
• Not Real-Time : 30분에서 1시간까지 지연
• Redundant Data : 여러 enricher와 collection에
여러 벌을 복사
• High Costs : 고가용성 환경이 필수
• Complex Configuration : 배치 지향 패턴
Data source 1
Enricher 1
Enricher 2
Node
Intermediate
Collection
Agent 1
Node
Intermediate
Collection
Agent 2
HDFS
Data source 2
Data source 3
Data source 4
1
2

[참고] Enricher
 한 시스템에서 다른 시스템으로 메시지를 보낼 때 대개 받는 시스템에서는 받는 정보(즉, source
시스템에서 보낸 정보)보다 더 많은 정보가 필요
 예를 들어, 보내는 시스템에서는 customer ID만 보내주는데 받는 시스템에서는 고객명과 주소가 같이
필요. 또는 주문관리시스템에서 보내는 주문 메시지에는 주문번호만 보내는데, 받는 쪽에서는 그 주문과
연관된 고객ID가 필요해서 그 정보를 고객관리시스템에 넘겨 줄 필요가 있음
원천 메시지(=받은 메시지)에 필요한 모든 데이터가 들어있지
않을 때 다른 시스템과 어떻게 통신하는가?
 Content Enricher 같은 특별한 변환기(transformer)를
사용해서 빠진 정보를 보충해 넣기 위해 외부의 데이터
소스에 접근.
 The Content Enricher는 받은 메시지의 정보(예, key 필드)를
이용해서 외부 데이터 소스로부터 데이터를 받음. 그렇게
필요한 데이터를 받은 다음에는 받은 메시지에 첨부. 처음
받은 메시지의 정보는 그렇게 새로운 메시지로 변하게 되거나
필요없게 될 수도 있음.

② Protocol Converter Pattern
Protocol Converter Pattern
 다양한 출처에서 오는 서로 다른 프로토콜을 갖는 data source 때문에 프로토콜 변환이 필요
 다양한 프로토콜의 데이터를 해석/변환하여 공통 플랫폼에 넘겨줌
 다양한 서로 다른 메시지의 표준화된 구조가 필요  NoSQL 데이터 구조에 맞춘 표준 메시지 형태로 변환
프로토콜 변환을 위해 Ingestion
Layer에서 하는 일;
1. 들어오는 여러 이벤트 채널 식별
2. Polydata(복합데이터) 구조 식별
3. 다중 프로토콜을 적합한 장치로
전달하는 서비스 제공
4. 인터페이스 제공 : 여러 메시지
패턴을 갖는 외부 시스템을
공통플랫폼과 결합
5. 다양한 요청을 처리하는 서비스
제공
6. 다양한 프로토콜 층에서 들어오는
데이터를 요약하는 서비스
7. 들어오는 데이터를 다음 층에서
처리할 수 있는 통합 플랫폼 제공
Hadoop Storage
Layer
NoSQL Database
HDFS
Files
Message
Exchanger
Message
Exchanger
Data Mart /
Data Warehouse
File Handler
Router
S
Web Services
Byte Streams
RFID Streams
P
Web Service
Handler
Stream
Handler
Seriallizer
Async Message
Handler

③ Multidestination Pattern
 수많은 데이터 유입으로 저장 공간이 넘치는 문제, RDBMS와 분석 플랫폼이 물리적으로 분리되면서 많은
데이터가 네트워크를 통해 이동해야 하는 문제 등이 발생
 비용 늘고, 데이터 오류도 생기고, 데이터 처리에 시간도 많이 걸림
 (그래서) 데이터를 여러 데이터 저장소로 분산하여 수집(RDBMS와 NoSQL 저장소)하기 시작
 데이터 이동을 HDFS 스토리지 안에서 할 수 있게 되고, Hive나 Pig를 사용하여 데이터 분석.
Multidestination Pattern
Subscribing destination
Enrichers는 publisher뿐만
아니라 subscriber에서도
필요하게 사용될 수도
있음
※ The destinations
have to register with
the publishing agent on
the router.
등록된
목적지(destination)
수와 데이터 양에 따라
라우터를 하나의
클러스터에 배치 할
수도 있음
Hadoop Storage
Layer
NoSQL Database
HDFS
Data source 1
Enricher 1
Enricher 2
Data Mart /
Data Warehouse
Node
Intermediate
Collection
Agent 1
Node
Intermediate
Collection
Agent 2
Router
S
Data source 2
Data source 3
Data source 4
Search &
Analytics Engine
P
S

④ Just-in-Time Transformation Pattern
 모든 원천(raw) 데이터를 HDFS로 모은 다음 업무상 용도에 따라 관련 전처리 배치 작업을 실행하여 데이터를
정제하고, 검증하고, 관련있는 것끼리 묶고, 변환함
Raw data as well as transformed data co-existing in HDFS
※ 변환된 데이터의 일부는 HDFS에 그대로 남거나(1),
일부는 분석 등을 위해 다른 저장소로 이동(2)
Data source 1
Enricher 1
Enricher 2
Node
Intermediate
Collection
Agent 1
Node
Intermediate
Collection
Agent 2
HDFS
Data source 2
Data source 3
Data source 4
1
Transformed Data 1
Transformed Data 2
Transformed Data 3
1-1
1-2
1-3
Raw Data
Data
Mart
DW
Real-time
Analytics
Engine
2

⑤ Real-Time Streaming patterns
 자급자족하고 지연 시간을 최소화하기 위해 개별 처리
노드의 로컬 메모리 사용
 비공유(share-nothing) 아키텍처 : 모든 노드는
개별성(atomic responsibilities)을 가지며 서로 의존하지
않음
Real-Time Streaming pattern
실시간 스트리밍 수집 시스템의 특성
Create
event
Business
Process
Engine
NoSQL Data
Sources Event
Processing
Node
Event
Processing
Node
Alerter
Click Stream
Data
Log Streams
RFID Streams
P
Event Listener
Event
Processing
Engine
Event Listener
Event
Processing
Engine
Coordinator
Mobile
Dash
board
BAM
redirect
 실시간 정보를 빠르게 분석할 수 있는 API 제공
 원자성은 클러스터 내 시스템 확장시에도 부품별로
일어남을 의미
 중앙의 마스터 노드 없음. 모든 노드는 하나의 스크립트로
배포할 수 있어야 함.

[참고] 스트리밍 데이터 처리 도구
Apache Sqoop
• 하둡 빅데이터 노드와 관계형 데이터베이스 간에 대량의
(반정형, 비정형) 데이터를 이동시키는 도구
Chukwa
• 로그 기반의 데이터를 분석하고 모니터링하는 분산시스템.
• 여러 기계에서 점진적으로 생성된 로그를 모니터링, 처리
• 덧붙이기(appending) 기능 제공
• 데이터를 수집하는 단계와 처리하는 단계를 파이프라인
형태로 구조화  각 단계 사이에는 제한된 수의
인터페이스만을 제공
Apache Kafka
• 대용량 분산 메세징 시스템 : LinkedIn에서 자사의 내부
데이터 처리를 위해 개발
• 메시지를 파일 시스템에 저장
• 주요 기능 : I/O 성능 최적화를 위해 압축 사용, 가용성을
높이기 위해 미러링, 확장성 개선, 다중 클러스터
상황에서의 성능 최적화
배치 처리 상태의 파일을 다루는 도구
Flume
• 다양한 Source에서 발생된 많은 양의 로그 데이터를
수집하고 병합해서 HDFS로 써 주는 분산처리 시스템
Storm
• 이벤트 처리 시스템(event-processing system) : 확장성과
신뢰성을 위해 서비스 클러스터를 사용
• 실시간 스트리밍 기반 데이터 분석 기술 : 다양한 경로를
통하여 유입되는 데이터 중에서 특정한 이벤트를 찾아서
처리
InfoSphere Streams
• (텍스트, 이미지, 음성, 이메일, 센서, 금융거래데이터 등의)
이질적인 데이터 유형에 대한 복잡한 분석을 수행
• 디지털 필터링, 패턴/관계 분석, 분해, 기하공간 분석 등을
활용하여 규칙적으로 생성된 데이터의 실시간 분석과 미래
예측을 수행
실시간 스트리밍 데이터를 다루는 도구

빅데이터용 ETL Tools
 데이터 웨어하우스에서 요구하는 형태대로 데이터를 이행하는 데 사용
 이행은 실제로는 데이터가 데이터 웨어하우스에 적재되기 전에 중간 지역에서 이루어짐
Hadoop Storage
Layer
NoSQL Database
HDFS
NoSQL Data
Sources
Enricher 1
Enricher 2
Data Mart /
Data WarehouseInformation
Staging Server
Node
Intermediate
Collection
Agent 1
Node
Intermediate
Collection
Agent 2
Router P
S

[Chapter 4]
BigDataStoragePatterns

Analytics Engines
Data
Source
Hadoop Platform Management Layer
Visualization Layer
RelationalDB
IngestionLayer
Monitoring Layer
Security Layer
Hadoop InfrastructureLayer
Hadoop
Storage
Layer
Data Warehouses
UnstructuredData
NoSQL Database
HDFS
Analytics
Appliances
Big Data Storage Patterns
 ….
HDFS가 전통적인
DW 시스템을 위한
intermittent façade
역할 수행
Façade
Pattern
Lean
Pattern
NoSQL
Pattern
Polyglot
Pattern
빅 데이터 문제를
해결하기 위해 다양한
형태의 스토리지
메커니즘(RDBMS, 파일
스토리지, CMS, OODBMS,
NoSQL, HDFS)이 공존
빅 데이터에 접근하고
쿼리를 날리기 위해
전통적인 RDBMS
시스템이 NoSQL로
대체
HBase 는
column-family
하나, column 하나,
unique row-key를
사용해서
인덱싱됨.

① Façade Pattern
 한 서브시스템 내의 인터페이스 집합에 대한 획일화된 하나의 인터페이스를 제공하는 패턴으로,
서브시스템을 사용하기 쉽도록 상위 수준의 인터페이스를 정의 하는 것.
 시스템을 서브시스템으로 구조화하여 복잡성을 줄이고 서브시스템들 사이의 통신과 종속성을 최소화
 기존의 DW 인프라와 프레임워크를 그대로 사용 가능
장점
 서브시스템의
구성요소를
보호함으로써
사용자가 다루어야 할
객체가 줄어든다
 다루어야 할 객체가
줄어듬에 따라
서브시스템과
사용자간의 결합도가
약해진다
다양한 출처에서 들어오는 데이터(=비정형
데이터)를 HDFS에 다 모은 다음
변환해서(=정형 데이터) DW로 적재
Data source 1
Sqoop
Data source 2
Data source 3
Data source 4
Existing DW
Implementation
INGESTION
HDFS
Data
Node
Data
Node
Data
Node

② Data Partitioning/Indexing & the Lean Pattern
 HDFS 기반의 NoSQL 데이터베이스에서는 partitioning 강추
 왜냐하면, HDFS는 폴더 구조라서 데이터가 time-stamp, 위치 등의 파라미터를 가지고 따라 여러 폴더에 분산
또는 분할(partition) 저장.
 Data indexing is applicable to NoSQL databases, like HBase, that are HDFS aware and compliant.
데이터셋을 식별하는 방법
3) Lean pattern—HBase implementation with
only one column-family and only one column
and unique row-key
1) HBase implementation with only one
column-family and multiple columns
2) HBase implementation with multiple
column-families and multiple columns

③ NoSQL Pattern
 NoSQL 데이터베이스가 하둡에서 하는 역할
1) (비정형) 데이터를 HDFS뿐만 아니라 로컬 NFS 디스크에 저장
2) HDFS-aware : 데이터 노드간에 데이터를 분산 저장하고 접근할 수 있도록 함
Hbase 관점에서 본 NoSQL Storage Access Pattern

[참고] NoSQL DB의 용도
NoSQL DB 종류 작동 방식 시나리오(용도) 제품
Graph Database • data entities와 connections을 nodes와 edges로
저장
• 네트워크 DB와 비슷
• shortest paths 계산, social network 분석 등
Applications that provide evaluations of “like” or
note that “user that bought this item also
bought,” like a recommendation engine.
Neo4J, Hyper
Graph DB, Info
Grid, OpenLink
InfiniteGraph,
AllegroGraph
Key-Value Pair
Database
• Key-value 쌍으로 데이터 저장
• Key는 유일값이며 Foreign key 없음
• relationship 없음  병렬 lookup에 적합
• 데이터 통합성은 front-end applications에서 관리
Needle-in-a-haystack applications. MemCached, Riak,
Redis, V,
Membase
Document
Database
• text, media, JSON, XML 데이터를 저장
• The value in a row is a blob of the
aforementioned data and can be retrieved using
a key.
Applications that evaluate churn
management(이탈고객관리) on the basis of non-
enterprise and social media data.
(여러 문서에서 특정 string 값을 검색하는 경우)
CouchDB, Raven,
mongo DB,
Cloudant,
MarkLogic,
Terrastore
Columnar
Database
• 개별 tuple에 엄청 많은 수의 컬럼이 있음
• 각각의 컬럼은 column key를 가짐.
• 관련 컬럼은 column-family qualifier를 가지고
있어서 검색시 함께 조회됨
Google search type of applications, where an
entire related columnar family needs to be
retrieved based on a string.
Hadoop, Hbase,
Greenplum,
Amazon SimpleDB
Vertica, Cassandra,
Azure, HyperTable
Netizza, Terradata,
BigTable,

[참고] NoSQL Family Tree
오픈소스 커뮤니티 유형
유즈케이스
Foundation backed
Single vendor
Analytics Data warehouse
Operational database
Caching
Paper

④ Ployglot Pattern
 어플리케이션을 통해 저장되는 되는
데이터의 유형이 텍스트에서 다른 비정형
형태까지 다양하게 있으므로 데이터는
RDBMS, CMS, Hadoop과 같은 다양한 곳에
저장될 수 있음
 Use case에 따라서 저장 메커니즘은
RDBMS에서 NoSQL db, CMS까지 다양하게
사용할 수 있음

[Chapter 5 ]
BigDataAccessPatterns

Hadoop에서 데이터를 다루는 방법
 접근하는 데이터의 종류
 Incremental data
 Selective/filtered data
 Near real-time data with low latency
 데이터에 접근하는 방법(form)
 End-to-End User Driven API: users to write simple queries to produce clipped or aggregated output
and throw on a visual display.
예) Google Search is an example where the query results are abstracted from the user and the results are fetched using
BASE (basically available soft state consistent eventually) principles. Google gives users the opportunity to enter a
query according to a set of Google-specified query rules, and it provides an output without exposing the internal
mechanism of the query processing.
 Developer API: Individual developers can interact with the data and analytics service. These services
might be available in SaaS (software as a service) formats.
예) Amazon Web Services (AWS). The API enables querying of the data or the summary of the analytics transactions.

Big Data Access의 이해
 Data Access Pattern은 거기에 맞는 Data Storage pattern과 결합하여 함께 사용되어야 함
ETL
Data Service 2
(예, 트위터)
Data Service 1
(예, Facebook)
Service Catalog
Data Source1
+
Data Source2
Data Source1
+
Data Source
1 + 2 + 3
HDFS
Data
Visualization
Reports Search HTTP
CacheCache
NoSQL
Database
Big Data Appliance
Service
Locator
Pattern
Lightweight
Stateless
Pattern
Near
Real-time
Pattern
Stage
Transform
Pattern
Connector
Pattern

Big Data Access Patterns과 유즈케이스
Access Pattern 설명 Use Case
Stage Transform
Pattern
uses the end-to-end user API approach and
presents only the aggregated or clipped
information in the NoSQL layer (Stage) after
transforming the raw data.
Search, Data Visualization, Reports
• 여러 관점에서 데이터를 시각화할 때(Connector pattern과 결합하
여 사용)
• (Hbase 통하지 않고) NoSQL 데이터베이스에서 직접 보고서 추출
• useful for rapidly searching data that has been abstracted from
HDFS data storage into the NoSQL layer.
Connector Pattern uses the developer API approach of using APIs for
accessing data services provided by appliances.
Bulk Data, Data Visualization
• XML 형태의 bulk 데이터 처리.
• 여러 관점에서 데이터를 시각화할 때(Storage Transform pattern
과 결합하여 사용)
Lightweight
Stateless Pattern
uses lightweight protocols like REST, HTTP, and
others to do stateless queries of data from the big
data storage layer.
Data Discovery
• RESTful 서비스를 사용하여 여러 데이터 소스로부터 데이터 발견
(Data Discovery)
Service Locator
Pattern
A scenario where the different sources of
unstructured data are registered on a service
catalog and dynamically invoked when required.
Enterprise-wide Dashboard
• collates data from applications across the organization using the
catalog of services available from the API management software.
Near Real-Time
Pattern
works well in conjunction with (and is
complementary to) the data ingestion pattern
“just-in-time transformation.”
Search

① Stage Transform Pattern
 HDFS가 모든 원 데이터를 갖고 있으며, NoSQL 데이터베이스에서는 업무 목적의 데이터만 가져와서 사용
(Hbase, MongoDB, Riak, Vertica, neo4j, CouchDB, Redis 등과 같은 NoSQL 데이터베이스)
 For example, for implementing data discovery for a retail application that depends on social media data,
enterprise data, historical data and recommendation engine analysis, or abstracting data for a retail user or
users, a NoSQL database makes the implementation of a recommendation engine much easier.
 NoSQL Storage pattern과 결합하여
NoSQL DB에서 사용자 데이터를 추출하고
저장하는데 사용할 수 있음
 추출 데이터는 추천 엔진에서 사용하며,
데이터 검색 시간을 획기적으로 줄여줌
오래 걸리는 배치 프로세스를 통해서 뽑아내는 데이터(원 데이터 전체)
자주 사용하는
데이터만 뽑아옴
NoSQL
Database
HDFS
추천 엔진
Application
 Enterprise Data
 Social Media Data
 Historical Data

② Connector Pattern
 데이터 접근/이동을 가속화하고 Developer API를 사용할
수 있는 appliance 있나?
 EMC Greenplum, IBM PureData (Big Insights + Netezza),
HP Vertica, and Oracle Exadata 등
• 성능 완전 빵빵. 데이터는 HDFS에 저장하지만 NoSQL
데이터베이스에서 추출.
• GreenPlum은 데이터 접근 향상을 위해 자체의
파일시스템(OneFS)을 가지고 있음
• 시각화 지원 : 개별 노드/디스크는 분산 데이터베이스에 있는
VM
• RAID 같은 프로토콜을 사용해서 데이터 중복과 복제
 데이터에 접근할 수 있도록 developer-usable API와 SQL
비슷한 쿼리 언어를 제공.
 개발 시간을 획기적으로 줄이고 전문 기술(niche skill)로
자원 식별을 불필요하게 만든다.
VM VM VM

③ Lightweight Stateless Pattern
 WebHDFS를 사용해서 RESTful HTTP를 호출하여
HDFS에 있는 파일에 접근
 WebHDFS는 웹서비스의 일종  자바나 다른
언어로 개발하는 데 제한 없음
 For a cloud provider or an application wanting to
expose its data to other systems, this is the
simplest pattern.
 HDFS systems expose RESTful web services to
the consumers who want to analyze the big data.
 점점 더 퍼블릭 클라우드 환경이 이 서비스 채택.
 Integration Platform as a Service (iPaaS)의 시작.
 빅데이터 분석에 사용한 만큼만 지불하게 되므로
장비를 직접 소유하는 데 따른 비용 절감
HTTP Service Interface
for HDFS
(REST protocol)
HDFS
Lightweight Stateless pattern for HDFS
CLOUD

④ Service Locator Pattern
 여러 스토리지가 있는 경우, 특정 스토리지만 선택하려고 할 때는 어떻게?
 For a storage landscape with different storage types, a data analyst needs the flexibility to manipulate ,
filter, select, and co-relate different data formats. Different data adapters should also be available at the
click of a button through a common catalog of services. The Service Locator (SL) pattern resolves this
problem where data storage access is available in a SaaS model.
 서로 다른 데이터 소스는 서비스 카다로그 상의 하나의 서비스로써 노출됨.(권한있는 데이터 분석가에게만
보여짐).  기업 안팎 모두 가능
 복수의 시각화 도구를 통해 이 서비스들을 동적으로 합치거나 연결함으로써 기업 데이터뿐만 아니라 소셜
미디어 데이터를 보여줄 수 있음.

④ Service Locator Pattern
Data source 1
Data source 2
Data source 3
HDFSEnterprise
Internet
Social Media
Service Facilitator
Service Catalog
Data Source 1
+
Data Source 2
Data Source 1
+
Data Source
1 + 2 + 3
Visualization 1
Visualization 2
Service Locator Pattern for HDFS

⑤ Near real-time Pattern
 수집, 저장, 데이터 접근이 하나의 경로(pipe)로
죽 이어질 때 준실시간 데이터 접근이 가능해짐.
 여러 스토리지에 있는 데이터들은 이미 다
걸러지고 정렬된 상태여야 함
 어플리케이션 로그 검색
 분석에 필요한 정보는 빠르게 접근할 수 있는
cache에 저장
90%의
noise
data를
제거한
순수한
데이터
(NoSQL DB, memcache
등의 형태)
“Near real-time” 접근이란?
• Extremely low latency in capturing and processing the data.
• Analyzing the data in real time
분석
HDFS
Solr Search
Engine
Cache
INGESTION
Filter
Metadata
Near Real-Time Access Pattern using multicache

[Chapter 6 ]
DataDiscovery&AnalysisPatterns

Analysis Patterns
빅데이터 분석 = 고객 행동에서 통찰력 있는 패턴을 찾아내고 해석하려는 시도
Social Media
RDBMS /
NoSQLEmailDocuments
Logs
CACHE RFID Meter Data
Analysis Tools
(Attensity, Radian, Solr 등)
HDFS
Visualization Tools
Machine Learning
Recommendatio
ns Pattern
Converger
Pattern
Constellation
Search Pattern
Index Base
Insight Pattern
Data Queuing
Pattern

빅데이터의 발견과 분석
빅데이터 분석 = 고객 행동에서 통찰력 있는 패턴을 찾아내고 해석하려는 시도
Document Natural language processing
비정형 데이터의 종류
비정형 데이터를 분석하는
통계방법
Application Log Text mining
E-mail Linguistic computation
Social media forum
(트위터, 페이스북 등)
Machine Learning
Machine generated data
(RFID, 날씨데이터 등)
Search and sort algorithms
Syntax and lexical analysis
Data Queuing Pattern:
데이터가 분석되는 동안 spike 처리하는데 사용
A lightweight process or workflow is required to queue the additional
chunks of data and then route them to available nodes.
비정형 데이터를 분석하는 통계방법
Index-based Insight Pattern:
사용자로부터 들어온 정보에 기반하여 인덱스 정의
점점 더 많이 데이터가 인덱스의 범위를 결정하게 되면서 인덱스는
반복적으로 조정됨
Constellation Search Pattern:
MDM 개념 활용 : 일련의 변수가 반복 발생되는 것을 확인하기 위해
constellation of 메타데이터를 사용
Constellation은 반복해서 재정의되며 다시MDM 시스템에 추가
Machine Learning Pattern:
통계와 수치분석 알고리즘을 사용하여 기기가 만들어낸 데이터의 패턴 식별
(energy meters, 날씨관련 장비, RFID feeds 등)
Converger Pattern:
비정형 데이터를 분석하여 정형 데이터와 결합할 때 기업 차원의 의사결정이
필요

① Data Queuing Pattern
 불연속적으로 쏟아져 들어오는 빅데이터에 대해 어떻게
분석도구를 가지고 관리할 수 있을까?
(예, Events like professional football or rock concerts trigger
a lot of activity in different forums and email groups. It is also
the right time to roll out offers and promotions.)
 Infrastructure as a Service(IaaS) 솔루션
 A simple lightweight workflow to queue the additional data
chunks and orchestrate the assignment of analysis to the
nodes that are free is required in the architecture. There is
also a need for spining new virtual machines, on demand, to
address the new capacity requirements dynamically.
 The data queuer that sits above the HDFS layer allows us to
provision and orchestrate the analysis payload so that it does
not interrupt the analysis tools and provides a seamless
interface.
Data queuer
Streamless interface
Visualization Tool
HDFS
Node 1 Node…n
Analysis Tools
(Attensity, Radian, Solr 등)

② Index-based Insight Pattern
 모니터링하고 싶은 몇 개 유형의 파라미터를 설정할
때
 The above problem requires an efficient key / index
lookup that provides rapid scanning and also helps to
keep related column families together. This is a
pattern used by many analysis tools to build indexes
and enable rapid search. Indexes can be used along
with zones and/or partitions to improve performance
of ‘read’ requests.
 As data grows and read requests vary, more indexes
need to be incorporated based on the most
frequently ‘read’ data attributes.

③ Constellation Search Pattern
 빅데이터 소셜 미디어 분석 사례의 일부는 집중해야 할 사용자 그룹을 식별하는데 도움.
 데이터를 묶는 기준은 마스터 데이터 : 빅데이터에서는 분산 마스터데이터를 추구 (D-MDM).
 Master data는 변수들 사이에서 데이터의 constellation을 생성하는 데 이용. 데이터의 레벨별로 다양한
추상화 수준의 constellation이 있음
 Constellation은 소셜 미디어 데이터에 대한 기계학습 패턴을 통해서 얻어짐.
Data source 1
Data source 2
Data source 3
HDFS
R
Algo 3
Algo 1 Algo 2
HDFSAdapter
Algo 4
VISUALIZATION
Data Scientist
Enterprise
Internet
Social Media
Constellation
 페이스북의
‘모래사장에서
바늘찾기’
아키텍처 =
인메모리 인덱스 +
Metadata

④ Converger Pattern
 내부 데이터와 소셜 미디어 데이터를 결합하여
기업이나 제품헤 대한 소비자 감성에 더 많은
통찰력을 제공할 필요.
 기업 내/외의 정보를 결합하는 아키텍처 필요
 분산 MDM(D-MDM)을 통해 외부 데이터의 포맷을
변환하고 공통 관련 데이터를 결합
 데이터의 수렴(집중)은 데이터가 분석되기 전에
이루어져야 함.
 ‘Facade Data storage’ pattern과 함께 사용될 수
있음
Converger Pattern
Traditional BI Tools
Structured Data
Visualization Tools
Big Data Analysis Tools
Big Data Storage layer
Unstructured
Relational Databases NoSQL Databases
Result
Dataset
Converge
Operational
Data Stores
Data
Warehouses

⑤ Machine Learning Recommendation Pattern
 수많은 출처로부터 쏟아져 들어오는 막대한 양의 다양한 데이터를, 사람의 손을 거치지 않고 자동으로
의미있는 정보로 변환하는 것
 통계적 방법과 알고리즘 사용
 kNN Classification algorithm : 분류되어있지 않은 레코드들을 분류된 레코드들 중 가장 비슷한 속성을
가진 레코드로 할당
 Time decision trees
 Bayesian decision theory (베이시안 의사결정이론) : 미리 알고 있는 정보를 통해 의사결정
 Regression coefficients (회귀계수) : 회귀방정식에서 독립변수의 계수
 Apriori algorithms : 빈번하게 일어나는 데이터 항목 찾기

기타 이슈들
 공통점이 없고 불충분한 데이터
 정밀한 데이터 정제과정 필요
 데이터 양의 수시 변화
 Data queuing pattern과 결합된
클라우드 인프라 활용
 개인보안성의 문제
 개인정보의 보호는 법으로
강제되고 있음
 (DaaS 활용에 따른) 성능 문제
 독창적인 방법이 필요
빅데이터 분석의 문제들
 실시간으로 생성되는 어마어마
하지만 내용 구성이 서로 다른 로그
파일
① 로그의 속성 식별
② 예외 기록
③ 데이터 매핑 속성 생성
④ 원 데이터를 반복적으로 조사해서
이벤트 빈도와 예외 빈도 탐색
⑤ 데이터 기간 선택
⑥ 반복되는 이벤트 범주를 찾아서
연결
⑦ Fine tune the categories with
every search
⑧ 반복실행을 통해 안정화된 속성과
카테고리 분석 실행
로그 파일 분석
 소셜 미디어에 포함된 기업이나
제품에 대한 소비자의 감성(신뢰도),
의견 등을 분석
 분석 대상 : 단어의 출현 빈도,
대화의 일부분, 문장에서 negation
syntax의 사용과 단어의 위치 등의
비율이나 강조 범위
 그러나, 소셜 미디어에는 비속어와
문법에 맞지 않는 내용이 많다
 기법 : Bayes 이론, 엔트로피와 벡터
분석
 도구 : Splunk
감정 분석

[Chapter 7 ]
BigDataVisualizationPatterns

Big Data analysis and Visualization Patterns
Data source 1
Data source 2
Data source 3
HDFS
R
Algo 3
Algo 1 Algo 2
HDFSAdapter
Algo 4
VISUALIZATION
Data Scientist
Enterprise
Internet
Social MediaExploder
Pattern
Zooming
Pattern
First
Glimpse
Pattern
Portal
Pattern
Mashup
View
Pattern
Compression
Pattern

Big Data analysis and Visualization Patterns
Visualization Pattern 설명 Use Case
MashupView Pattern HIVE에 mashup view를 한 데 모아 저장해서 쿼리
성능을 최대화한 것. DW(Hive)를 오프라인으로
업데이트 하기 위해 MapReduce 작업이 배치로 실행됨
 시각화와 분석 도구들은 Hive의 쿼리를 통해서 Hadoop과 통신
 그런데 Hive는 JOIN이나 AGGREGATION 같은 쿼리를 실행하기에는
부적합하므로 Hadoop 자체나 abstracted storage에 mashup view를 생성
※ Mashup view = MapReduce 실행 결과를 취합해 놓은 것
Compression Pattern 더 빠르게 접근할 수 있도록 압축, 변환, 하나의 형태로
데이터 서식 지정
 데이터를 취합하거나 매쉬업 하지 않고도 빠르게 접근도록 분석되기 전에
분석도구가 이해할 수 있는 압축 포맷으로 변경(예, R의 .xdf 포맷)
 성능 향상, 데이터 검증, 데이터 교정과 일관성 확인 가능
Zoning Pattern 더 빠르게 접근할 수 있도록 다른 zone의 다양한
속성으로 쪼개고 색인 처리
 데이터가 가진 속성에 따라 특성별로 구분하여 저장(partitioning)
 Hadoop, abstracted storage, 캐쉬, 시각화 클러스터 등 각 층(layer)에
데이터 특성별로 zone으로 구분  필요한 데이터만 검색
First Glimpse Pattern 시각화를 최소화하여 가장 관련있는 정보를 한눈에
보여줌. 필요하면 확장해서 더 상세한 데이터 볼 수
있음.
 엄청 많은 데이터를 시각화 해야 하므로 아주 필수 정보만 한 눈에 확
들어오도록 하는 패턴(‘lazy-loading”)
 그 다음부터는 드릴 다운을 통해 상세로 이동
※ lazy-loading : 오브젝트의 인스턴스를 필요 시만 메모리에 생성하는 기법
Exploder Pattern First Glimpse pattern의 확장형으로 다른 소스의
데이터를 서로 다른 시각화 관점으로 볼 수 있게 함.
 다른 출처에서 데이터를 가져오거나 다른 인덱스된 데이터 셋을 하나로
모아서 보여준다.
 다른 데이터셋을 보고, 서로 연관관계를 파악하고, 다른 관점으로도
시각화하고..
Portal Pattern 빅데이터 시각화를 위해 기존의 기업 포털 사용  D3.js 같은 스크립팅 프레임워크를 사용하여 현재의 포털의 기능을
강화하여 재사용
Service Facilitator
Pattern
빅데이터 분석 프로젝트를 위해 임시로 빌려서
사용( pay-as-you go approach)

[Chapter 8]
BigDataDeploymentPatterns

Big Data Infrastructure의 구성
• Storage
• Network
• Processing power unit
data traffic from
multiple data centers
and infrastructure for
uploading data to
downstream systems
and/or a data center
might be needed • 데이터와 메타데이터를 저장
• Appliances
• NoSQL data storage
Additional
Infrastructure
Security
Infrastructure
Hadoop
Cluster

Traditional Tree network pattern
 데이터를 병렬로 받아서 Hadoop 시스템에 병렬로 넘기기 위해, 여러 agent들을 여러 노드들로 채널화하는
프레임워크를 사용(예, Flume, SFTP 등)
Data source 1
Data source 2
Data source 3
Data source 4
Tree Trunk
Branch 2
Branch n
Ingestion
Data Node Data Node Data Node
Branch 1
Ingestion
Ingestion Data Node Data Node Data Node
Hadoop Ecosystem

Resource negotiator pattern
 Hadoop ecosystem과 분리된 방화벽 밖의 네트워크 망에서 클라이언트의 데이터를 안전하게 수집
 데이터 수집 배치 작업과 Negotiator node의 배치 작업을 분리
SecureAccessoverVPN
Data source 1
Data source 2
Data source 3
Data source 4
Ingestion
Negotiator
Ingestion
Negotiator
Ingestion
Ingestion
Ingestion
Hadoop Ecosystem
DMZ
Negotiator Node
안정적인
상태에서의
데이터 수집

Hadoop storage replacing resource negotiator
 Hadoop ecosystem이 ingestion negotiator 역할을 수행
SecureAccessoverVPN
Data source 1
Data source 2
Data source 3
Data source 4
Ingestion
Ingestion
Ingestion
Ingestion
Ingestion
Hadoop Ecosystem
DMZ
Data Node Data Node
Ingestion

Spine Fabric Pattern
Data Center 1
Data
source 1
Data
source 2
Data
source 3
Data
source 4
Ingestion
Ingestion
Data Node Data Node
Ingestion
Data Node
Data Centre 6
Data Center 2
Data Center 4
Data Center 3
Data Center 5
Spine Hadoop Ecosystem
Redirect
Process
Target Hadoop Ecosystem
Aggregate and
Process
OR
Redirect to other
Data Centers
 서로 다른 데이터 출처들로부터 오는 관계로 보안 수준이 서로 다른 채로 유입되는 데이터의 처리
Source 데이터 센터와 목표 데이터 센터가
분리됨으로써 deployment pattern의 변경 없이도
새로운 소스가 쉽게 수집될 수 있음
목표 데이터 센터

Federation Pattern
 다양한 출처로부터 온 데이터를 구역으로 나누어 저장하고 처리
Data
source 1
Data
source 2
Data
source 3
Data
source 4
Ingestion
Ingestion
Data Node Data Node
Ingestion
Data Node
Data Centre 6
Data Center 2
Data Center 4
Data Center 3
Data Center 5
Hadoop Ecosystem
Redirect to other
Data Centers
Federation Pattern

Lean DevOps Pattern
 인프라와 클러스터를 VM 처럼 자동으로 생성
 Agile IaaS 스크립트를 사용하여,
1) 인프라와 어플리케이션 환경 설정용 템플릿을 새작성하고,
2) 필요하면, 전체 VM 클러스터나 인프라를 재생성할 수도 있음
Self-Service Portals
Template Catalogs
Templates
Virtualization
Hardware
DevOps Scripts

[Chapter 9]
BigDataNon-Functional
Requirements

Big Data 아키텍처에서 꼭 고려해야 할 요소들
Reliability (신뢰성)
Reliability is the ability of the system
to be predictable and give the desired
results on time and every time. It is
related to the integrity of the system
to give consistent results to every user
of the system.
Scalability (확장성)
The ability of the system to increase
processing power within the same
machine instance (vertical scaling) or
to add more machine instances in
parallel (horizontal scaling) is called
scalability.
Operability (운영안정성)
Once in production, how amenable the
system is for monitoring every aspect
that could affect the smooth
operations determines its operability.
Maintainability (유지보수성)
A system is highly maintainable if
defects, change requests, and
extended features can be quickly
incorporated into the running system
without affecting existing
functionality.
Availability (가용성)
Metrics like 99.999 and 24*7 are used
to define the availability of the system
for the users so that there is no
downtime or very little downtime.
Security (보안)
Distributed nodes, shared data, access
ownership, internode communication,
and client communication are all prime
candidates for security vulnerabilities
that can be exploited in a big data
system

Big data application architecture 요약2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Big data application architecture 요약2

Similar to Big data application architecture 요약2 (20)

Big data application architecture 요약2