sensorql을 통한 실시간 기상 데이터 활용 | devon 2012

SensorQL을 통한 실시간 기상 데이터 활용

김응희

[email protected]

2012.10.11

서울대학교 BiKE (Biomedical Knowledge Engineering) Lab.

http://bike.snu.ac.kr

mailto:[email protected]

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 기반 구현

다음-서울대 데이터 수령 준비 사항

목표 업데이트 관련 스트레스 테스트 (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 선정 이유 및 특장점

http://www.mongodb.org/

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)



• 질의 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)



• 질의 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)


수행방안: 스마트 저장소 (계속)

• 스마트 저장소 이슈

이슈 방안

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시

온

도

(

섭

씨)

시간


수집되는

데이터

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: 시간


데이터 저장소

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 접근법 적용

수행방안: 스마트 저장소 & 데이터 요약


스마트 저장소 스마트 데이터 스마트 저장소

스마트 데이터

실 시간 대용량 데이터

저장 및 질의 지원


압축 및 효율적 배포 지원


저장 및 질의,

압축 및 효율적 배포

지원

sensorql을 통한 실시간 기상 데이터 활용 | devon 2012

Documents