Rankwave moment™ desc3

MOMENT™
Solu,on
Descrip,ons
1
Big-‐data
Analysis
Pla0orm

Contents
• Features
of
MOMENT™
• Archtecture
• System
Topology
• Performance
• Roadmap
2

4
Features
■ As
fast
as
possible
-‐ In-‐memory
compuFng
■ Easy
scalable
-‐ Auto
scaling
based
on
cloud
system
-‐ Auto
aging
data
-‐ Auto
load
balancing
■ Real-‐Fme
query
-‐ Direct
query
from
cluster
-‐ Easy
query
language
-‐ Streamming
data
query
■ Failover
-‐ ReplicaFon

5
As
fast
as
possible
우리가 사용할 수 있는 시스템이 Von
Neumann
Architecture
라면,
Process
가 수행하는 연산은 결국,
CPU
와 Memory
사이에 일어나는 것
이다.
따라서,
Process
가 가장 빠르게 연산을 수행하려면,
연산하려는 그 순간, 데이터의 위치는 File
system
이 아닌
Memory
이어야 한다.
그럼에도 불구하고,
여전히 File
system
을 사용해야 하는 이유는 확실하다.
Memory
상에 로딩된 데이터는 Process
중단과 동시에 사라
져 버리기 때문이다.
하지만,
현실적으로 판단해보자.
서비스가 안정화 단계로 진입했다는 가정은 반드시 필요하겠지만,
서비스를 운영하면서 데이터베이
스 시스템을 시시때때로 중단했는가?
메모리에 데이터를 다시 로딩하는 초기화 시간을 감수할 수 있다면,
연산 대상이 되는 모든 데이터를 Memory
에 올리는 것은 속도를
위한 최선의 선택이다.
메모리에 데이터를 로딩하는 초기화 시간은 실제 이 시스템을 사용하는 사람은 인지하지 못하는 시간이다.
그들은 데이터 로딩 시간
을 감내하는 시스템 운영자의 지루함에는 관심이 없다.
얼마나 빠르게 연산을 수행하는지가 그들이 관심을 가지는 것이다.
■
Overview
(1/5)

OperaFng
Data
#1 OperaFng
File
System
6
As
fast
as
possible
Data
#1
Process
Data
Memory
Data
#2
Data
#n-‐1
Data
#n
File
I/O
Data
#N
File
I/O
File
system
에 기반하는 경우,
데이터의 개수 만큼의 File
I/O,
즉,
File
System
에서 Process
의 Data
Memory
로 로딩하는 과정이 수행
된다.
Big
data
분석에서,
연산해야하는 데이터의 수는 대부분 전체 데이터 이다.
즉,
아래의 식에서 n
은 대부분 전체 데이터의 수이다.
…
퐿푇= Σ푖=1↑푛▒퐷푇(푖) + Σ푖=1↑푛▒푃푇(푖) 
LT
:
lead
Fme
DT
:
data
loading
Fme
PT
:
data
processing
Fme
■
Base
on
file
system
(2/5)

File
System
7
As
fast
as
possible
■
In-‐memory
type
Data
#1
Process
Data
Memory
Data
#2
… Data
#n-‐1
Data
#n
퐼푇= Σ푖=1↑푛▒퐷푇(푖) 
퐿푇= Σ푖=1↑푛▒푃푇(푖) 
IT
:
IniFalizing
Fme
LT
:
lead
Fme
DT
:
data
loading
Fme
PT
:
data
processing
Fme
Data
#1
Data
#2
Data
#N-‐1
Data
#N
…
Loading
all
data
into
memory
IniFalizing
단계에서는 File
System
의 데이터를 메모리로 로딩하는 시간이 필요하지만,
데이터를 연산할 때에는 그 시간이 필요하지
않게 된다.
(3/5)

