Download - SensorQL을 통한 실시간 기상 데이터 활용 | Devon 2012
SensorQL을 통한 실시간 기상 데이터 활용
김응희
2012.10.11
서울대학교 BiKE (Biomedical Knowledge Engineering) Lab.
http://bike.snu.ac.kr
Common Open seMantic USN Service Platform
Goal
COMUS Platform-based AIDU Sensor Service
Common Open seMantic USN Service Platform
• Easy Access: to Global USN resources & sensor-related data
• Easy Install: of various types of sensors
• Easy Development: of applications and systems dealing with sensor data
• Easy Use: with OpenAPIs
Sharing USN resources
&
Interoperability
Semantic USN info.-based
high-valued
contents development
Popularization of
Mobile USN
services
Various types of sensors
Overall structure of COMUS project & Our role
COBALT
COCORE
COMW
COMUSN
Service mash-up OpenAPI
Semantic USN
Repository
Community processing
Semantic processing
Sensor resource processing
Service platform interface
USN middle ware Network configuration
system
Static USN gateway mobile USN
gateway
Common sensor Smart phone
Diffusion sensor
Easy Install
Easy Use
Easy Access
Service development support
Easy Development
1차년도 목표 및 산출물
단일 인터페이스 Open API를 통한 이종 센서 데이터 제공 연구목표
세부 목표 산출물
친숙한 인터페이스
풍부한 표현력
실시간 응답
활용 잠재성 (시나리오) 검증
SensorQL (SQL like한 질의 언어),
SensorQL console (SensorQL 학습용 서비스)
비교, 논리, 정렬, 제약 연산자 지원
in SensorQL
Sensor Open API
Mash-up 서비스 (Sensor Open API + map OpenAPI + chart OpenAPI)
2011년 산출물
Sensor
Query
Language
Dummy
Dataset
Sensor
OpenAPI
SensorQL
Console
Sample
Mash-up
Service
2011년 산출물: Dummy Dataset
Sensor
Query
Language
Sensor
OpenAPI
SensorQL
Console
Sample
Mash-up
Service
Dummy
Dataset
기상예보
데이터
항목 내용
수집 영역 서울시 25개 구
수집 기간 2012.03.20 – 2012.03.27
수집된 데이터 간격 3시간
수집된 데이터 종류 온도, 습도, 풍향/풍속, 강수량, 강설량, 날씨
서울시 온도 센서
데이터 베이스
서울시 습도 센서
데이터 베이스
서울시 풍속/향 센서
데이터 베이스
서울시 강수 센서
데이터 베이스
서울시 강설 센서
데이터 베이스
서울시 날씨 센서
데이터 베이스
[가정]
서울시 각 구당
6종 센서 존재
Sensor
테이블 Sensor Record
테이블 id
latitude
longitude
sensor_id
time (from-to)
sensingValue
센서 데이터베이스 대표적 스키마 구조
MySQL 기반 6개의 센서 데이터베이스
2011년 산출물: Sensor Query Language (SensorQL)
Dummy
Dataset
Sensor
OpenAPI
SensorQL
Console
Sample
Mash-up
Service
역할
고려
사항
COMUS 플랫폼 내 데이터에 대한, 사용자가 원하는 센싱 정보 조건 (질의) 표현 지원
부수적인 언어 습득 없이, 직관적인 질의 기술 지원
SQL-like한 문법
Select
Describe
Show Datasources
datasource_name
property lists From datasource_name Where conditions filters
논리연산자
비교연산자
sort
limit
duration
(JavaCC 기반 정의/구현)
COMUS에서 지원하는
센서 (저장소) 종류 질의
문법
Sensor
Query
Language
특정 센서 저장소의
스키마 질의
특정 센서로부터
얻고자 하는 데이터
조건 및 종류 질의
• Red font: 예약어
2011년 산출물: Sensor OpenAPI
Sensor
Query
Language
Dummy
Dataset
SensorQL
Console
Sample
Mash-up
Service
Sensor
OpenAPI
역할 사용자 질의에 부합한 센서 정보 전달
Input 사용자 질의 (SensorQL 형식) Output 사용자 질의에 부합한 센싱 정보 (XML 형태)
사용자
Sensor OpenAPI
Syntactic parser (단순 문법 점검)
Semantic parser (의미 점검 e.g. 센서 A에 속성 B가 존재하는가)
SensorQL – SQL converter
DB records – XML converter
1
2
3
SensorQL
SensorQL
SensorQL
COMUS 센서 저장소
메타 정보 관리 시스템
센서 A 정보 저장소
센서 Z 정보 저장소
…
SQL
Records
4
XML
TOMCAT 6.0 기반 구현
2011년 산출물: SensorQL console
Sensor
Query
Language
Dummy
Dataset
Sensor
OpenAPI
Sample
Mash-up
Service
역할 Sensor OpenAPI의 활용법 학습 도구
SensorQL 형식의
질의문 입력 패널
질의문에 부합한
정보 가시화 패널
사용자가 구축하는
프로그램에 embedding 가능한
서비스 호출 정보 제공 패널
SensorQL
Console
질의문 예제 패널
최근 질의문 패널
COMUS 내
센서 저장소
정보 제공 패널
Google Web Toolkit 기반 구현
2011년 산출물: Sample Mash-up Service
Sensor
Query
Language
Dummy
Dataset
Sensor
OpenAPI
SensorQL
Console
역할 Sensor OpenAPI의 활용도 검증 및 활용 시나리오 예제
Sample
Mash-up
Service
서울시 25개 구 중,
관심 있는
구(복수 지원) 선택
1
기간 선택
(From – To)
2 질의 전송
3
지도 상에서
선택된 구(복수 지원)
Marking
4 선택된 구 (복수지원)
기온, 습도, 풍속,
강수량, 강설량
가시화
5
Sensor OpenAPI, Google map API,
HighChart API 기반 구현
2012
다음-서울대 데이터 수령 준비 사항
목표 업데이트 관련 스트레스 테스트 (Stress Testing focusing on Update operation)
데이터 특성
데이터 종류 7종 (온도, 습도, 기압, 풍향, 풍속, 강수유무, 강수량)
데이터 생성 주체 개수 약 600
데이터 형식 JSON
업데이트 주기 매 1분
점검절차
1. 수령 받을 데이터 분석
2. 데이터 저장소 선정
3. Semi-real 데이터 생성
4. 기간 별 (1분, 1시간, 하루, 한달, 반년) 데이터 업데이트 및 소요시간 측정
5. 분석
Dealing with real & Streaming data (Update issue)
1. 수령 받을 데이터 분석
데이터 종류 데이터 타입
1 온도 Numeric
2 습도 Numeric
3 기압 Numeric
4 풍향 Numeric
5 풍속 Numeric
6 강수 유무 Boolean
7 강수량 Numeric
데이터의 종류와 타입 리스트
공통 meta 데이터 비고
1 AWS_ID COMUS 내부 ID
2 경도
3 위도
4 고도
5 측정 시간
공통 meta 데이터 리스트
업데이트 주기 데이터 형식 기상측정장비 개수
매 1분 JSON 600
1. 수령 받을 데이터 분석 (계속)
• 풍향 Data set 예제
{
"resourceId": "129.254.88.127:AWS:12:1",
"Time": "2012-09-01T00:00:00Z",
"location_x": 36.5333,
"location_y": 126.3167,
"location_z": 60.00,
"Type": "Wind_Direction",
"Value": 211.9
}
기상측정장비 ID
측정 시간
경도
위도
고도
데이터 종류
데이터 값
2. 데이터 저장소 선정
• mongoDB (http://www.mongodb.org/) 선정 및 학습
– About it: a scalable, high-performance, open source NoSQL database
Features Description
Document-oriented storage JSON-style document with dynamic schemas offer simplicity & power
Full Index Support Index on any attribute
Auto-Sharding Scale horizontally without compromising functionality
Querying Rich, document-based queries
Fast In-Place Updates Atomic modifiers for contention-free performance
Map/Reduce Flexible aggregation & data processing
GridFS Store files of any size without complicating your stack
mongoDB 선정 이유 및 특장점
3. Semi-real 데이터 생성
1. 7종류의 센서 데이터 중 "풍향" 데이터 선정
– 선정 사유: ETRI로부터 예제 JSON 수령
2. Semi-real 데이터 생성 시 착안점
– 실제 수령될 데이터와의 유사성 최대화
Attribute 명 기본 형식 데이터 생성 시 규칙
resourceId 129.254.88.127:ASW:XXX XXX∈[1, 600]
Time yyyy-MM-dd'T'HH:mm:ss Start with 2012-09-01T00:00:00
location_x double type location_x∈[10, 300]
location_y double type location_y∈[10, 300]
location_z double type location_z∈[10, 300]
Type Wind_Direction
Value double type Value∈[0, 359]
생성된 Wind Direction JSON 데이터 상세 정보
3. Semi-real 데이터 생성 (계속)
• 생성된 JSON (Wind Direction) 일부
… … …
4. 기간 별 데이터 업데이트 및 소요시간 측정
최초 1분 ~ 6개월 시뮬레이션
(269,200 회 update 반복)
Prepared
600 JSONs
mongoDB
1. Connect
2. update
3. Disconnect
Record START time
Record END time
END time - START time
= REQUIRED time
ith 업데이트 required time
1st 업데이트 required time
259,200th 업데이트 required time
…
…
총 15,5520,000 (약 1억 5천만) 개
JSON 업데이트
실험 환경
• Single machine
• Quad Core 2.80GHz 64bit
• 8GB RAM
5. 분석
269,200 회 업데이트 총 소요시간 (약 1억 5천만 JSON) 17167.35 초 (약 4.7시간)
1회 업데이트 최대 소요시간 (600 JSON) 1.552초
1회 업데이트 최소 소요시간 (600 JSON) 0.044초
1회 업데이트 평균 소요시간 (600JSON) 0.066232 초
결론
• 7종 데이터 중, 풍향 데이터 기반 6개월 간 업데이트 시뮬레이션.
– 풍향 데이터 1회 업데이트 시 소요된 최대 시간: 약 1.5초.
– 타 6종 데이터 1회 업데이트 시 소요되는 시간 동일 가정.
– 7종 데이터 1회 업데이트 시 소요되는 총 시간: 1.5초 X 7종 = 10.5초.
– 업데이트 주기가 60초 (1분)이므로, 시뮬레이션 시 설정된 환경 내 수령 가능.
온도 습도 기압 풍향 풍속 강수유무 강수량
X X X O X X X
Dealing with real & Streaming data (Query issue)
다음-서울대 데이터 활용 준비 사항
목표 질의-응답 관련 스트레스 테스트 (Stress Testing focusing on Query-Response)
데이터 저장소
특성
데이터 저장소 종류 mongoDB 2.2.0 (released: 2012.08.29)
테이블 (Collection) 종류 7 (온도, 습도, 기압, 풍향, 풍속, 강수유무, 강수량)
테이블 필드 (Attribute) 수 7 (resourceId, Time, location_x, location_y, location_z, Type, Value)
테이블 당 레코드 (JSON) 수 6개월 기준 15,5520,000 (약 1억 5천만)
업데이트 주기/추가되는 레코드 수 1분/600개
점검절차
1. 질의 리스트 (Query list) 선정
2. 데이터 저장소 인덱스 설정 및 업데이트 시간 측정
3. 질의-응답 시간 측정 with 질의 리스트
4. 분석
1. 질의 리스트 선정
1. 7종류의 테이블 (Collection) 중 "풍향" 테이블 선정
– 선정 사유: ETRI로부터 예제 JSON 수령 & semi-real 데이터 보유
2. 질의 리스트 선정 시 착안점
– 빈번할 것으로 예상되는 기본 질의 스타일
– 제약사항
• 질의 시, "resourceId" 혹은 "Time"에 대한 조건 필수 기입
질의
Q1 "Time"이 t일 때, "resouceId"가 r인 "Value" (풍향)의 값
Q2 "Time"이 t1 ~ t2일 때, "resourceId"가 r인 "Value"의 값 (t1 < t2)
Q3 "resouceId"가 r인 센서의 최근 10개 "Value"의 값
2. 데이터 저장소 인덱스 설정 및 업데이트 시간 측정
• 인덱스 설정 attributes: "resourceId" and "Time"
269,200 회 업데이트 총 소요시간 (약 1억 5천만 JSON) 31316.01 초 (약 8.6 시간)
1회 업데이트 최대 소요시간 (600 JSON) 15.56 초
1회 업데이트 최소 소요시간 (600 JSON) 0.049 초
1회 업데이트 평균 소요시간 (600JSON) 0.12 초
3. 질의-응답 시간 측정 with 질의 리스트
1분 (600 JSON)
1시간 (36,000 JSON)
하루 (864,000 JSON)
한달 (25,920,000 JSON)
반년 (155,520,000 JSON)
Q1 0.375 0.286 0.209 0.506 0.739
Q2 0.169 0.052 1.195 2.386 10.919
Q3 0.189 0.033 0.371 73.737 N/A
(단위: 초)
질의
Q1 "Time"이 "2012-09-01T00:00:00"일 때, "resouceId"가 "129.254.88.127:AWS:100"인 "Value" (풍향)의 값
Q2 "Time"이 "2012-09-01T00:00:00"~ "2012-09-03T00:00:00"일 때, "resourceId"가 "129.254.88.127:AWS:100"인 "Value"의 값
Q3 "resouceId"가 "129.254.88.127:AWS:100"인 센서의 최근 10개 "Value"의 값
4. 분석
• 결론
– 인덱스 설정된 저장소에 대한 지속적인 업데이트 연산 시 문제 여지 존재
• 가정: 단일 머신, 추가 센서 도입 여지
– 빈번한 주기로 기록되는 데이터 특성 상 질의에 대한 제약사항 필요
• 예: 특정 온도 센서에 대해, 온도가 20도 이상인 Time.
– 추가 제약조건
» 고려 기간 (예: 2012년 9월 ~ 2012년 12월)
» 단위 (예: day)
• 이슈
– 실시간 대용량 데이터 서비스를 위한 클라우드 컴퓨팅 기법 도입
• 스마트 저장소
– 데이터 분산 저장 및 분산 환경 내 질의-응답 지원 환경 구축
• 스마트 데이터
– 데이터 approximation을 통한 데이터 저장 용량 간략화
2차년도 연구 목표
클라우드 컴퓨팅 환경
단일 인터페이스 Open API를 통한 이종 센서 데이터 제공 연구목표
세부 목표
친숙한 인터페이스
풍부한 표현력
활용 잠재성 (시나리오) 검증
실 시간 대용량 데이터 처리
(온도, 습도, 기압, 풍향, 풍속, 강수유무, 강수량)
실 시간 대용량
데이터 저장
실 시간 대용량
데이터 질의
스마트 저장소 스마트 데이터
실 시간 대용량 데이터 처리
핵심 수행 방안
클라우드 환경 기반
스마트 저장소
클라우드 환경 기반
스마트 데이터
실 시간 대용량 데이터 처리
핵심 수행 방안
클라우드 환경 기반
스마트 저장소
클라우드 환경 기반
스마트 데이터
수행방안: 스마트 저장소
• 스마트 저장소
– 클라우드 환경 내 분산 저장 및 인덱싱
• 가정: 6 workers 보유
Reduce Map
Dataset of
resourceId 1-600
Dataset of
resourceId 1-100 Dataset Solr
Dataset of
resourceId 101-200
Dataset of
resourceId 201-300
Dataset of
resourceId 301-400
Dataset of
resourceId 401-500
Dataset of
resourceId 501-600 Dataset Solr
…
resourceId index
time index
value index
실험 환경
•Mac Mini 3대
•Dual Core 2GHz 64bit
• 2GB RAM
Machine #0
Data
COORDINATOR
Machine #1
S1
Solr/mongoDB
Machine #2
S2
Solr/mongoDB
Machine #3
S3
Solr/mongoDB
HTTP HTTP HTTP
S1
S2
S3
하루치 데이터
수행방안: 스마트 저장소 (계속) [데이터 업데이트]
수행방안: 스마트 저장소 (계속) [데이터 업데이트]
No. 데이터
종류
기본
단위 No.
데이터
종류
기본
단위 No.
데이터
종류
기본
단위
1 센서
ID 문자열 7
1분
평균 풍속 0.1 m/s 13
시간 누적
강수량 0.1 mm
2 관측시각 년월일시분 8 1분
평균 기온 0.1 C 14
일 누적
강수량 0.1 mm
3 위도 Degree 9 1분
평균 습도 0.1 % 15
15분 이동
누적 강수량 0.1 mm
4 경도 Degree 10 1분 평균
현지기압 0.1 hPa 16
60분 이동
누적 강수량 0.1 mm
5 고도 Meter 11 1분 평균
해면기압 0.1 hPa 17
일 순간
최대 풍향 0.1 Degree
6 1분
평균 풍향 0.1 Degree 12 강수 감지 0: 무강수 18
일 순간
최대 풍속 0.1 m/s
수행방안: 스마트 저장소 (계속) [데이터 업데이트]
컬럼 순서
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
의미 ID 시각 위도 경도 고도 풍향 풍속 기온 습도 현지 기압
해면 기압
강수 감지
시간 강수
일 강수
15분 이동 강수
60분 이동 강수
일 최대 풍향
일 최대 풍속
예 12 2012
0305
1055
36.
5333 126.
3167 60.00 871 67 44 922 10055 10129 10 5 15 0 5 1081 87
1분 주기 업데이트 주기 file 데이터
기간 식 데이터 수
1분 센서 수 701
1시간 센서 수×60 42,060
하루 센서 수×60×24 1,009,440
한달 센서 수×60×24×30 30,283,200
반년 센서 수×60×24×30×6 181,699,200
1분 업데이트 주기 데이터
수행방안: 스마트 저장소 (계속) [데이터 업데이트]
0
50
100
150
200
250
300
3.5
3.9
3.1
3
3.1
7
3.2
1
3.2
5
3.2
9
4.2
4.6
4.1
4.1
4
4.1
8
4.2
2
4.2
6
4.3
5.4
5.8
5.1
2
5.1
6
5.2
5.2
4
5.2
8
6.1
6.5
6.9
6.1
3
6.1
7
6.2
1
6.2
5
6.2
9
7.3
7.7
7.1
1
7.1
5
7.1
9
7.2
3
7.2
7
7.3
1
8.4
8.8
8.1
2
8.1
6
8.2
8.2
4
8.2
8
소요
시간
(m
s)
Distributed Solr Distributed MongoDB
수행방안: 스마트 저장소 (계속) [ 질의 ]
질의
Q1 "resouceId"가 "100"인 센서의 최근 "Value"의 값 300개
Q2 "resourceId"가 "100“ 이고 "Time"이 "201203210000"~ "201203230000 "인 "Value"의 값 300개
Q3 "resouceId"가 "100"이고 "Time"이 "201205050028"인 "Value"의 값
4개월 (118,304,811 개)
+15일 (132,262,106 개)
+15일 (148,220,766 개)
+15일 (163,194,878 개)
+15일 (179,153,279 개)
Q1 Solr 3,839 1,854 3,879 1,500 2,702
MongoDB 292,340 251,508 285,455 270,046 281,386
Q2 Solr 1,034 1,656 3,266 1,367 1,300
MongoDB 203,992 242,680 325,917 285,063 325,859
Q3 Solr 281 274 600 322 384
MongoDB 2,820 2,500 3,008 2,732 3,062
(단위: ms)
수행방안: 스마트 저장소 (계속) [ 질의 ]
• 질의 Q1
0
50000
100000
150000
200000
250000
300000
350000
400000
450000
500000
7.1 7.3 7.5 7.7 7.9 7.11 7.13 7.15 7.17 7.19 7.21 7.23 7.25 7.27 7.29 7.31 8.2 8.4 8.6 8.8 8.10 8.12 8.14 8.16 8.18 8.20 8.22 8.24 8.26 8.28 8.30
소요
시간
(m
s)
Distributed Solr Distributed MongoDB
수행방안: 스마트 저장소 (계속) [ 질의 ]
• 질의 Q2
0
100000
200000
300000
400000
500000
600000
7.1 7.3 7.5 7.7 7.9 7.11 7.13 7.15 7.17 7.19 7.21 7.23 7.25 7.27 7.29 7.31 8.2 8.4 8.6 8.8 8.10 8.12 8.14 8.16 8.18 8.20 8.22 8.24 8.26 8.28 8.30
소요
시간
(m
s)
Distributed Solr Distributed MongoDB
수행방안: 스마트 저장소 (계속) [ 질의 ]
• 질의 Q3
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
7.1 7.3 7.5 7.7 7.9 7.11 7.13 7.15 7.17 7.19 7.21 7.23 7.25 7.27 7.29 7.31 8.2 8.4 8.6 8.8 8.10 8.12 8.14 8.16 8.18 8.20 8.22 8.24 8.26 8.28 8.30
소요
시간
(m
s)
Distributed Solr Distributed MongoDB
수행방안: 스마트 저장소 (계속)
• 스마트 저장소 이슈
이슈 방안
Iterative MapReduce resourceId, time, value 등 복수 개의 key에 대한
인덱스 테이블 생성을 위한 방법론 개발 및 구현
Incremental indexing 주기적으로 업데이트되는 데이터에 대한
효율적 인덱싱 개발 방법 개발 및 구현
Optimal size of fragments 가용한 머신 및 다뤄야 할 데이터 사이즈 기반
최적화된 분할 사이즈 도출 및 적용
Back to the project
실 시간 대용량 데이터 처리핵심 수행 방안
클라우드 환경 기반
스마트 저장소
클라우드 환경 기반
스마트 데이터
클라우드 컴퓨팅 환경
수행방안: 스마트 데이터
• 동기 (Motivation)
과제 명 독립형 컴포넌트 기반 서비스 지향형 패타급 컴퓨팅 플랫폼 기술개발
지원기관 지식경제부
시행기관 정보통신연구진흥원
수행기간 2010.03 - 2012.02
RDF
triples
30억 이상의
RDF triples
예상 Query 리스트-
예상 Answer 리스트
인덱싱된
Query-Answer 집합
실 시간 서비스
Query Answer
Query Answer
Query Answer
…
Index
table
수행방안: 스마트 데이터 (계속)
• 스마트 데이터 기본 아이디어
row data
row data
row data
row data
Processing (approximation)
A function (with parameters)
row data
row data
row data
row data
row data
row data
A function (with parameters)
일반 데이터
… n
k
스마트 데이터
… k/n
수행방안: 스마트 데이터 (계속)
• 현재 (naive) 접근법
resourceId: r1, location_x: 100, location_y: 50, location_x: 10, Time: 2012-03-22T00:00, Value=4
resourceId: r1, location_x: 100, location_y: 50, location_x: 10, Time: 2012-03-22T03:00, Value=4.3
resourceId: r1, location_x: 100, location_y: 50, location_x: 10, Time: 2012-03-22T21:00, Value=7.6
… 데이터
저장소
0
2
4
6
8
10
12
00시 03시 06시 09시 12시 15시 18시 21시
온
도
(
섭
씨)
시간
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
수집되는
데이터
수행방안: 스마트 데이터 (계속)
• 효율적 (advanced) 접근법
0
5
10
15
00시 03시 06시 09시 12시 15시 18시 21시
온
도
(
섭
씨)
시간
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
수집되는
데이터
Approximation (Finding a function for dataset)
0
5
10
15
00시 03시 06시 09시 12시 15시 18시 21시
온
도
(
섭
씨)
시간
y = ax2 + bx + c
where,
y: 온도
x: 시간
수행방안: 스마트 데이터 (계속)
0
5
10
15
00시 03시 06시 09시 12시 15시 18시 21시
온
도
(
섭
씨)
시간
y = ax2 + bx + c
where,
y: 온도
x: 시간
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
데이터 저장소
resourceId: r1, location_x: 100, location_y: 50, location_x: 10, Time: 2012-03-22, a=3, b=4, c=5
…
resourceId: r1, location_x: 100, location_y: 50, location_x: 10, Time: 2012-12-31, a=2, b=7, c=1, d=13
…
수행방안: 스마트 데이터 (계속)
• 센서 별 저장되는 데이터 수 비교
상황 가정
센서 데이터 수집 주기 1분
Approximation 주기 1일
하루 한달 반년 일년
Naive 1,440 43,200 259,200 518,400
Advanced 1 30 180 360 0
100000
200000
300000
400000
500000
600000
하루 한달 반년 일년
저
장
되
는
데
이
터
수
데이터 축적 기간
Naïve approach
Advanced approach
수행방안: 스마트 데이터 (계속)
• 질의-응답 방식 비교
– 가정
• 데이터 저장소 크기: 2012년 1년 치 데이터
• 질의: 온도 센서 r1에 대한 2012-09-01T09:00의 온도 값
Naïve approach Advanced approach
518,400
records
360
records
…
518,400 데이터 탐색
온도 값 return
… 360 데이터 탐색
수식 계산 with params
온도 값 return 201209010900
수행방안: 스마트 데이터 (계속)
• 센서 데이터 배포 방식 비교
– 가정
• 데이터 저장소 크기: 2012년 1년 치 데이터
• 배포 데이터: 온도 센서 r1에 대한 2012-09에 대한 온도 값 리스트
Naïve approach Advanced approach
518,400
records …
518,400 데이터 탐색
온도 값 43,200 개 return
360
records …
360 데이터 탐색
30개의 함수 return
수행방안: 스마트 데이터 (계속)
• 스마트 데이터 이슈
이슈 방안
Approximation 정확도 다양한 분포 모델 도입/개발: Curve fitting problem (Gaussian, Poisson, Gaussian mixture, Fourier transform, etc)
Approximation 소요시간 클라우드 컴퓨팅 기법 도입 (Approximation을 위한 연산의 MapReduce화)
데이터 특성 [온도, 기압, 습도, 풍향, 풍속], [강수량], [강수 여부] 별
데이터 분포 분석 및 차등 approximation 접근법 적용
수행방안: 스마트 저장소 & 데이터 요약
클라우드 컴퓨팅 환경
스마트 저장소 스마트 데이터 스마트 저장소
스마트 데이터
실 시간 대용량 데이터
저장 및 질의 지원
실 시간 대용량 데이터
압축 및 효율적 배포 지원
실 시간 대용량 데이터
저장 및 질의,
압축 및 효율적 배포
지원
Q n A