Persistent Temporal Streams David Hilley Umakishore Ramachandran { - - PowerPoint PPT Presentation

persistent temporal streams
SMART_READER_LITE
LIVE PREVIEW

Persistent Temporal Streams David Hilley Umakishore Ramachandran { - - PowerPoint PPT Presentation

Persistent Temporal Streams David Hilley Umakishore Ramachandran { davidhi, rama } @cc.gatech.edu School of Computer Science College of Computing, Georgia Institute of Technology Middleware 09 Outline Intro Premise Temporal


slide-1
SLIDE 1

Persistent Temporal Streams

David Hilley Umakishore Ramachandran

{davidhi, rama}@cc.gatech.edu School of Computer Science College of Computing, Georgia Institute of Technology Middleware ’09

slide-2
SLIDE 2

Outline

  • Intro
  • Premise
  • Temporal Streams
  • Programming Model
  • System Design & Implementation
  • Evaluation
  • Conclusion & Questions

2

slide-3
SLIDE 3

What is Live Stream Analysis?

  • Live Stream Analysis
  • Surveillance / “Situational Awareness”
  • Traffic Analysis
  • Cargo / Asset Tracking
  • Robotics
  • Disaster Response
  • Ubiquitous and increasingly important

3

slide-4
SLIDE 4

What is Temporal Streams?

  • Building blocks for stream analysis
  • Distributed data structures for streams
  • “Glue” for communicating components
  • A lower-level substrate

4

slide-5
SLIDE 5

Our Own Experience

  • TV Watcher
  • Media Broker / MB++
  • Streaming Grid
  • V(A)aaS – video-analytics-as-a-service
  • RF2ID
  • ASAP – situational awareness
  • IPTV Analytics / Recommender systems

5

slide-6
SLIDE 6

Pain Points

  • Time – synchronization, data retrieval
  • Scalable data delivery
  • Storage of streaming data
  • Management of computation? – yes, but

vastly different requirements between applications and domains

6

slide-7
SLIDE 7

Pain Points

  • Time – synchronization, data retrieval
  • Scalable data delivery
  • Storage of streaming data
  • Management of computation? – yes, but

vastly different requirements between applications and domains

6

slide-8
SLIDE 8

Solution Space

  • MPI, Message-Oriented-Middleware

(too low level)

  • Stream Data Management Systems
  • Event Stream Processing (ESP) / CEP

(too high level)

  • Temporal Streams

(just right)

7

slide-9
SLIDE 9

Relationship to Other Work

  • A middleground
  • Below full SDMS and stream languages
  • Above non-stream oriented distributed

communications

  • Roughly analogous to non-streaming:
  • Distributed Data Structures (Gribble, et al.)
  • BerkeleyDB (Seltzer, et al.)
  • Boxwood (MacCormick, et al.)

8

slide-10
SLIDE 10

In Context

  • Bottom-up “systems” approach
  • Recognizing the value of time
  • Explore effect on system level properties
  • Programming model incorporates time
  • Unique point in the design space

9

slide-11
SLIDE 11

Going forward

  • Intro
  • Premise
  • Temporal Streams
  • Programming Model
  • System Design & Implementation
  • Evaluation
  • Conclusion & Questions

10

slide-12
SLIDE 12

Programming Model

11

slide-13
SLIDE 13

Channel

  • Represents a continuous data stream
  • Items ordered by wall-clock timestamp

now

  • ldest

1:05pm 1:06pm

12

slide-14
SLIDE 14

Channel

  • Represents a continuous data stream
  • Items ordered by wall-clock timestamp
  • Simple time-based operations:
  • put(item, [timestamp])
  • get(lower bound, upper bound)
  • Time variables to specify time intervals

e.g. now, newest-after(ts), oldest, etc.

  • Spans communication & storage

12

slide-15
SLIDE 15

Channel Get Interval Example

now

Returned Items

  • ldest

...

lower bound upper bound

13

slide-16
SLIDE 16

Persistent Channel Get

now

Live Data (60 sec.) Get Interval Stored Data

...

In RAM On Disk / Backing Store

14

slide-17
SLIDE 17

Stream Persistence

  • Seamless persistence with same interface
  • System automatically manages:
  • moving “live” items to backing store
  • retrieving stored items when necessary
  • Control storage representation:
  • User-provided transformation (pickling)
  • Automatic adaptation
  • Pluggable storage backends

15

slide-18
SLIDE 18

The Premise

  • Not just about “plumbing” / transport
  • More explicit support for writing stream

manipulation code via the data abstractions

  • Wall-clock time as a recognized entity
  • Time as an indexing mechanism naturally

admits synchronization, data persistence

16

slide-19
SLIDE 19

As we continue

  • Intro
  • Premise
  • Temporal Streams
  • Programming Model
  • System Design & Implementation
  • Evaluation
  • Conclusion & Questions

17

slide-20
SLIDE 20

System Design & Implementation

18

slide-21
SLIDE 21

Channel Data Management

  • Significant portion of system complexity
  • Index live and stored data
  • Interface with storage backend
  • Pickling – content transformation
  • Data delivery
  • Connection management
  • Lifecycle management

19

slide-22
SLIDE 22

Channel Architecture

Live Channel Layer

  • ldest

now

Generic Persistence Layer Persist Trigger Queue Pickling Handler Backend New Item Triggers GC Triggers Garbage List Producers & Consumers put get GC Thread get

persist_item get_interval init cleanup

f Configured Backend Channel Interaction Layer

Channel Book-keeping

Worker Threads

20

slide-23
SLIDE 23

Channel Architecture

Live Channel Layer

  • ldest

now

Generic Persistence Layer Persist Trigger Queue Pickling Handler Backend New Item Triggers GC Triggers Garbage List Producers & Consumers put get GC Thread get

persist_item get_interval init cleanup

f Configured Backend Channel Interaction Layer

Channel Book-keeping

Worker Threads

20

slide-24
SLIDE 24

Three Layer Stack

  • Channel interaction layer
  • Hooks in live channel
  • Sends data to generic persistence layer
  • Generic persistence layer
  • Queues items for transformation
  • Guarantees temporal ordering and one writer
  • Backend layer
  • init, get interval, put item
  • Interfaces with concrete storage

21

slide-25
SLIDE 25

Filesystem-based Backend

  • Exploit properties of the above layer
  • Like ISAM, but append-only
  • Concurrent reads & one writer, no locks
  • Treat secondary storage like a big

ring-buffer

  • Based on results from

Hyperion/StreamFS (USENIX ’07)

22

slide-26
SLIDE 26

Moving along

  • Intro
  • Premise
  • Temporal Streams
  • Programming Model
  • System Design & Implementation
  • Evaluation
  • Conclusion & Questions

23

slide-27
SLIDE 27

Evaluation

24

slide-28
SLIDE 28

Evaluations

  • System-level evaluation:
  • Quantitative overhead of components
  • Storage & retrieval
  • Scaling under contention
  • Pickling
  • Application-based evaluation:
  • Airport surveillance
  • Video analysis & storage
  • Historical queries
  • Show you can achieve good performance

25

slide-29
SLIDE 29

Channel Persistence Evaluation

  • Single consumer backend overhead
  • OProfile system-wide measurements
  • Callgrind instructions in backend
  • Single consumer baseline get overhead
  • Multiple stream scaling
  • Metadata baseline
  • RGB video data
  • RGB with pickling handlers
  • Dynamic load adjustment w/ pickling
  • Mixed live/stored workload

26

slide-30
SLIDE 30

Multiple Stream Scaling

1us 10us 100us 1ms 100ms 1s 1 2 3 4

latency With Data

~ ~ ~ ~

1us 10us 100us 10ms 100ms 1 2 3 4 8

Metadata Only

~ ~ ~ ~

(a) RGB video streams

1ms 10ms 100ms 1s 4/2 3/5 6 8 12

RGB/MJPEG MJPEG

(b) with JPEG pickling

Item latencies by statistical percentile

27

slide-31
SLIDE 31

Multiple Stream Scaling

1us 10us 100us 1ms 100ms 1s 1 2 3 4

latency With Data

~ ~ ~ ~

1us 10us 100us 10ms 100ms 1 2 3 4 8

Metadata Only

~ ~ ~ ~

(a) RGB video streams

1ms 10ms 100ms 1s 4/2 3/5 6 8 12

RGB/MJPEG MJPEG

(b) with JPEG pickling

Graceful scaling under increasing contention

27

slide-32
SLIDE 32

Multiple Stream Scaling

1us 10us 100us 1ms 100ms 1s 1 2 3 4

latency With Data

~ ~ ~ ~

1us 10us 100us 10ms 100ms 1 2 3 4 8

Metadata Only

~ ~ ~ ~

(a) RGB video streams

1ms 10ms 100ms 1s 4/2 3/5 6 8 12

RGB/MJPEG MJPEG

(b) with JPEG pickling

Graceful scaling under increasing contention

27

slide-33
SLIDE 33

Airport Surveillance

  • Application
  • Pick streams of interest
  • Store historical data
  • Approximate interest
  • Modeled on ASAP

28

slide-34
SLIDE 34

Components & Dataflow

Agent 4 RGB Video 2 Sensors Face Detectors Random Historical Queries

Feature Aggregators

Video Channels Face Channels Motion Channels

Optical Flow

Sensor Channels

Video Producers Sensor Producers

29

slide-35
SLIDE 35

Components & Dataflow

Agent 4 RGB Video 2 Sensors Face Detectors Random Historical Queries

Feature Aggregators

Video Channels Face Channels Motion Channels

Optical Flow

Sensor Channels

Video Producers Sensor Producers

29

slide-36
SLIDE 36

Measurements

  • TS Historical Queries: 4-15ms
  • ASAP Published Live Queries: 135-175ms

Analysis?

  • Same hardware, same feature detectors.
  • ASAP’s comms layer reinvents time-oriented

access anyway.

  • Temporal streams gives you stream persistence.
  • Temporal streams also allows transparent
  • verlapping of communication and computation!

30

slide-37
SLIDE 37

Recap

Value of time at the system level.

  • Time-based distributed data structures
  • Automatic data management
  • Transparent stream persistence

Bottom-up approach.

  • No computational model imposed
  • Lightweight; loose coupling
  • Stream data substrate

31

slide-38
SLIDE 38

That’s all folks

  • Thank you!
  • Questions?

32

slide-39
SLIDE 39

33

slide-40
SLIDE 40

34

slide-41
SLIDE 41

35

slide-42
SLIDE 42

Extra Slides

36

slide-43
SLIDE 43

Backend Comparison

daemon daemon fs+disk daemon kernel app be_lib app app fs+disk app kernel

100 200 300 400 500 600 fs1 gpfs1 mysql null OProfile samples (in thousands)

OProfile data: same workload, different backends.

37

slide-44
SLIDE 44

Measurements

  • Standalone feature detectors
  • “In system” latencies
  • Pipeline latencies
  • Effect as RGB streams are added
  • Effect as working set grows
  • Historical data queries
  • Data overheads for protocol versions

38

slide-45
SLIDE 45

Measurements

Face Opt

10 20 30 40 50 60 70 80 90 100

Latency in ms

Standalone 0RGB 1RGB 2RGB 1RGB-30mins 1RGB-45mins

15-25% includes network-related overhead and contention

38

slide-46
SLIDE 46

Related Work

39

slide-47
SLIDE 47

Categories

  • Parallel Batch Processing
  • Stream Databases / Processing Engines
  • Stream Languages
  • Distributed Programming
  • Processing Streams/FIFOs

40

slide-48
SLIDE 48

Relationship to Other Work

  • A middleground
  • Below full SDMS and stream languages
  • Above non-stream oriented distributed

communications

  • Roughly analogous to non-streaming:
  • Distributed Data Structures (Gribble, et al.)
  • BerkeleyDB (Seltzer, et al.)
  • Boxwood (MacCormick, et al.)

41

slide-49
SLIDE 49

Key Differentiation

  • No computational model imposed
  • Lightweight; loose coupling
  • Stream data substrate

42

slide-50
SLIDE 50

One Example

Unblinking Eyes, for $20 Million, at Freedom Tower September 24, 2008 “If you have ever wondered how security guards can possibly keep an unfailingly vigilant watch on every single one of dozens

  • f television monitors, each depicting a different scene, the

answer seems to be (as you suspected): they can’t. Instead, they can now rely on computers to constantly ana- lyze the patterns, sizes, speeds, angles and motion picked up by the camera and determine - based on how they have been pro- grammed - whether this constitutes a possible threat. In which case, the computer alerts the security guard whose own eyes may have been momentarily diverted. Or shut.” The New York Times, City Room blog

43

slide-51
SLIDE 51

Common Traits

  • Continuous streams
  • Heavy-weight
  • Unstructured
  • Feature detection/extraction
  • Computationally intensive
  • Distributed analysis
  • Historical data

44

slide-52
SLIDE 52

Current Approaches

  • Centrally controlled & managed execution
  • Stream Data Management System (SDMS)
  • Stream Processing Engines
  • Declarative query languages
  • Continuous queries (CQ)
  • Independent communicating components
  • General distributed programming
  • Loose coupling
  • Lower level / more procedural

45

slide-53
SLIDE 53

Gap

  • Integrate:
  • Higher-level time-based model
  • General distributed application approach
  • Keep looser coupling
  • Independent communicating components
  • Distributed data structures

46

slide-54
SLIDE 54

Relationship to Other Work

  • A middleground
  • Below full SDMS
  • Above non-stream oriented distributed

communications

  • Roughly analogous to non-streaming:
  • Distributed Data Structures (Gribble, et al.)
  • BerkeleyDB (Seltzer, et al.)
  • Boxwood (MacCormick, et al.)

47

slide-55
SLIDE 55

Programming Model

  • Distributed data structures – channel
  • Threads communicate via channels

Producer

Video Video

Producer Feature Detector Feature Detector

Features Features

Analysis

48

slide-56
SLIDE 56

Time Variables

Variable Param(s) Definition now

  • current time

newest ch timestamp of newest visible item in channel ch

  • ldest

ch timestamp of oldest visible item in channel ch newest-after ch, ts timestamp of newest visi- ble item in channel ch if the item’s timestamp is af- ter ts, ∞ otherwise next ts ts + ǫ (the smallest timestamp > ts)

49

slide-57
SLIDE 57

Producer Code Example

while ( true ) { Item item = new Item ( dataBuffer ) ; // Put the item i n t o the channel with // the d e f a u l t timestamp

  • f

’now ’ chanConn . putItem( item ) ; . . . }

50

slide-58
SLIDE 58

Consumer Code Example

Time32 lower = Time32 . newest ; Time32 upper = Time32 . v_now ; while ( true ) { Item item = chanConn . getItem( lower , upper ) ; // Do something with the item . . . lower = Time32 . next( item . getTimestamp ( ) ) ; }

51

slide-59
SLIDE 59

Channel Groups

  • Only modify the visibility of items
  • One channel may belong to many groups

Text Stream Audio Stream

reference stream

... ...

Group A Group B

Text Stream

52

slide-60
SLIDE 60

Channel Groups

  • Only modify the visibility of items
  • One channel may belong to many groups

Text Stream Audio Stream

reference stream

... ...

Group A Group B

Text Stream

52

slide-61
SLIDE 61

Persistent Representation

  • Application provided pickling handler
  • Arbitrary N-to-1 mapping function
  • Transforms item for storage
  • Vary pickling function by load
  • Preserves time interval correspondence

Before Pickling After Pickling

53

slide-62
SLIDE 62

Local Channel Gets

Microseconds per channel get

items

0.4 0.6 0.8 1 1.2 1.4 11 101 1001 10001 100001 1000001

0.43 0.46 0.57 0.68 0.96 1.30 0.42 0.40 0.43 0.49 0.59 0.70

max average

Increasing items in the channel

54

slide-63
SLIDE 63

Local Channel Gets

Microseconds per channel get

interval size

1 2 3 4 5 6 7 8 9 10 0.6 0.9 1.2 1.5 1.8 2.1 2.4 2.7 3

0.99 1.17 1.17 1.59 1.60 2.06 2.05 2.03 2.09 2.81 0.61 0.79 0.92 1.19 1.33 1.60 1.73 1.85 2.01 2.39

max average

Increasing items in an interval

54

slide-64
SLIDE 64

Remote Channel Gets

Frame drops (motion JPEG, ~30fps)

simultaneous consumers

1 2 3 4 5 6 7 1 2 4 8 12 16 24 32

0 0 1.16667 2.66667 5.16667 6.83333 0 0 1 1 1 4

sum over all max of any client

Increasing consumers – MJPEG (sum and max)

55

slide-65
SLIDE 65

Remote Channel Gets

Frame drops (motion JPEG, ~30fps)

simultaneous consumers

0.1 0.2 0.3 0.4 0.5 1 2 4 8 12 16 24 32

0 0 0.0972222 0.166667 0.215278 0.213542

average per client

Increasing consumers – MJPEG (average)

55

slide-66
SLIDE 66

Remote Channel Gets

Frame drops (uncompressed, ~30fps)

simultaneous consumers

2 4 6 8 10 1 2 4 8 12

1.33333 9.5 1 3

sum over all max of any client

Increasing consumers – RGB (sum and max)

55

slide-67
SLIDE 67

Remote Channel Gets

Frame drops (uncompressed, ~30fps)

simultaneous consumers

0.2 0.4 0.6 0.8 1 1 2 4 8 12

0.166667 0.791667

average per client

Increasing consumers – RGB (average)

55

slide-68
SLIDE 68

Remote Channel Gets

Frame drops (RGB, ~30fps, replication)

simultaneous consumers

2 4 6 8 10 12 16 18 20 22

9 9.33333 10 10.6667 3 3 3 2

sum over all max of any client

Increasing consumers – Replicated (sum and max)

55

slide-69
SLIDE 69

Remote Channel Gets

Frame drops (RGB, ~30fps, replication)

simultaneous consumers

0.2 0.4 0.6 0.8 1 16 18 20 22

0.5625 0.518519 0.5 0.484848

average per client

Increasing consumers – Replicated (average)

55

slide-70
SLIDE 70

Channel Group

Node 1 (producer)

Video Channel Audio Channel

Video Producer Thread Audio Producer Thread

Node 2 Node 3

Video Consumer Thread Audio Consumer Thread

Experimental Setup

56

slide-71
SLIDE 71

Channel Group

Average ms of skew per frame (motion JPEG, ~30fps)

test run

5 10 15 20 25 30 35 40 1 2 3 4 5

33.632 32.383 33.332 32.887 33.237 8.378 8.381 8.647 8.693 8.569

Without Groups With Groups

56

slide-72
SLIDE 72

Backend Comparison

fs1 gpfs1 mysql null

4 8 12 5.38 8.81 0.29 time in backend (%) 42 46 50 54 48.22

Time spent in backend

57

slide-73
SLIDE 73

Backend Comparison

daemon daemon fs+disk daemon kernel app be_lib app app fs+disk app kernel

100 200 300 400 500 600 fs1 gpfs1 mysqlnull OProfile samples (in thousands)

System-wide time

57

slide-74
SLIDE 74

Backend Comparison

Backend fs1 gpfs1 mysql null Total Instructions (Millions) 128 143 5,477 126 Instructions in Backend 1.99% 1.83% 97.50% 0.03% NOTE: Instructions in Backend percentages do not include initialization instructions.

Callgrind (single producer)

57

slide-75
SLIDE 75

Overhead of Storage Subsystem

Number of Items 25 50 75 100

Microseconds

50 100 150 200 250

∼118 µsecs

58

slide-76
SLIDE 76

Persistence Automatic Load Adjustment

item number 100 200 300 400 500 600

seconds

0.5 1 1.5 2 2.5 3 3.5 4 item number 600 1200 1800 2400 3000

seconds

0.005 0.01 0.015 0.02

  • Per-item storage latency
  • Automatically adjusting to overload
  • Dynamically vary pickling handler

59

slide-77
SLIDE 77

Mixed Workload by Distribution

percentage of live gets 20 40 60 80 100

milliseconds

5 10 15 20 25 30 35 40 45 uniform zipf binomial

50 60 8 8.5 9 9.5 10

Per-get time with historical query distribution

60

slide-78
SLIDE 78

Unary Feature Detector – main

int main ( int argc , char ∗∗argv ) { rt_sys_handle_t ∗rtsh ; conn_endpt_t inchan ,

  • utchan ;

cmdargs_t args ; // Parse command−l i n e args parse_args(&args ) ; // Connect to f r o n t end and contact super−nodes . rtsh = init rt ( argv [ 1 ] ) ; // Get channel d e s c r i p t o r . inchan = add chan( rtsh , args . input_name ) ;

  • utchan = add chan( rtsh ,

args . output_name ) ; // Run the transform f u n c t i o n transform ( rtsh , &args , &inchan , &outchan ) ; // . . .

61

slide-79
SLIDE 79

Unary Feature Detector – Transformation

void transform ( rt_sys_handle_t ∗rtsh , args_t ∗args , cendpt_t in_ch , cendpt_t out_ch ) { // Create l o c a l copy

  • f

i n c h to in // . . . while ( ! done ) { // Get one item item− >status = conn get 1 i (in , &low , &up , item ) ; // S u c c e s s f u l get i f ( item− >status == 0 && item− >buf_len >= 1) { // Process item , r e s u l t in buf2 rval = conn put( out_ch , buf2 , buf2_sz , &item− >ts ) ; // . . .

62

slide-80
SLIDE 80

Unary Feature Detector – Optical Flow Example

decode_vid_hdr ( item− >buf , &height , &width , &bpp , &c ) ; // make g r a y s c a l e rgb_to_grayscale ( buf3 , DATA_OFFSET ( item− >buf ) , width , height , bpp ) ; // halve framerate i f (i & 1 == 1) { goto skip ; } // do OpenCV o p t i c a l flow n = detect_optflow1 ( buf3 , width , height , buf2 ) ; // . . . send r e s u l t s in buf2 . . .

63

slide-81
SLIDE 81

Historical Query Generator

while ( true ) { // Generate a random time i n t e r v a l based // on rp ’ s params random_gen(&lower , &upper , percentage , &rp ) ; // Get rp . n items rval = conn_get_n ( chan , &lower , &upper , bufs , bufsizes , rp . n , metadata ) ; . . . }

64

slide-82
SLIDE 82

Binary Feature Detector – main

// . . . // Parse command−l i n e args // Connect to f r o n t end and contact super−nodes . // Get channel d e s c r i p t o r . inchan = add chan( rtsh , args . input_name ) ; inchan2 = add chan( rtsh , args . input_name2 ) ;

  • utchan = add chan( rtsh ,

args . output_name ) ; // Create channel group int ch_nums [ 2 ] = {inchan . chan_num , inchan2 . chan_num }; make group( rtsh , ch_nums , gr_nums , 2 , 1 ) ; // . . . Create background get thread . . . // Run the transform f u n c t i o n

65

slide-83
SLIDE 83

Binary Feature Detector – Background Fetching Thread

// . . . while ( ! done ) { // Get one item item− >status = conn get 1 i (in , &low , &up , item , gr_nums [ 1 ] ) ; // S u c c e s s f u l get i f ( item− >status == 0 && item− >buf_len >= 1) { low = time add(&item− >ts , &one_micro ) ; ATOMIC_PUT(&globbg , item− >buf ) ; // . . . } }

66

slide-84
SLIDE 84

Binary Feature Detector – Foreground Separation

decode_vid_hdr ( item− >buf , &height , &width , &bpp , &c ) ; // grab c u r r e n t background ATOMIC_GRAB(&buf , &globbg ) ; cvSetImageData(&bgImg , DATA_OFFSET ( buf ) , width ∗3); // do foreground s e p a r a t i o n res = detect_fgdata1 ( DATA_OFFSET ( item− >buf ) , &bgImg , &tmpIn , width , height , buf2 ) ; // . . . send r e s u l t s in buf2 . . .

67

slide-85
SLIDE 85

Binary Feature Detector – Camera Change Example

decode_vid_hdr ( item− >buf , &height , &width , &bpp , &c ) ; // histogram scene change res = detect_schist1 ( DATA_OFFSET ( item− >buf ) , &lastHist , width , height , corr_hist , ncorr_hist , &curr_start , 0 . 5 ) ; . . . i f ( res > threshold ) { upper = now( ) ; // f e t c h BG images from bg chan to confirm lower = TIME SUB( item− >ts , TIME10MS ) ; conn get n( bg_chan , &lower , &upper , bufs , bufsizes , 10 , NULL , gr_nums [ 1 ] ) ; // . . .

68

slide-86
SLIDE 86

Airport Surveillance

Node G Node A

Agent 4 RGB Video 2 Sensors Optical Flow Feature Aggregator Sensor Producers Video Producers

1 2 4

Node B

Optical Flow

2

Node C

Optical Flow

2

Node D

Face Detector

2

Node E

Face Detector

2 1

Node H

Face Det. Feature Aggregator

1

Node H

Sensor Historical Queries

2

Video Historical Queries

4

Topology

69

slide-87
SLIDE 87

Airport Surveillance

Component Configuration Total +Nodes Agent 1 per node, hosts 4 vid. / 2 sensor 2 2 Producers 6 per ASAP node, one per stream 12

  • Historical Query

6 per dedicated node 12 2 Face Detection 2 per dedicated node 8 4 Optical Flow 2 per dedicated node 8 4 Face Aggregator 1 per dedicated node 1 1 Optical Flow Aggregator 1 per dedicated node 1 1

The “+Nodes” column specifies the additional nodes required by each column.

69

slide-88
SLIDE 88

Airport Surveillance

Face FaceAgg Opt OptAgg

10 20 30 40 50 60 70 80 90 100

Latency in ms

Standalone 0RGB 1RGB 2RGB 1RGB-30mins 1RGB-45mins

Component Latency in ms.

69

slide-89
SLIDE 89

Airport Surveillance

All Historical RGB Compressed

10 20 30 40

Time in ms 0RGB 1RGB 2RGB 1RGB-30mins 1RGB-45mins

Query Time in ms.

69

slide-90
SLIDE 90

Airport Surveillance

Data Video Face Optical Flow Sensor Payload 230,408 128 128 1024 Response Header 64 64 64 64 Item Metadata 20 20 20 20 Total System Data 84 84 84 84 Total 230,492 212 212 1108 Overhead % 0.036% 39.62% 39.62% 7.58%

System Data Overheads in bytes

69

slide-91
SLIDE 91

Airport Surveillance

Data Video Face Optical Flow Sensor Payload 230,408 128 128 1024 Response Header Len 2 2 2 2 Response Header 13 13 13 13 Data Header Len 2 2 2 2 Data Header 4 3 3 3 Item Metadata Len 2 2 2 2 Item Metadata1 15-21 14-20 14-20 14-20 Total System Data 38-42 36-40 36-40 36-40 Max Total 230,450 168 168 1064 Overhead % 0.018% 23.81% 23.81% 3.76%

System Data Overheads (Variable Length)

69

slide-92
SLIDE 92

Port Asset Tracking – Drools Syntax Example

rule ” Syntax Example” when [ condition 1] [ condition 2] . . . then [ action 1] [ action 2] . . . end

70

slide-93
SLIDE 93

Port Asset Tracking – Truck Entering Port

rule ”Truck Entering Port ” when $tee : TruckEnterEvent () then log ( $tee ) end

71

slide-94
SLIDE 94

Port Asset Tracking – Truck Leaving Port

rule ”Truck Leaving Port ” when $tle : TruckLeaveEvent ( $tsl : tmstamp , $id1 : id ) $tee : TruckEnterEvent ( $tse : tmstamp , id == $id1 ) then diff = ( $tsl . getTime () − $tse . getTime ( ) ) / 1000) log ( ”Truck %d l e a v i n g at %d secs ” , $id1 , diff ) retract ( $tle ) retract ( $tee ) insert (new TruckCycle ( $tee , $tle , diff )) end

72

slide-95
SLIDE 95

Port Asset Tracking – Phantom Truck Leaving Port

rule ”Phantom Truck Leaving Port ” when $tle : TruckLeaveEvent ( $id1 : id ) not ( exists ( TruckEnterEvent ( id == $id1 )) ) then log ( ”No enter event : phantom truck %d” , $id1 ) // diagnose anomaly diagnosePhantom ( $tle ) end

73

slide-96
SLIDE 96

Port Asset Tracking – Phantom Truck Actions

// r u l e ”Phantom Truck Leaving Port ” a c t i o n s void diagnosePhantom ( TruckLeaveEvent tle ) { Long ts = tle . getTimestamp ( ) . getTime () / 1000; // based

  • n

estimated tr u ck timing , f i n d p o t e n t i a l // video

  • f

e n t r y Long tentry = ts − getAvgCycleTime ( ) ; Long tdelta = getAvgCycleTime () / 10; boolean done = found = f a l s e ; while ( ! done && ! found ) { // ± 10% around p o t e n t i a l e n t r y Item [ ] i = entryCam . getItems ( tentry − tdelta , tentry + tdelta ) ; // show human

  • p e r a t o r

OpOutput

  • o = showOperator ( i ) ;

// u si n g

  • p e r a t o r

feedback , conti nue s e a r c h i n g tentry = oo . getTEntry ( ) ; tdelta = oo . getTDelta ( ) ; found = oo . isFound ( ) , done = oo . isDone ( ) ; } // . . .

74

slide-97
SLIDE 97

Port Asset Tracking – Truck Leaving Port Late

rule ”Truck Leaving Port Late ” when // >55 mins i s l a t e ( time i s in seconds ) $tc : TruckCycle ( time > (60∗55)) then log ( ”Truck Le ft Late ! ” ) // diagnose anomaly diagnoseLateDeparture ( $tc ) end

75

slide-98
SLIDE 98

Port Asset Tracking – Late Departure Actions

// r u l e ”Truck Leaving Port Late ” a c t i o n s void diagnoseLateDeparture ( TruckCycle tc ) { Long len = tc . getTruckLeaveEventTime () − tc . getTruckEnterEventTime ( ) ; Long tdelta = len / 10; // do a b i n a r y s e ar c h f o r the tr u ck d e l a y ; f i n d // the f i r s t p o i n t where the tr u ck s t a r t s running l a t e // s t a r t at the middle

  • f

the j o u r n e y Long ts = tc . getTruckEnterEventTime () + ( len / 2 ) ; while ( ! done ) { // get a p p r o p r i a t e channel f o r time i n d e l i v e r y c y c l e chan = getVideoChannelByTime ( tc , ts ) ; // . . . Item [ ] i = chan . getItems ( ts − tdelta , ts + tdelta ) ; // show

  • p e r a t o r

video OpOutput

  • o = showOperator ( i ) ;

// modify s e ar c h based

  • n

feedback // . . .

76

slide-99
SLIDE 99

Port Asset Tracking – Truck Missed Checkpoint

rule ”Truck Missed Checkpoint ” when // i f we have a gap i n c h e c k p o i n t s $ce1 : CheckptEvent ( $id1 : id , $point : point > 1) not ( exists ( CheckptEvent ( id == $id1 && point == ( $point −1)) )) // c o l l e c t a l l p r i o r c h e c k p o i n t s i n t o a l i s t $prior : ArrayList () from collect ( CheckptEvent ( id == $id1 , $p2 : point < $point ) ) // f i n d the most r e c e n t checkpoint b e f o r e m i s s i n g $lp : Number () from accumulate ( CheckptEvent ( id == $id1 , $p2 : point < $point ) , max ( $p2 ) ) then log ( ”Truck %d m i s s i n g checkpoint # %d” , $id1 , $point −1) log ( ” Last checkpoint # %d : %s ” , $lp , $prior ) // diagnose anomaly diagnoseMissedCheckpoint ( $ce1 , $prior , $lp ) end

77

slide-100
SLIDE 100

Port Asset Tracking – Missed Checkpoint Actions

// r u l e ”Truck Missed Checkpoint ” a c t i o n s void diagnoseMissedCheckpoint ( CheckptEvent ce , ArrayList<CheckptEvent> lst , Long lastPointId ) {

5

HashMap<Long , CheckptEvent> map = pointListToMap ( lst ) ; CheckptEvent last = map . get ( lastPointId ) ; // . . .

10

Channel c = getVideoChanByCheckpt ( lastPointId +1); // get data between two good c h e c k p o i n t s Item [ ] i = c . getItems ( last . getTimestamp ( ) , ce . getTimestamp ( ) ) ;

15

// use video f o r d i a g n o s i s // . . .

20

}

78

slide-101
SLIDE 101

Code Complexity

Component SLOC Generated SLOC Supernode (Erlang) 510 1006 Front-end (Python) 192

  • Utilities (C)

1544

  • IDL (Sun RPC → C)

231 1084 C Client Library (C) 4507

  • 5 Storage Backends (C)

2030

  • Storage Backend Common (C)

250

  • Backend IDL (Sun RPC → C)

45 282 C Runtime Totals 8449 + 276 (IDL) 1366 Java Client Library (Java) 1663

  • First Generation System

79

slide-102
SLIDE 102

Code Complexity

Component SLOC Generated SLOC fs1 771

  • gpfs1

568

  • mysql

391

  • pgsql

271

  • null

29

  • Common

250

  • Common IDL

45 282 Total 2280 + 45 (IDL) 282

Storage Backends

79

slide-103
SLIDE 103

Code Complexity

Component SLOC Generated SLOC IDL (Protobuf → Java) 115 5692 Java Client Library 1517

  • Second Generation System

79

slide-104
SLIDE 104

Code Complexity

Component SLOC Airport Surveillance (C) 1050 Traffic Monitoring (C) 810 Port Asset Tracking (DRL) 75 Port Asset Tracking (Java) 250

Applications

79

slide-105
SLIDE 105

Value of System Philosophy

  • V(A)aaS – video-analytics-as-a-service
  • Live stream analysis in the cloud
  • Provides flexibility
  • Characteristics:
  • Looser coupling
  • “Black box” components
  • Spans administrative domains
  • Glue between distributed components

80

slide-106
SLIDE 106

Themes

  • Transparent vs. Opaque Computation
  • Structured vs. Unstructured Streams
  • Granularity of Stream Data
  • Granularity of Dataflow
  • Streams & Computation

81