8
■
Memory
is
expensive?
64bits
system
의 등장과 더불어 시스템의 메모리 가용 용량은 증가하였고,
그 가격은 이전과는 비교할 수 없을 정도로 저렴해졌다.
하
지만 여전히,
모든 데이터를 메모리에 로딩할 경우,
우려되는 것은 바로 Cost
이다.
아직까지 Memory
는 Disk
보다 100배,
SSD
와 비교
하면 약 10배 비싸다.
하지만,
목표하는 성능을 충족하는 조건에서 비용에 대한 비교가 되어야 한다.
현재 10배 저렴한 SSD
디스크는 약 500Mbps
의 성능을 낸다.
즉,
최대 1초에 500
M
를 처리할 수 있는데,
Tera
bytes
급의 데이터를 처리
하기에는 부족한 성능이기 때문에 불가피하게 분산 처리를 선택할 수 밖에 없다.
(1T
의 데이터를 1대의 시스템으로 처리하기 위해서는 최소 2,097
sec
가 필요하다.
1T
/
500Mbps
=
2,097
sec)
64bits
system
이라면,
이론상 16
Exabytes
의 Memory
를 사용할 수 있으나,
실제로 OS
에서 제공하는 최대 메모리는 1-‐2TB
이고,
Cloud
서
비스에서 제공하는 장비당 Max
memory
크기는 200GB
(AWS
case.)
정도이다.
따라서,
Memory
에 1TB
의 데이터를 로딩하려면 불가피하게 시스템 장비를 여러대 운영할 수 밖에 없다.
1T
데이터를 1분안에 처리하는 분산 시스템을 목표로 할 경우 필요한 분산 시스템 수는 다음과 같다.
In-‐Memory
방식의 경우 시간당 약 $
1.5
의 시스템 비용이 더 발생하고 있다.
물론,
이 수치는 데이터 처리 시간을 고려하지 않은 분산
시스템 수이고,
각각의 상황에서 필요한 CPU
수준을 고려하지 않았기 때문에,
정확한 산정은 아닐 수 있다.
하지만,
Disk
의 처리 능력을 고려했을 때,
Memory
라는 resource
가 훨씬 비싼 것만은 아니라는 결론은 얻을 수 있다.
(게다가,
AWS
의 경우,
File
I/O
회수에 따라 과금이 되기 때문에,
File
system
에 의존하는 것이 결코 저렴하지 않다.)
As
fast
as
possible
Base
on
file
system In-‐Memory
필요 대수 1T
/
500Mbps
/
60
=
30,
AWS
m3.xlarge
사용 1T
/
200G
=
5,
AWS
r3.8xlarge
사용
시스템 비용 30
*
$
0.532
(/h)
=
$
15.96
/
hour 5
*
$
3.5
(/h)
=
$
17.5
/
hour
(4/5)

9
As
fast
as
possible
Base
on
file
system In-‐memory
type
퐿푇= Σ푖=1↑푛▒퐷푇(푖) + Σ푖=1↑푛▒푃푇(푖)  LT
:
lead
Fme
DT
:
data
loading
Fme
PT
:
data
processing
Fme
퐿푇= Σ푖=1↑푛▒푃푇(푖) 
>
Big
data
분석이라는 것은 많은 양의 데이터에서 의미있는 결과를 얻어내는 과정이다.
즉,
system
이 수행해야되는 일의 n
의 값이 항상 크다는 것을 의미한다.
시스템이 보유한 데이터의 개수가 1억개라면,
매번 시스템이 연산해야되는 데이터의 개수는 1억개에 가까울 것이다.
따라서,
데이터를 미리 메모리에 로딩해두는 것이 메모리 낭비가 아닌 연산 속도를 위한 최적의 선택이라고 할 수 있다.
예를 들어,
데이터 1개를 메모리에 로딩하는 시간을 0.00001
초 라 하자.
(아마도 대부분,
이 시간보다는 훨씬 더 걸릴 것이
다.)
만약 1억개의 데이터를 연산해야한다면,
0.00001
*
100000000
=
1000
(sec),
즉,
16
분이 매번 더 필요하게 되는 것이다.
시스템이 초기화 되는데 16분을 기다릴 것인가?
아니면,
매번 시스템의 응답을 기다리는데 16분을 더 기다릴 것인가?
결론적으로,
MOMENT™
는 데이터 연산 속도를 위해,
In-‐Memory
compuFng
을 적용하고 있다.
■
Conclusion
:
In-‐memory
compuFng
for
performance
(5/5)

