3. Goal
Common Open seMantic USN Service Platform
COMUS Platform-based AIDU Sensor Service
• 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 Semantic USN info.-based Popularization of
high-valued Various types of sensors
& Mobile USN
Interoperability contents development services
4. Overall structure of COMUS project & Our role
Easy Access Easy Development
Service development
support
COBALT Service mash-up OpenAPI
Easy Use
COCORE Community Semantic Semantic
processing processing USN
Repository
Sensor resource processing
Service platform interface
Network configuration
COMW USN middle ware
system
Easy Install
COMUSN Static USN gateway
mobile USN
gateway
Common Diffusion sensor
sensor Smart phone
5. 1차년도 목표 및 산출물
연구목표 단일 인터페이스 Open API를 통한 이종 센서 데이터 제공
세부 목표 산출물
SensorQL (SQL like한 질의 언어),
친숙한 인터페이스
SensorQL console (SensorQL 학습용 서비스)
비교, 논리, 정렬, 제약 연산자 지원
풍부한 표현력
in SensorQL
실시간 응답 Sensor Open API
활용 잠재성 (시나리오) 검증 Mash-up 서비스
(Sensor Open API + map OpenAPI + chart OpenAPI)
6. 2011년 산출물
Dummy
Dataset
Sensor Sensor
Query OpenAPI
Language
Sample
SensorQL Mash-up
Console Service
7. 2011년 산출물: Dummy Dataset
Dummy
Dataset 센서 데이터베이스 대표적 스키마 구조
Sensor Sensor Record
테이블 id 테이블
sensor_id
Sensor [가정] latitude Sensor time (from-to)
서울시 각 구당
기상예보 Query OpenAPI
longitude sensingValue
6종 센서 존재
데이터
Language
항목 내용 서울시 온도 센서 서울시 습도 센서 서울시 풍속/향 센서
데이터 베이스 데이터 베이스 데이터 베이스
수집 영역 서울시 25개 구
수집 기간 2012.03.20 – 2012.03.27
수집된 데이터 간격 3시간 Sample
SensorQL Mash-up
온도, 습도, 풍향/풍속, 서울시 강수 센서 서울시 강설 센서 서울시 날씨 센서
수집된 데이터 종류 Console 날씨
강수량, 강설량, 데이터 베이스 데이터 베이스 데이터 베이스
Service
MySQL 기반 6개의 센서 데이터베이스
8. 2011년 산출물: Sensor Query Language (SensorQL)
역할 COMUS 플랫폼 내 데이터에 대한, 사용자가 원하는 센싱 정보 조건 (질의) 표현 지원
Dummy
Dataset
고려
부수적인 언어 습득 없이, 직관적인 질의 기술 지원
사항
Sensor Sensor
Query 문법 SQL-like한 문법 OpenAPI
(JavaCC 기반 정의/구현)
Language
Show Datasources
COMUS에서 지원하는
센서 (저장소) 종류 질의 Describe datasource_name
특정 센서 저장소의
스키마 질의 Select property lists From datasource_name Where conditions filters
특정 센서로부터 논리연산자 sort
얻고자 하는 데이터 Sample 비교연산자 limit
조건 및 종류 질의 SensorQL Mash-up duration
Console• Red font: 예약어 Service
9. 2011년 산출물: Sensor OpenAPI
역할 사용자 질의에 부합한 센서 정보 전달
Dummy
Input 사용자 질의 (SensorQL 형식) Output 사용자 질의에 부합한 센싱 정보 (XML 형태)
Dataset
Sensor Sensor
Sensor OpenAPI OpenAPI
SensorQL Query
1
Language Syntactic parser
(단순 문법 점검)
SensorQL
COMUS 센서 저장소
사용자 2
Semantic parser 메타 정보 관리 시스템
(의미 점검 e.g. 센서 A에 속성 B가 존재하는가)
SensorQL
XML SQL
3
SensorQL – SQL converter
센서 A 정보 저장소
Sample
4 SensorQL …
Mash-up
DB records – XML converter
Console Records Service
TOMCAT 6.0 기반 구현 센서 Z 정보 저장소
10. 2011년 산출물: SensorQL console
역할 Sensor OpenAPI의 활용법 학습 도구
Dummy
Dataset
최근 질의문 패널
SensorQL 형식의
Sensor
질의문 입력 패널 Sensor
Query OpenAPI 질의문 예제 패널
질의문에 부합한
Language
정보 가시화 패널
COMUS 내
센서 저장소
정보 제공 패널
사용자가 구축하는
프로그램에 embedding 가능한
서비스 호출 정보 제공 패널
Google Web Toolkit 기반 구현
Sample
SensorQL Mash-up
Console Service
11. 2011년 산출물: Sample Mash-up Service
역할 Sensor OpenAPI의 활용도 검증 및 활용 시나리오 예제
Dummy
Dataset
1
서울시 25개 구 중,
관심 있는
구(복수 지원) 선택
Sensor Sensor
2 3
기간 선택 Query OpenAPI 전송
질의
(From – To)
Language
5
선택된 구 (복수지원)
4 기온, 습도, 풍속,
지도 상에서 강수량, 강설량
선택된 구(복수 지원) 가시화
Marking
Sample
SensorQL Mash-up
Sensor OpenAPI, Google map API,
Console
HighChart API 기반 구현 Service
13. Dealing with real & Streaming data
(Update issue)
다음-서울대 데이터 수령 준비 사항
목표 업데이트 관련 스트레스 테스트 (Stress Testing focusing on Update operation)
데이터 종류 7종 (온도, 습도, 기압, 풍향, 풍속, 강수유무, 강수량)
데이터 생성 주체 개수 약 600
데이터 특성
데이터 형식 JSON
업데이트 주기 매 1분
1. 수령 받을 데이터 분석
2. 데이터 저장소 선정
점검절차 3. Semi-real 데이터 생성
4. 기간 별 (1분, 1시간, 하루, 한달, 반년) 데이터 업데이트 및 소요시간 측정
5. 분석
14. 1. 수령 받을 데이터 분석
업데이트 주기 데이터 형식 기상측정장비 개수
매 1분 JSON 600
데이터 종류 데이터 타입
1 온도 Numeric 공통 meta 데이터 비고
2 습도 Numeric 1 AWS_ID COMUS 내부 ID
3 기압 Numeric 2 경도
4 풍향 Numeric 3 위도
5 풍속 Numeric 4 고도
6 강수 유무 Boolean 5 측정 시간
7 강수량 Numeric 공통 meta 데이터 리스트
데이터의 종류와 타입 리스트
15. 1. 수령 받을 데이터 분석 (계속)
• 풍향 Data set 예제
{
"resourceId": "129.254.88.127:AWS:12:1", 기상측정장비 ID
"Time": "2012-09-01T00:00:00Z", 측정 시간
"location_x": 36.5333, 경도
"location_y": 126.3167, 위도
"location_z": 60.00, 고도
"Type": "Wind_Direction", 데이터 종류
"Value": 211.9 데이터 값
}
16. 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 선정 이유 및 특장점
17. 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 데이터 상세 정보
19. 4. 기간 별 데이터 업데이트 및 소요시간 측정
실험 환경
• Single machine
• Quad Core 2.80GHz 64bit
• 8GB RAM 최초 1분 ~ 6개월 시뮬레이션
(269,200 회 update 반복)
Record START time
1. Connect
END time - START time
mongoDB 3. Disconnect
= REQUIRED time
Prepared
600 JSONs 2. update Record END time
1st 업데이트 required time
총 15,5520,000 (약 1억 5천만) 개 …
JSON 업데이트 ith 업데이트 required time
…
259,200th 업데이트 required time
20. 5. 분석
269,200 회 업데이트 총 소요시간 (약 1억 5천만 JSON) 17167.35 초 (약 4.7시간)
1회 업데이트 최대 소요시간 (600 JSON) 1.552초
1회 업데이트 최소 소요시간 (600 JSON) 0.044초
1회 업데이트 평균 소요시간 (600JSON) 0.066232 초
21. 결론
• 7종 데이터 중, 풍향 데이터 기반 6개월 간 업데이트 시뮬레이션.
온도 습도 기압 풍향 풍속 강수유무 강수량
X X X O X X X
– 풍향 데이터 1회 업데이트 시 소요된 최대 시간: 약 1.5초.
– 타 6종 데이터 1회 업데이트 시 소요되는 시간 동일 가정.
– 7종 데이터 1회 업데이트 시 소요되는 총 시간: 1.5초 X 7종 = 10.5초.
– 업데이트 주기가 60초 (1분)이므로, 시뮬레이션 시 설정된 환경 내 수령 가능.
22. 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. 분석
23. 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"의 값
24. 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 초
25. 3. 질의-응답 시간 측정 with 질의 리스트
질의
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"의 값
(단위: 초)
1분 1시간 하루 한달 반년
(600 JSON) (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
26. 4. 분석
• 결론
– 인덱스 설정된 저장소에 대한 지속적인 업데이트 연산 시 문제 여지 존재
• 가정: 단일 머신, 추가 센서 도입 여지
– 빈번한 주기로 기록되는 데이터 특성 상 질의에 대한 제약사항 필요
• 예: 특정 온도 센서에 대해, 온도가 20도 이상인 Time.
– 추가 제약조건
» 고려 기간 (예: 2012년 9월 ~ 2012년 12월)
» 단위 (예: day)
• 이슈
– 실시간 대용량 데이터 서비스를 위한 클라우드 컴퓨팅 기법 도입
• 스마트 저장소
– 데이터 분산 저장 및 분산 환경 내 질의-응답 지원 환경 구축
• 스마트 데이터
– 데이터 approximation을 통한 데이터 저장 용량 간략화
27. 2차년도 연구 목표
연구목표 단일 인터페이스 Open API를 통한 이종 센서 데이터 제공
세부 목표
친숙한 인터페이스
실 시간 대용량 실 시간 대용량
풍부한 표현력
데이터 저장 데이터 질의
스마트 저장소 스마트 데이터
실 시간 대용량 데이터 처리
(온도, 습도, 기압, 풍향, 풍속, 강수유무, 강수량)
클라우드 컴퓨팅 환경
활용 잠재성 (시나리오) 검증
28. 실 시간 대용량 데이터 처리
핵심 수행 방안
클라우드 환경 기반 클라우드 환경 기반
스마트 저장소 스마트 데이터
29. 실 시간 대용량 데이터 처리
핵심 수행 방안
클라우드 환경 기반 클라우드 환경 기반
스마트 저장소 스마트 데이터
30. 수행방안: 스마트 저장소
• 스마트 저장소
– 클라우드 환경 내 분산 저장 및 인덱싱
• 가정: 6 workers 보유
Map Reduce
Dataset of
Solr Dataset
resourceId 1-100
Dataset of
resourceId 101-200
resourceId index
Dataset of
Dataset of
resourceId 201-300 … time index
resourceId 1-600 Dataset of
resourceId 301-400 value index
Dataset of
resourceId 401-500
Dataset of
Solr Dataset
resourceId 501-600
31. 수행방안: 스마트 저장소 (계속)
[데이터 업데이트]
하루치 데이터
실험 환경 S1
•Mac Mini 3대
•Dual Core 2GHz 64bit S2
• 2GB RAM
COORDINATOR S3
Data
Machine #0
HTTP HTTP HTTP
Solr/mongoDB Solr/mongoDB Solr/mongoDB
S1 S2 S3
Machine #1 Machine #2 Machine #3
32. 수행방안: 스마트 저장소 (계속)
[데이터 업데이트]
데이터 기본 데이터 기본 데이터 기본
No. No. No.
종류 단위 종류 단위 종류 단위
센서 1분 시간 누적
1 문자열 7 0.1 m/s 13 0.1 mm
ID 평균 풍속 강수량
1분 일 누적
2 관측시각 년월일시분 8 0.1 C 14 0.1 mm
평균 기온 강수량
1분 15분 이동
3 위도 Degree 9 0.1 % 15 0.1 mm
평균 습도 누적 강수량
1분 평균 60분 이동
4 경도 Degree 10 0.1 hPa 16 0.1 mm
현지기압 누적 강수량
1분 평균 일 순간
5 고도 Meter 11 0.1 hPa 17 0.1 Degree
해면기압 최대 풍향
1분 일 순간
6 0.1 Degree 12 강수 감지 0: 무강수 18 0.1 m/s
평균 풍향 최대 풍속
33. 수행방안: 스마트 저장소 (계속)
[데이터 업데이트]
컬럼
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
순서
15분 60분 일 일
현지 해면 강수 시간 일
의미 ID 시각 위도 경도 고도 풍향 풍속 기온 습도 이동 이동 최대 최대
기압 기압 감지 강수 강수
강수 강수 풍향 풍속
2012
36. 126.
예 12 0305 60.00 871 67 44 922 10055 10129 10 5 15 0 5 1081 87
5333 3167
1055
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분 업데이트 주기 데이터
39. 수행방안: 스마트 저장소 (계속)
• 스마트 저장소 이슈
이슈 방안
resourceId, time, value 등 복수 개의 key에 대한
Iterative MapReduce
인덱스 테이블 생성을 위한 방법론 개발 및 구현
주기적으로 업데이트되는 데이터에 대한
Incremental indexing
효율적 인덱싱 개발 방법 개발 및 구현
가용한 머신 및 다뤄야 할 데이터 사이즈 기반
Optimal size of fragments
최적화된 분할 사이즈 도출 및 적용
40. Back to the project
실 시간 대용량 데이터 처리핵심 수행 방안
클라우드 환경 기반 클라우드 환경 기반
스마트 저장소 스마트 데이터
41. 수행방안: 스마트 데이터
• 동기 (Motivation)
과제 명 독립형 컴포넌트 기반 서비스 지향형 패타급 컴퓨팅 플랫폼 기술개발
지원기관 지식경제부
시행기관 정보통신연구진흥원
수행기간 2010.03 - 2012.02
클라우드 컴퓨팅 환경
Query Answer
Query Answer Index
RDF … table
triples Query Answer 실 시간 서비스
예상 Query 리스트- 인덱싱된
예상 Answer 리스트 Query-Answer 집합
30억 이상의
RDF triples
42. 수행방안: 스마트 데이터 (계속)
• 스마트 데이터 기본 아이디어
일반 데이터 스마트 데이터
row data
A function
row data (with parameters)
k row data
row data
…
k/n
row data
n … Processing
(approximation)
row data
row data
A function
row data (with parameters)
row data
row data
43. 수행방안: 스마트 데이터 (계속)
• 현재 (naive) 접근법
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
12
10
수집되는 8
(
섭 온
데이터 씨 도
6
4
)
2
0
00시 03시 06시 09시 12시 15시 18시 21시
시간
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
44. 수행방안: 스마트 데이터 (계속)
• 효율적 (advanced) 접근법
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
15
10
(
수집되는 섭 온
씨 도 5
데이터
)
0
00시 03시 06시 09시 12시 15시 18시 21시
시간
Approximation (Finding a function for dataset)
y = ax2 + bx + c 15
where, 10
(
섭 온
y: 온도 씨 도 5
)
x: 시간 0
00시 03시 06시 09시 12시 15시 18시 21시
시간
45. 수행방안: 스마트 데이터 (계속)
2012-03-22 서울시 동작구 온도 예보 데이터 (출처: 기상청)
y = ax2 + bx + c 15
where, 10
(
섭 온
y: 온도 씨 도 5
)
x: 시간 0
00시 03시 06시 09시 12시 15시 18시 21시
시간
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
…
데이터 저장소
46. 수행방안: 스마트 데이터 (계속)
• 센서 별 저장되는 데이터 수 비교
상황 가정 600000
센서 데이터 수집 주기 1분
500000
Approximation 주기 1일 저
장
400000
되
는
하루 한달 반년 일년 300000
데
Naï approach
ve
이
Advanced approach
터 200000
Naive 1,440 43,200 259,200 518,400
수
100000
Advanced 1 30 180 360
0
하루 한달 반년 일년
데이터 축적 기간
47. 수행방안: 스마트 데이터 (계속)
• 질의-응답 방식 비교
– 가정
• 데이터 저장소 크기: 2012년 1년 치 데이터
• 질의: 온도 센서 r1에 대한 2012-09-01T09:00의 온도 값
Naï approach
ve Advanced approach
360 … 360 데이터 탐색
518,400 데이터 탐색 records
수식 계산 with params
518,400
records …
201209010900
온도 값 return 온도 값 return
48. 수행방안: 스마트 데이터 (계속)
• 센서 데이터 배포 방식 비교
– 가정
• 데이터 저장소 크기: 2012년 1년 치 데이터
• 배포 데이터: 온도 센서 r1에 대한 2012-09에 대한 온도 값 리스트
Naï approach
ve Advanced approach
360 … 360 데이터 탐색
518,400 데이터 탐색 records
518,400
records …
온도 값 43,200 개 return 30개의 함수 return
49. 수행방안: 스마트 데이터 (계속)
• 스마트 데이터 이슈
이슈 방안
Approximation 정확도 다양한 분포 모델 도입/개발: Curve fitting problem
(Gaussian, Poisson, Gaussian mixture, Fourier transform, etc)
Approximation 소요시간 클라우드 컴퓨팅 기법 도입
(Approximation을 위한 연산의 MapReduce화)
[온도, 기압, 습도, 풍향, 풍속], [강수량], [강수 여부] 별
데이터 특성 데이터 분포 분석 및 차등 approximation 접근법 적용
50. 수행방안: 스마트 저장소 & 데이터 요약
실 시간 대용량 데이터
저장 및 질의,
압축 및 효율적 배포
지원
실 시간 대용량 데이터 실 시간 대용량 데이터
저장 및 질의 지원 압축 및 효율적 배포 지원
스마트 데이터
스마트 저장소 스마트 데이터 스마트 저장소
클라우드 컴퓨팅 환경