10
Easy
Scalable
■
Overview
Big
data
를 처리하는 시스템을 운영할 때 힘든 부분 중의 하나는 데이터 크기와 원하는 성능에 맞는 시스템 규모를 sizing
하고,
적절
한 시점에 시스템 크기를 조정하는 것이다.
대부분 이러한 시스템 증설 (혹은 감설)
작업에는 데이터를 옮기거나 삭제하는 작업이 수반되는데,
다루는 데이터가 크고 개수가 많기
때문에,
운영자의 리소스에 의존하여 운영하기 보다는 자동화를 통한 관리가 반드시 필요하다.
데이터를 에이징 작업의 경우,
에이징할 데이터의 수와 양이 크기 때문에 필요한 작업 시간이 길 수 있는데,
서비스를 중단할 수 있는
시간은 그 보다 훨씬 짧을 수 있다.
서비스 중단 없이도 에이징이 가능한 구조가 반드시 필요하며,
에이징 주기는 시스템 성능에 영향
이 없는 범위에서 짧을 수록 좋다.
Auto
scaling
을 위해서는 기본적으로 시스템 투입 및 제거가 자동화 되어야 된다는 뜻이므로,
cloud
system
을 활용하는 것이 필요해진
다.
데이터 aging
을 자동화 한다는 것은 자동으로 데이터를 삭제하는 정책을 적용한다는 것이고,
기술적으로 그것은 어려운 구현이 아니
다.
다만,
데이터가 자동으로 지워진다는 것은,
분산 시스템에서 데이터가 한쪽으로 몰릴 수 있다는 것이고,
데이터를 고르게 재 분배하는
것이 자동화 되어야 한다는 것을 뜻한다.
따라서,
자동으로 load
balancing
이 될 수 있는 시스템 구조가 필요하게 된다.

11
Easy
Scalable
■
Auto
scaling
based
on
cloud
system
Cloud
Service
를 활용하면,
데이터의 양에 따라 시스템 규모를 자동으로 조절할 수가 있다.
MOMENT™ 는 AWS
(Amazon
Web
Services)
와 연동해 자동으로 시스템 규모를 결정하고,
그에 필요한 장비를 투입하여,
가장 효율적인 시스템 운영이 가능하도록 한다.
MOMENT™ 시스템은 크게 Central
Server
와 Node
Server
로 이루어지며,
Central
서버는 Node
Server
의 Memory
Usage
Table
을 관리한다.
각 Node
의 Memory
Usage
에 따라 시스템 증설 혹은 감소를 결정하게 된다.
Data
ManipulaFon
Central
Server
Insert,
Update,
Delete
Data
Queue Data
Allocator
Table
Manager
ParFFon
Manager
Memory
Usage
Table
Table
Manager
ParFFon
Manager
Node
Server
#1
Node
Server
#10
…
Node Memory
Usage
Node#1 54%
Node#2 51%
…
Node#10 48%
AWS
EC2
SDK

12
Easy
Scalable
■
Auto
aging
data
항상 모든 데이터를 유지하면서 분석을 하면 좋지만,
시스템 자원은 항상 제한적이다.
따라서,
의미없는 오래된 데이터는 주기적으로
삭제해주는 것이 필요하다.
MOMENT™ 는 데이터 저장소와 데이터 조회 영역이 분리되어있기 때문에,
데이터 에이징을 시스템 중지 없이 처리할 수 있다.
메모리에서의 데이터 에이징 작업은 File
system
보다 훨씬 빨리 처리할 수 있고,
부하도 크지 않기 때문이다.
Auto
aging
설정은,
데이터들을 관리하는 Table
단위로 지정이 가능하다.
메모리 상의 데이터 에이징은 1)
데이터가 추가될 때,
2)
데이터가 업데이트 될 때,
그리고 3)
주기적인 Batch
작업에 의해 이루어진다.
파일 시스템상의 Raw
Data
에이징은 메모리 데이터 에이징시 발견된 대상을 에이징 큐에 기록한 뒤,
주기적인 Batch
작업에 의해 삭제
처리한다.
Table
Manager
ParFFon
Manager
Data
ManipulaFon
Queue
File
System
Data
Aging
Queue
for
File
system
Insert,
Update
Data
Aging
?
Aging
data
from
file
system
Batch
Job
Aging
data
from
memory

13
Easy
Scalable
■
Auto
load
balancing
메모리의 사용량에 따라 데이터를 Node
서버에 분산하지만,
데이터의 Update
가 일어나고,
데이터 에이징이 반복되면,
특정 Node
의
메모리 사용량이 올라가는 현상이 발생할 수 있다.
또한,
데이터의 업데이트가 반복되면서 할당된 Node
의 가용 용량을 초과하여 다른 Node
로 데이터를 이전해야되는 경우도 발생할
수 있다.
MOMENT™ 는 자동으로 데이터의 LocaFon
을 다시 할당하는 기능을 제공한다.
Central
서버는 각 노드들의 메모리 사용량을 모니터링하고,
전체 Node
의 평균 메모리 사용량보다 특정 Node
의 메모리 사용량이 일
정 비율을 초과할 경우,
자동으로 해당 Node
의 일부 데이터를 다른 Node
로 재할당하는 작업을 수행한다.
Central
Server
Data
Allocator
Memory
Usage
Table
Node Memory
Usage
Node#1 54%
Node#2 90%
…
Node#10 48%
Node
Server
#2
Table
Manager
ParFFon
Manager
Broken
balance
?
[Batch
job]
Checking
the
balance
of
memory
usage
Give
up
your
data!
Request
re-‐allocaFon

14
Real-‐Fme
Query
■
Overview
Hardoop
의 분석 Framework
인 Map,
Reduce
는 개념적으로 매우 훌륭한 framework
이다.
하지만,
Raw
Data
의 형태에 따라,
Map
을 구현
하고,
Reduce
구현하는 과정이 필요하다.
요구 사항 변경에 따라 Map,
Reduce
모듈에 대한 구현을 변경하고 Deploy
하는 과정을 거쳐야
하기 때문에 사용하기에 불편한 점이 있다.
또한,
전체 데이터를 대상으로 Map,
Reduce
를 거쳐야 원하는 결과를 추출할 수 있는 상황이 되기 때문에,
실시간†
처리는 불가능한 것
이었다.
이를 보완하기 위해,
Hardoop
framework
을 활용하면서 컬럼 기반 NoSQL
인 Hbase
가 등장하였고,
비로소 실시간 처리가 가능
한 구조가 되었다.
MOMENT™
에서도 비슷한 고민을 하였고,
우선 Memory
Map
을 활용한 컬럼 방식으로 데이터 저장할 수 있도록 설계되었다.
실시간 쿼리가 가능하도록 클러스터 간 데이터 조회를 최소화 하기 위해,
각 클러스터 마다 데이터 분석 모듈을 배치했고,
각 클러스
터의 데이터 분석 모듈은 로컬의 데이터를 조회하여 쿼리에 대한 결과를 생성하게 된다.
MOMENT™ 의 Real-‐Fme
Query
와 관련된 구현 사항은 다음과 같다.
1) 효율적인 데이터 분석을 위해 클러스터간 통신으로 데이터를 조회하지 않고,
로컬 데이터를 직접 읽도록 함
2) 프로그래밍 구현에 의한 Query
가 아닌 SQL
과 유사한 Query
language
를 통한 데이터 조회 가능
3) 스트리밍으로 들어오는 데이터를 반복해서 쿼리할 수 있는 기능 제공
[실시간]
실시간 이라는 것은 어느 정도의 시간을 뜻하는 것일까?
Impala
의 Architect
는 다음과 같이 이야기했다.
“It's
when
you
sit
and
wait
for
it
to
finish,
as
opposed
to
going
for
a
cup
of
coffee
or
even
levng
it
run
overnight.
That's
real
Fme”

15
Real-‐Fme
Query
■
Direct
query
from
cluster
전체 데이터 View
에서 Query
를 수행하는 것이 아니라,
여러 개의 Node
로,
그리고 내부에는 Table
별로 구성된 ParFFon
에서 Query
를
병렬로 수행한 뒤,
상위로 결과를 합치는 작업을 반복한다.
이 방식을 통해 응답시간을 실시간 수준으로 올릴 수 있게 된다.
이를 위해서 최종적인 데이터 조회는 ParFFon
레벨에서 이루어져야 하며,
그러기 위해서는 각각의 Node에 Query
를 수행하는 모듈이
있어야 만 한다.
클러스터에서 로컬에 있는 데이터를 직접 조회하면서 쿼리를 수행하기 때문에,
클러스터간 네트워크 통신을 최소화
할 수 있게 된다.
Central
Server
Node
Server
#1
Table
#1
ParFFon
#1
… ParFFon
#100
Query
job
for
each
parFFon
Synthesizer
Query
Processor
(Thread
pool)
Query
Processor
Synthesizer
Query
Processor
Synthesizer
Query
Processor
Synthesizer
Node
Server
#2
Node
Server
#3
Query
Processor
Synthesizer
Node
Server
#10
Broadcast
query
job
to
sub
nodes
…

16
Real-‐Fme
Query
■
Easy
query
language
MOMENT™ 는 SQL
과 유사한 형태의 Query
Syntax
를 지원해,
실시간 Query
기능을 제공한다.
현재 버전은 ANSI/ISO
SQL
Standard
와의
Compliance
를 확보할 수 있는 기본 모듈이 구현되어 있으며,
JSON
형태로 작성해 전송할 수 있다.
{
“query”:
{
“select”
:
[
{
…
}
,
{
…
}
],
“from”
:
“
Table
Name
“,
“where”
:
“
Retrieving
condiFon
“
},
“receiver”
:
{
“data_format”
:
“json_array”,
“type”
:
“direct_h{p”,
“url_format”
:
“
…
“
}
}
데이터를 조회 하고자 하는 Table
이름은 from
object
에 지정하고,
where
object
에는 조회
하는 조건을 지정한다.
논리 연산자 (|,
&),
비교 연산자 (
>,
<,
=,
<=,
>=)
를 지원하며,
우선
순위는 괄호로 묶어 지정할 수 있다.
동일한 from
과 where
로 여러 개의 조회 내용을 한꺼번에 지정할 수 있다.
select
object
은 크게,
목록을 조회할 수 있는 list,
목록 내 값의 개수를 셀 수 있는 count,
생
성된 목록에서 값의 합을 구할 수 있는 sum
type
으로 정의된다.
Query
결과를 전송하는 방법을 정의하는 object
이다.
Query
결과의 size
가 클 수 있다는 것을 고려해 크게 4가지의 receiver
를 지원한다.
1) 결과를 File
system
에 저장한 뒤,
파일을 조회할 수 있는 정보를 HTTP
방식으로 호출
2) 결과를 File
system
에 저장한 뒤,
파일을 조회할 수 있는 정보를 Queue
에 Push
3) 결과를 HTTP
Parameter
로 직접 전송
4) 결과를 TCP
/
IP
Packet
으로 전송하는 방식

17
Real-‐Fme
Query
■
Query
Syntax
select
Object
Type JSON
Array
로 Mul,
query
를 지정 가능
query_key String Query
내에서의 Unique
한 값.
결과를 리턴받을 때 어떤 쿼리에 대한
결과인지를 구분하기 위한 값.
type list column String
Array 결과를 탐색할 컬럼 정보
order_by String SorFng
을 수행할 컬럼
sort Number 오름차순,
내림차순
limit Number 조회할 결과의 최대 수
count group_by column String Grouping
할 컬럼 정보
sort Number Grouping
할 때의 SorFng
옵션
limit Number Grouping
할 최대 수
target String
Array Grouping
할 값의 목록.
해당 값만 CounFng
함.
disFnct String disFnct
처리할 컬럼명
sum group_by column String Grouping
할 컬럼 정보
sort Number Grouping
할 때의 SorFng
옵션
limit Number Grouping
할 최대 수
disFnct String disFct
처리할 컬럼명
column String 합을 구할 컬럼명

18
Real-‐Fme
Query
■
Streaming
data
query
MOMENT™ 는 축적된 데이터의 빠른 조회 뿐만 아니라,
지속적으로 투입되는 데이터의 Filtering
기능도 제공한다.
Filter
의 등록,
삭제,
수정,
시작,
중지에 대한 인터페이스를 제공하며,
수신되는 데이터에서 원하는 조건에 맞는 데이터를 필터링해 타
시스템으로 전달할 수 있다.
Data
Streaming
data
source
Queue Streaming
Filter
Processor
Data
Allocator
Synthesizer
Query
Processor
Table
Manager
Filter
Client
Regist,
Unregist,
Modify
filters
Start
filter,
Stop
filter
Query
Processor
Synthesizer
①
Data
AllocaFon
② Processing
Query
③ Filtered
result
noFficaFon
④
Clearing
data
②
Central
Server
Node
Server
#1
(Extensible)

19
Failover
■
Overview
MOMENT™ 는 raw
data
storage
가 별도 존재하고,
시스템 초기화 시에 Memory
에 로딩되기 때문에,
raw
데이터에 대한 replicaFon
은 고
려하지 않고 있다.
(AWS
의 S3
의 경우,
data
integrity
를 보장하고 있다.)
MOMENT™ 내부 시스템에서 데이터 유실시 시스템 초기화가 불가능한 부분에 대해서는 별개의
system
에 replicaFon 함으로써
Failover
되도록 하고 있다.
또한,
In-‐Memory
compuFng
방식이기 때문에,
할당된 데이터를 로딩해 시스템을 초기화 하는데에는 시간이 오래 걸리는 단점을 가지고
있다.
이런 단점을 극복하기 위해,
로딩할 데이터를 Local
File
DB
에도 저장하며,
이 File
DB
는 별개의 시스템에
replicaFon
되도록 설정
할 수 있다.
Failover
를 위해 replicaFon
을 구성하는 곳은 다음과 같다.
1) Central
Server
의 Data
allocaFon
정보
2) 로딩할 데이터의 Raw
data
경로
3) 로딩된 데이터의 Hash
value
(CRC32)
4) 로딩된 데이터의 Local
Cache
DB

20
Failover
■
ReplicaFon
MOMENT™ 에서 사용하는 Local
File
DB
는 Oracle
Berkeley
DB
를 사용하고 있으며,
Berkeley
DB
를 online
relicaFon
이 가능하도록 구현되
어 있다.
Master
로 들어온 Event
는 ReplicaFon
Manager
에 의해 Remote
system
의
Event
queue
로 전달되며,
Slave
의 처리에 대한 응답을 받고
난 뒤,
local
database
에 반영한다.
만약 Master
가 동작하지 않는 경우,
Database
Access
module
은 Slave
로 Client
의 요청을 보낸다.
Slave
는 ReplicaFon
Event
가 아닌 일반
Insert,
Update,
Delete
Event
가 들어온 경우에는 Master
sync를 위해 해당 Event
들을 큐잉한다.
Master Slave
Event
Handler
ReplicaFon
Manager
Berkeley
DB
Event
Handler
ReplicaFon
Event
ReplicaFon
Manager
Berkeley
DB
인 경우 Skip
ReplicaFon
요청
ReplicaFon
완료
Put
Data Put
Data
Event
queue Event
queue
Put
data Event
queue Database
Acess
Module

22
Layers
-‐
Data
Data
Management
Data
Source
Data
Allocator Table
Manager Load
checker ParFFon
Manager Aging
AWS
S3 AWS
DynamoDB MySQL MongoDB
Job
Queue
Service Berkeley
DB
Library
checker
Data
Sync.
Client
Data
Source
Gateway SGW MyGW DyGW
AWS
SDK JDBC
Remote
BDB
MoGW
Service
Data
Allocator
:
Data
를 memory
에 Loading
할 Node
Server
할당
Load
checker
:
Memory
Usage
를 체크해 Node
서버의 부하를 균일하게 관리
Table
Manager
:
Schema
정보를 관리하고,
데이터를 ParFFon
에 할당.
Data
의 Insert,
update,
delete
처리
ParFFon
Manager
:
Memory
map
관리.
Aging
checker
:
데이터의 변화 시점에 aging
대상여부 확인.
변화가 없는 데이터의 경우 주기적으로 check.
Remote
BDB
Service
:
Local
DB
인 BDB
의 Network
을 통한 접근을 위한 service.
Fail
over
를 위한 BDB
의 replicaFon
도 함께 처리함.
SGW,
MyGW,
DyGW,
MoGW
:
raw
data
에 접근하기 위한 gateway
server
Job
Queue
Service
:
순차적인 처리를 위한 Queue
서비스.
Local
access
는 물론,
네트워크를 통한 remote
access
가능.
JSON
format
으로 정의된 Job
의 Push
/
Pop
기능 제공

23
Layers
-‐
Query
ApplicaFon Query
Query
Management
Client C/C++
Lib. Java
Lib. TCP/IP
Query
Processor Synthesizer
Filter
Client C/C++
Job
Queue
Service Thread
Pool Berkeley
DB
Library
Lib. Java
Lib. TCP/IP
Cache
Manager Query
Parser
Query
Client
:
데이터 조회를 위한 Query
를 전송하고,
그 결과를 받는 client.
Filter
Client
:
Streaming
Data
에 filter
를 지정하고,
filtering
된 결과를 받는 client.
Query
Processor
:
하위 노드에 query
를 broadcasFng
하고,
synthesizer
를 이용해 결과를 merge
한 뒤,
query
혹은 filter
requestor
에게 결과를 전송함.
Synthesizer
:
ParFFon
혹은 Node
단위로 수행된 Query
결과를 Merge
해 최종 결과를 생성해내는 모듈.
Cache
Manager
:
Query
결과에 대한 cache
를 생성.
cache
의 만료 기간을 관리하고,
cache
의 존재 여부를 판단.
동일한 Query
에 대해 불필요한 반복 처리를 피하기
위함.
Query
Parser
:
JSON
형태로 구성된 Query
Syntax
를 확인하고,
수행해야될 Query
정보를 추출하는 모듈
Thread
Pool
:
MulF-‐Job
을 동시에 처리하기 위한 framework

25
MOMENT™ System
CMM
Central
Server
MM
Node
Server
#1
MM
Node
Server
#2
MM
Node
Server
#n
QM
Queue
Manager
Server
MC
MOMENT
Cache
(Remote
BDB
Service)
…
Pop
jobs
of
inserFng
data.
Push
jobs
for
inserFng
data
with
parameter
of
Amazon
S3
path.
Data
Source Query
Client
MC-‐Replica
MOMENT
Cache
(Remote
BDB
Service)
SGW
Amazon
S3
Sub
node
query
Request
query
Send
query
result
Save
raw
data
to
S3
Save
data
locaFon
informaFon,
data
hash
value.
Extensible
node
Alloc.
Modify
Delete
Data

27
Query
response
Fme
&
System
cost
Total
record
count
:
12,547,313
Total
record
size
:
235.39
GB
■
Query
response
Fme
Query
type Response
,me
Calc.
Count
without
grouping 3.24sec.
Calc.
Count
with
grouping 9.12
sec.
Calc.
Sum. 8.65
sec.
Select
10
columns,
limit
10,000 16.3
sec.
■
Cost
(per
month,
base
on
AWS)
Instance Instance
type Count Cost
($)
CORE
(CMM,
QM) m3.large On-‐Demand 1 201.6
MM r3.xlarge Spot 10 2030.4
MC m3.medium On-‐Demand 2
(include
replica.) 201.6
SUM. 2433.6

29
Our
next
plans
• Security
• ANSI/ISO
SQL
standard
compliance
• InteracFve
tools
• Package
for
1-‐Fme
installaFon

Rankwave moment™ desc3

More Related Content

Similar to Rankwave moment™ desc3 (20)

Rankwave moment™ desc3