Complex Event Processing(CEP)

Transcript

Advanced Software Engineering
INFORMATION FLOW PROCESSING Systems:
COMPLEX EVENT PROCESSING (CEP) model
Francesco NOCERA
Outline
• Information Flow Processing (IFP) domain
• Data Stream Processing Systems (DSPS) Vs Complex Event
Processing (CEP) Systems
• CEP Model
• Applicazioni del CEP in ambito sanitario: SMS
• EsperTech
- Esper in action!
• Apache Flink
- FlinkCEP in action!
Francesco NOCERA
Introduzione
Information Flow Processing (IFP) systems
- sistemi sviluppati negli ultimi decenni con l’obiettivo di
ottenere
l’elaborazione
tempestiva
di
grandi
flussi
di
informazioni provenienti dall’esterno del sistema verso l’interno
 processing di un continuo flusso di dati
 fonti distribuite geograficamente ad un tasso imprevedibile in termini di
tempestività di risposta a query complesse
Francesco NOCERA
Domini applicativi
 Monitoraggio ambientale
 Mercato finanziario
 Rilevazione di frodi
 Sistemi di gestione dei dispositivi RFID
 Sistemi di controllo aziendale
 Sistemi di monitoraggio delle condizioni di salute
Francesco NOCERA
Modello generico di un sistema IFP
Una macchina IFP è uno strumento che processa i flussi di dati generati dagli information sources,
applicandone una serie di regole che genereranno un nuovo flusso di dati in uscita, recapitato
agli information sinks. Ogni flusso è costituito di information items i quali sono soggetti a
operazioni di filtraggio, combinazione e aggregazione. L'intera macchina è gestita da un terzo attore, il
rule manager che si occupa dell’implementazione del set di regole e gestisce il funzionamento
dell'intera macchina.
Francesco NOCERA
Modelli sistemi IFP
Modelli emersi, in competizione tra loro:
 Data Stream Processing (DSP) model [Babcock et al., 2002]
 Complex Event Processing (CEP) model [Luckham, 2001]
Francesco NOCERA
Data Stream Processing (DSP) model
 descrive il problema IFP come un flusso in ingresso proveniente da fonti interne al sistema. Data
Stream Management System (DSMS) è il modello tradizionale e si basa sull’ approccio del DBMS
(operatori SQL, join, operatori di selezione e aggregazione) presentando due sostanziali differenze:
1. I DSMS lavorano su dati in transizione che sono continuamente aggiornati, mentre i
DBMS su dati persistenti con aggiornamenti poco frequenti
2. I DSMS eseguono interrogazioni continuamente in esecuzione fornendo risposte
aggiornate sulla base dei nuovi flussi in ingresso, mentre i DBMS inviano query singole con
risposte singole
Francesco NOCERA
Complex Event Processing (CEP) model
 considera il flusso di informazioni come un evento verificatosi esternamente al sistema il quale
deve essere FILTRATO e COMBINATO per individuare eventi di ad alto livello.
il modello si basa sull’individuazione di eventi di basso livello che, in presenza di alcune
caratteristiche, vanno a formare eventi di alto livello (Composite Events).
I contributi a questo modello provengono da diverse comunità:
 Distributed information Systems
 Business process automation
 Control systems
 Network Monitoring
 Sensor Networks
Francesco NOCERA
Cosa è un evento?
 L’evento è un qualcosa di noto che accade all’interno o all’esterno di un
sistema; esso potrebbe rappresentare un problema o un impedimento,
un’opportunità, o un comportamento inaspettato. Il termine evento è spesso
utilizzato per riferirsi intercambiabilmente sia al verificarsi di uno specifico
insieme di condizioni, conosciuto come evento complesso; che all’ occorrenza di
un insieme di eventi singoli che definiscono un evento composito.
 La rilevazione di un evento complesso è il requisito fondamentale richiesto
dall’utente finale, cioè dal event consumer
Francesco NOCERA
Sezioni di un evento
 Ogni evento è suddiviso in due sezioni: la testa e il corpo.
 La testa contiene tutte le informazioni relative all’evento, come l’indice di specificazione, il
tipo, il nome, il marco temporale, il numero delle occorrenze e l’identificatore del generatore
dell’evento. Tutte questi elementi sono fissi.
 Il corpo contiene tutte le informazioni riguardo le cause che hanno comportato la
rilevazione dell’evento. All’interno del corpo è necessario che ci sia una descrizione completa
di ogni informazione che potrebbe essere di particolare interesse per l’osservatore del
sistema evitando che esso abbia la necessità di ricondursi all’origine della sua rilevazione.
Generalmente il corpo dell’evento utilizza un lessico semplice e standardizzato affinché
l’evento sia compreso da tutti gli osservatori.
Francesco NOCERA
Ciclo di vita di un evento
 Ad ogni evento è associato un ciclo di vita. Tale ciclo è suddiviso in 4 fasi
I.
Ogni evento è generato da una sorgente che potrebbe
essere un’applicazione, una memoria, un servizio, un
processo, un trasmettitore o un sensore. La rilevanza di
un nuovo evento è valutata da un preprocessore, il quale
a sua volta genererà un nuovo evento con un livello di
interesse più importante. Non tutti gli eventi avranno lo
stesso formato a causa della variabilità dei generatori; in
questi casi sarà necessaria una conversione prima di
essere depositato sul canale di comunicazione. In fase di
ricezione dell’evento i ricevitori possono prevedere
dispositivi di riconversione del formato.
II.
Il canale degli eventi trasporta tutti gli eventi dello
stesso
formato
dai
generatori
elaborazione degli eventi.
Francesco NOCERA
al dispositivo
di
Ciclo di vita di un evento
III. Una volta che l’evento è stato rilevato è avviata
l’elaborazione dell’evento. Questa fase prevede la valutazione
della parte condizionale delle regole e, in caso di verifica dei
vincoli, la esecuzione delle azioni. Il set di regole, come già
evidenziato, è stabilito in fase di progettazione dal rule manager e
generalmente sono modificabili e aggiornabili a seconda del
dominio di applicazione del sistema.
VI. L’esecuzione delle azioni (event-driven activity) include
l’invocazione di servizi, l’avvio di procedure, la notifica di eventi
presso la rete dei destinatari, la generazione di nuovi eventi e il
salvataggio dell’evento in locazioni di memoria fisiche per
l’utilizzo in elaborazioni successive. La rilevazione di un evento
può attivare numerosi sotto-attività. L’attivazione di quest’ ultime
può avvenire per mano della macchina di elaborazione o per
opera del ricevitore.
Francesco NOCERA
Complex Event Processing (CEP) System
Il primo sistema che prevedeva l’«event processing engine» utilizzava il modello di
interazione PUBLISH-SUBSCRIBE [Eugster et al. 2003], un paradigma di interazione orientato
ai messaggi e basato sull’indirizzamento indiretto.
Funzionamento:
ogni
utente
esprime
l’interesse
di
ricevere
una
informazione
SOTTOSCRIVENDO (subscribing) una specifica Classe di eventi, mentre le fonti di informazioni
(sources) PUBBLICANO (publishing) eventi senza indirizzarli ai riceventi (sinks).
Due versioni:
 TOPIC BASED: i publisher inviano i topics predefiniti ai riceventi
 CONTENT BASED: i subscribers modificano i filtri per selezionare gli eventi di interesse
Francesco NOCERA
I sistemi CEP sono un’estensione dei P-S in quanto permettono ai subscribers di esprimere il
proprio interesse verso i COMPOSITE EVENTS individuando modelli complessi di eventi in
ingresso tramite sequenziamento e relazioni di ordinamento.
In molti sistemi con funzionalità più avanzate si adotta una architettura distribuita organizzata
in un insieme di mediatori di eventi (brokers) connessi un una rete (event processing
network) la quale implementa routine specializzate.
In questa tipologia di macchina è fondamentale ottimizzare la LARGHEZZA DI BANDA e il
TEMPO DI LATENZA.
Francesco NOCERA
Modello funzionale di un sistema IFP:
Il flusso di output è influenzato da:
 set rules
 knowledge base
 history
 selection policy (multiple, single,
programmable)
 consumption policy (zero,
selected, programmale)
 load shedding of bursty inputs
Francesco NOCERA
Operators
1. Single-Item Operators: processano gli elementi singolarmente:
•selection operators(σ)
•elaboration operators
•projection (𝚷)
•renaiming(⍴)
Questi operatori sono molto importanti nei linguaggi di rilevamento per selezionare le parti di un
flusso rilevanti.
2. Logic Operators: sono operatori indipendenti dall’ordine che vengono utilizzati per il
rilevamento e verifica di condizioni.
•conjunction
•disjunction
•repetition ( da m a n volte)
•negation
Questi operatori sono ampiamente utilizzati nei linguaggi dichiarativi in quanto permettono di
verificare le condizioni sugli eventi selezionati durante la “condition part”. Essi non sono previsti
nei linguaggi dichiarativi ma posso essere espressi implicitamente.
Francesco NOCERA
Operators
3. Sequences: sono operatori simili agli operatori logici ma catturano gli elementi di
interesse in base all’ordine di arrivo.
E’ presente in molti pattern-based languages - non sono presenti nei trasforming
languages, dove sono esprimibili in maniera implicita- e possono sfruttare i marchi
temporali (causali) per riordinare gli elementi a seconda delle necessità dell’utente.
es. con declarative languages:
4. Iterations: esprimono sequenze illimitate di informazioni che specificano
determinate condizioni di iterazione. Dipendono dall’ordine di elementi e sono
generalmente espressi in modo implicito.
Tali operazioni sono generalmente utilizzati per il recursiving processing.
Francesco NOCERA
Operators
5. Windows: sono utilizzate per prelevare solo limitate porzioni del flusso id ingresso. Le
finestre in realtà devono essere considerate come costrutti che vengono utilizzati assieme agli
operatori.
L’utilizzo di tali costrutti è dovuto al fatto che esistono 2 classi di operatori:
•Bloccanti: esaminano l’intero flusso prima di produrre l’output (Es. Negation and repetition)
•Non-bloccanti : possono produrre un output appena il flusso entra nel sistema ( Es.
conjuction)
Poiché gli operatori bloccanti potrebbero causare problemi in fase di esecuzione, è necessario
limitare il flusso tramite le finestre.
Possiamo definire 2 categorie di finestre:
•Time-based (logiche): non è possibile stabilire a priori il numero di elementi analizzati
•Count-based (fisiche): a priori si definisce la grandezza della finestra e il numero di
elementi
Francesco NOCERA
Operators
A seconda della tipologia di limiti di finestratura definiamo 4 tipologie di finestre:
•Fixed windows: finestre fisse.
•Landmark windows: finestre delimitate inferiormente.
•Sliding windows: finestre i cui i limiti superiori e inferiori che avanzano con l’inserimento
di elementi.
•Pane and Tumble Windows: le prime sono caratterizzate da una dimensione superiore
al numero di elementi da analizzare e le seconde da una dimensione al più uguale affinché
si abbia la sicurezza che tutti gli elementi vengano elaborati almeno una volta
Francesco NOCERA
Operators
Count-based sliding windows
Time-based sliding windows
OSSERVAZIONI:
•Ci sono sistemi che permettono all’utente di definire e usare le finestre , un esempio è
l’ESL.
•Generalmente le finestre sono utilizzate nei linguaggi dichiarativi, mentre i linguaggi
PATTERN-BASED non prevedono l’utilizzo di tali operatori non essendoci operatori
bloccanti; in caso ci fosse la necessità sono previste di tecniche di limitazione
automatica.
Francesco NOCERA
Operators
6. Flow management operators:
sono operatori presenti solo nei trasforming languages e includono:
o
Join operator: sono utilizzati per unire 2 flussi. Bloccanti
o
Bag operators:
o
•
union
•
except: sono prelevati solo gli elementi appartenenti al primo flusso e non al secondo
•
intersect
•
remove-dupicate (rimuove tutti i duplicati da un flusso)
Duplicate operators: utili per duplicare flussi che saranno input per più processi.
esempio con Padres
o
Group-by operators: utili per partizionare il flusso
Bloccanti
o
Order-by operators: utili per ordinare i flussi.
Bloccanti
Francesco NOCERA
Caratteristiche aggiuntive dei linguaggi
I
detecting
languages
necessitano
della
parametrizzazione
e
dell’aggregazione. Il primo aspetto è legato alla necessità di far comunicare più
flussi contemporaneamente, in tale situazione si utilizzano costrutti in grado di
generare relazioni che considerano più flussi; il secondo aspetto è legato alla
necessità di ricavare informazioni medio-globali sui flussi in ingresso e uscita (
ad esempio valori massimi o minimi di determinati attributi).
I declarative languages sono dotati delle flow creation primitives che permettono
di generare nuovi flussi di uscita partendo da tuple salvate in un Database
relazionale.
Ad esempio nel CQL definiamo:
IStream: converte in flusso tutti i nuovi elementi aggiunti in una Tabella.
DStream: converte in flusso tutti gli elementi eliminati da una tabella.
RStream: converte in flusso tutti gli elementi di una tabella.
Francesco NOCERA
CEP Systems
 Rapide [1985]: fornisce un simulatore per il CEP. Abilita l’utente a catturare le relazioni
casuali e temporali tra gli eventi salvandoli nella KB
 GEM[1993]: prima implementazione di un algoritmo per la “detection” su flussi
disordinati (event specific technique)
 DistCED[2003]: permette all’utente di stabilire la durata degli eventi
 CEDR[2007]: propone un “New temporal model” basato su tre sottomodelli selezionabili
dall’utente: System time, Validity Time e Occurence Time. Inoltre l’utente può
intervenire tramite le rule per selezionare la consumption e selection policy
 Cayuga[2007]: è un CEPS con un linguaggio basato sul SQL, detto CEL(Cayuga Event
Language); strutturato sulle clausole: SELECT, FROM, PUBLISH, NEXT (per le sequenze),
FOLD (per le iterazioni)
 NextCEP[2009]: è un sistema incentrato sulla ottimizzazione del set di regole tramite il
“query rewriting”che minimizza l’utilizzo della CPU e riduce il ritardo dovuto al processo
 Raced[2009]: è un sistema designato per scenari su larga scala che organizza i nodi di
detection secondo una struttura ad albero in cui il carico computazionale
delle “subscriptions” più complesse è diviso tra i vari nodi che vanno dalla radice (root)
alle foglie (leaves)
Francesco NOCERA
CEP Systems
 Progress Apama
 OracleCEP
 StreamBase CEP
 Esper
 Apace Flink
Francesco NOCERA
Systematic Mapping Study
Direzioni della ricerca futura evidenziate dallo studio condotto:
 Concetti che necessitano di miglioramenti
 Generalizzazione tecniche di apprendimento e logiche
 Confronto o integrazione con approcci esistenti
 Supporto di formalismi più espressivi specie nell'ambito dello stream reasoning
 Estensione del supporto alle fasi di verifica e validazione, ad es. tramite sistemi
multiagente
 Applicazione delle tecniche proposte in scenari real-world: esigenza nell’ambito dei metodi
di processing dinamico delle regole, delle architetture event-driven, dell’applicazione di
ontologie e nell’utilizzo di query complesse su stream di eventi.
 Approfondimento di alcune categorie nell’ambito dei concetti chiave presi in esame:
 In ambito KC-1(Il comportamento adattativo dei sistemi CEP, regolato da opportune
reazioni in base al flusso di eventi )  il miglioramento del runtime monitoring e delle
fasi di verifica, e l’ottimizzazione dell'event recognition;
 In ambito KC-2(L’impiego di linguaggi, formalizzazioni, modelli in fase di progettazione,
test e verifica ed il relativo impatto nella risoluzione di specifiche problematiche
nell’ambito del processing degli eventi)  la consegna context-aware delle informazioni
Francesco NOCERA
APPLICAZIONI DEL
COMPLEX EVENT PROCESSING
IN AMBITO SANITARIO
A SYSTEMATIC MAPPING STUDY
Francesco NOCERA
Electronic databases (paper pubblicati dal 2010 ad oggi)
- ACM
- IEEE
- Springer
- ScienceDirect
- Google scholar
Paper selezionati: 25
Francesco NOCERA
RQ1: Aree del settore sanitario dove sono state implementate tecniche CEP
Categoria
Casi d’uso
No. paper
1
Personal health and fitness
4
2
Emergency Medical Assistance; Patient safety
4
3
Patient flow management
3
4
Hygiene Compliances-prevention of infections
5
5
Remote Healthcare-Telecare, Telemedicine etc
5
6
Foodborne Disease outbreak
1
7
Hosp. Processes, transportation of drugs/vaccines
1
Francesco NOCERA
Categoria 4: Hygiene Compliances-prevention of infections
• Detection of potential threads of infection
• Tracking inventory of medical equipment for quality assurance
• Monitoring transport of RFID tagged medical goods to prevent
damage
• Monitor hygiene compliance of healthcare workers of
contaminated medical equipment in a hospital
 HyReminder System
Francesco NOCERA
Categoria 5: Remote Healthcare-Telecare, Telemedicine
• Support for the elderly/disabled in their home
• Use of information logistics processing in telemedicine for
patients coping with obesity, remote monitoring and care
devoted to early dementia sufferers
Francesco NOCERA
RQ2: Principali fonti di dati
No.
1
Medical imaging
2
Laboratory and pharmaceutical data
3
Administrative data
4
Sensor data from medical devices that monitor vital signs, social
media, web pages, GPS, RTLS ( Real Time Location System) data
resulting from tracking devices/patients/staff at precise location
Francesco NOCERA
RQ3: Principali CEP query language
CO
Composition operator
SQ
Stream query
RBL
Rule base logic
Categoria
Casi d’uso
1
Personal health and fitness
2
Emergency Medical Assistance; Patient safety
3
Patient flow management
4
Hygiene Compliances-prevention of infections
RBL,SQ,CO
5
Remote Healthcare-Telecare, Telemedicine etc
RBL,SQ,CO
6
Foodboorne Disease outbreak
7
Hosp. Processes, transportation of drugs/vaccines
Francesco NOCERA
RBL,SQ
RBL,SQ,CO
RBL
RBL
RBL,SQ,CO
Francesco NOCERA
Esper è prodotto dalla EsperTech Inc
• framework open-source sotto licenza GNU General Public Licence (GPL)
v2;
• sotto licenza OEM per gli Independent Software Vendors(ISV);
• nella versione Enterprise Edition come software proprietario che
permette l’aggiunta di ulteriori componenti per offrire ad Esper ulteriori
funzionalità;
• disponibile per Java sotto il nome di Esper e per NET sotto il nome di
Nesper
• può essere inglobato in applicazioni standalone, in Application Server e in
Enterprise Service Bus, eseguiti tutti al di sopra di Java 7 o nuove JVM. Le
piattaforme che lo supportano sono Windows, Linux e Solaris.
Francesco NOCERA
• Esper fornisce un Domain Specific Language (DSL) per
processare gli eventi, chiamato Event Processing Language
(EPL): linguaggio dichiarativo per trattare eventi time-based
che giungono ad elevata frequenza, si tratta di un linguaggio
“SQL-Like”.
• L’utilizzo del linguaggio EPL, di facile apprendimento, rende
possibile attuare l’event stream processing (filtering, joins,
aggregation, ecc.) e il complex event processing (pattern
matching su relazioni temporali o causali) utilizzando un
unico linguaggio. Questo linguaggio a differenza del
tradizionale SQL orientato alle tabelle, è orientato agli
oggetti.
Francesco NOCERA
Francesco NOCERA
Esper-Push Service
- servizio che preleva/immette informazioni nel CEP Engine dirigendole/ricevendole da un
web server (su cui è eventualmente implementata la componente EsperHQ)
- gestisce le sessioni e le sottoscrizioni con il paradigma publish-subscribe e con principio
REST-style. In aggiunta il Push service fornisce un sistema request-response per la
gestione delle sottoscrizioni. Tra le sue funzioni vi sono: la gestione delle sorgenti dei dati
che sono tipicamente statements provvedendo al mapping (marshaling, un-marshaling) dei
dati di output per permetterne il trasporto e la comprensione da parte dei destinatari,
gestione dei subscribers e delle sottoscrizioni e garantire la qualità del servizio per la
trasmissione dei dati.
Francesco NOCERA
EsperHQ
Si tratta di una ricca GUI per client sviluppata in HTML5 e JavaScript implementabile su
qualsiasi J2EE servlet engine o application server. EsperHQ interagendo con Esper-Push
Service permette di gestire il CEP engine e la visualizzazione continua e real-time dei dati
(aka Eventlet). Questa componente fornisce un EPL editor per la manipolazione CRUD degli
statement, un debugger, informazioni sull’utilizzo della memoria e metriche circa lo stato
dell’engine. L’Eventlet mostra in vari layout dati real-time provenienti da sorgenti distribuite
(engine distribuiti) con la possibilità di visualizzarli insieme ai dati storici. Per utilizzare
questa componente è necessario un semplice web browser di ultima generazione.
Francesco NOCERA
EsperJDBC
Questa componente trasforma l’engine Esper in un JDBC server endpoint che può essere
interrogato utilizzando il dirver EsperJDBC in un qualunque applicativo. Quindi un qualsiasi
applicativo può interagire con il CEP engine utilizzando lo standard JDBC, sia esso presente
sulla stessa macchina del CEP engine oppure remoto.
EsperHA
Esper High-Availability (EsperHA) è una soluzione completa per evitare tempi di inattività
dell’engine, migliorarne le opzioni di resilienza, e assicurare recovery sia in situazioni di
failure che per ordinari spegnimenti.
Francesco NOCERA
Esper invece di memorizzare i dati ed eseguire query su essi come i tradizionali database,
Esper memorizza le query e le esegue sui dati che giungono in input. L’engine lavora in realtime e quando gli eventi giunti verificano le condizioni imposte dalle query, esso provvede a
comunicarlo a listner interessati, così che essi avviino determinate azioni (generazione di nuovi
eventi da sottoporre ad altre query, segnalazioni nella GUI, avvio di processi, ecc.). Inoltre se
gli eventi in arrivo non verificano nessun ELP statment, è possibile inoltrarli ad un ascoltatore
apposito.
Francesco NOCERA
- Gli eventi provenienti dall’esterno potrebbero necessitare di pre-processing affinché l’engine
possa riceverli in forma comprensibile. Situazione simile si verifica anche per gli output
dell’engine, che mediante adattatori sono consegnati ai destinatari.
- Gli adapter potrebbero non essere inseriti perché le API di Esper agevolano la ricezione di
eventi e la consegna dell’output del processing.
Francesco NOCERA
Esper fornisce due meccanismi principali per processare gli eventi:
- Event Patterns, che utilizza un linguaggio per definire patterns expression a cui sottoporre gli
eventi per verificarne il matching. Una pattern expression è formata da pattern operator e
pattern atoms ed ha la caratteristica di essere stateful, dunque l’engine tiene traccia del suo
stato. Questo meccanismo permette di individuare in maniera semplice relazioni temporali e
causali tra eventi. Per realizzare questo metodo di correlazione l’engine utilizza un approccio
FSM, dove le transizioni di stato avvengono in base agli eventi giunti e all’avanzare del tempo.
Un singolo evento o l’avanzare del tempo possono causare un’evoluzione multipla dello stato
in cui si trova il pattern (dunque un approccio FST).
- Event Stream Queries, utilizzando il linguaggio EPL è possibile scrivere query che includono
clausole SQL-Like e clausole a sostegno del CEP.
L’EPL differisce dall’SQL principalmente per il concetto di vista (views) piuttosto che quello di
tabelle, dove con vista si intende l’esito di operazioni che permettono di estrarre eventi da
uno o più stream con criterio prestabilito e strutturarli in maniera tale da essere utilizzabili
nello statement.
È inoltre possibile combinare i due meccanismi, cioè inserire pattern all’interno di EPL
statement.
Francesco NOCERA
Rappresentazione degli eventi
Un applicativo orientato all’utilizzo degli eventi ha la necessità di rappresentare l’informazione
da essi trasportata in una maniera strutturata.
In Esper un evento è un’entità immutabile le cui proprietà rispecchiano lo stato informativo
del fenomeno d’interesse verificatosi, esso può essere rappresentato attraverso differenti
oggetti:
- oggetti di classe java.lang.Object, cioè un java POJO (plain-old java object) che segue alcune
convenzioni JavaBean o un qualsiasi oggetto Legacy java class che non rispetta le convenzioni
JavaBean;
- oggetti di classe java.util.Map, dove un evento è una mappa ed ogni entry rappresenta una
proprietà;
- array di oggetti (Object []) dove ogni elemento è una proprietà dell’evento;
- un oggetto di classe org.w3c.dom.Node cioè un XML Document Object Model (DOM);
- un oggetto di qualsiasi classe esistente nell’applicativo di cui non si vogliono estrarre i dati
per trasformarli nei tipi su detti. Questo è reso possibile implementato l’interfaccia
PlugInEventRepresentation messa a disposizione dalle API di Esper, così da permette la
creazione di event type, basandosi sulle informazioni presenti in queste classi esistenti
nell’applicativo.
Francesco NOCERA
Struttura di uno statement EPL
[annotations]
[expression_declarations]
[context context_name]
[into table table_name]
[insert into insert_into_def]
select select_list
from stream_def [as name] [, stream_def [as name]] [,...]
[where search_conditions]
[group by grouping_expression_list]
[having grouping_search_conditions]
[output output_specification]
[order by order_by_expression_list]
[limit num_rows]
Francesco NOCERA
Applicazione
3 types of events are detected:
MONITOR - average temperature every 5 seconds ;
WARNING WARN -if we have 2 consecutive
temperatures above a certain threshold;
CRITICAL ALERT - if we have 4 consecutive events,
with the first one above a certain threshold, and
each subsequent one greater than the last – and the
last one being 1.5 times greater than the first.
Francesco NOCERA
package com.sisInfLab.cep;
import java.io.*;
import com.sisInfLab.cep.util.RandomTemperatureEventGenerator;
/**
*
* @author francesco nocera
*/
public class Start {
public static void main(String[] args) throws Exception {
System.out.println("-------------------------START--------------------------");
long noOfTemperatureEvents = 500;
RandomTemperatureEventGenerator generator= new
RandomTemperatureEventGenerator();
generator.startSendingTemperatureReadings(noOfTemperatureEvents);
//invio al generatore il numero max di eventi da generare per il test
}
}
Francesco NOCERA
package com.sisInfLab.cep.event;
import java.util.Date;
/**
*
*/
public class TemperatureEvent {
private int temperature;
private Date timeOfReading;
public TemperatureEvent(int temperature, Date timeOfReading) {
this.temperature = temperature;
this.timeOfReading = timeOfReading;
}
public int getTemperature() {
return temperature;
}
public Date getTimeOfReading() {
return timeOfReading;
} Francesco NOCERA
package com.sisInfLab.cep.handler;
import com.sisInfLab.cep.event.TemperatureEvent;
import com.sisInfLab.cep.subscriber.CriticalEventSubscriber;
import com.sisInfLab.cep.subscriber.MonitorEventSubscriber;
import com.sisInfLab.cep.subscriber.WarningEventSubscriber;
import com.espertech.esper.client.Configuration;
import com.espertech.esper.client.EPServiceProvider;
import com.espertech.esper.client.EPServiceProviderManager;
import com.espertech.esper.client.EPStatement;
/**
*
*/
Francesco NOCERA
public class TemperatureEventHandler {
private EPServiceProvider epService; //istanza dell'engine
private EPStatement criticalEventStatement;
private EPStatement warningEventStatement;
private EPStatement monitorEventStatement;
private CriticalEventSubscriber criticalEventSubscriber;
private WarningEventSubscriber warningEventSubscriber;
private MonitorEventSubscriber monitorEventSubscriber;
public void initService() {
Configuration config = new Configuration(); //ottengo istanza di configuarazione
default per l'engine (contiene parametri di default per settare l'engine)
config.addEventTypeAutoName("com.sisInfLab.cep.event");
configurazione il tipo di evento che l'engine dovrà gestire
//aggiungo
alla
epService = EPServiceProviderManager.getDefaultProvider(config); //la configurazione
creata viene utlizzata per configurare l'engine
createCriticalTemperatureCheckExpression(); //metodi per creare le istanze dei
subscriber e ottenere i rispettivi statement
createWarningTemperatureCheckExpression();
createTemperatureMonitorExpression();
}
Francesco NOCERA
private void createCriticalTemperatureCheckExpression() { // questo metodo è invocato da
initService()
criticalEventSubscriber = new CriticalEventSubscriber(); //istanzio il subscriber
criticalEventStatement
epService.getEPAdministrator().createEPL(criticalEventSubscriber.getStatement());
statement è ottenuto dal subscriber e creato nell'engine coì da essere avviato
=
//lo
criticalEventStatement.setSubscriber(criticalEventSubscriber);
subscriber allo statment avviato nell'engine
del
//associazione
}
private void createWarningTemperatureCheckExpression() { //idem
warningEventSubscriber =new WarningEventSubscriber();
warningEventStatement
epService.getEPAdministrator().createEPL(warningEventSubscriber.getStatement());
=
warningEventStatement.setSubscriber(warningEventSubscriber);
}
private void createTemperatureMonitorExpression() { //idem
monitorEventSubscriber = new MonitorEventSubscriber();
monitorEventStatement
epService.getEPAdministrator().createEPL(monitorEventSubscriber.getStatement());
monitorEventStatement.setSubscriber(monitorEventSubscriber);
}
Francesco NOCERA
=
public void handle(TemperatureEvent event) {
epService.getEPRuntime().sendEvent(event);
dell'engine
}
public TemperatureEventHandler() {
initService();
}
Francesco NOCERA
//invia
l'evento
ricevuto
all'istanza
package com.sisInfLab.cep.subscriber;
import java.io.*;
import java.util.Map;
import com.sisInfLab.cep.event.TemperatureEvent;
/**
*
*/
public class CriticalEventSubscriber {
private static final String CRITICAL_EVENT_THRESHOLD = "100";
private static final String CRITICAL_EVENT_MULTIPLIER = "1.5";
public CriticalEventSubscriber(){};
public String getStatement() {
String crtiticalEventExpression = "select * from TemperatureEvent "
+ "match_recognize ( "
+"
measures A as temp1, B as temp2, C as temp3, D as temp4 "
+"
pattern (A B C D) "
+"
define "
+"
A as A.temperature > " + CRITICAL_EVENT_THRESHOLD + ", "
+"
B as (A.temperature < B.temperature), "
+"
C as (B.temperature < C.temperature), "
+"
D as (C.temperature < D.temperature) and D.temperature >
(A.temperature * " + CRITICAL_EVENT_MULTIPLIER + ")" + ")";
return crtiticalEventExpression;
}
Francesco NOCERA
public void update(Map<String, TemperatureEvent> eventMap) {
TemperatureEvent
TemperatureEvent
TemperatureEvent
TemperatureEvent
temp1 = (TemperatureEvent) eventMap.get("temp1");
StringBuilder sb = new StringBuilder();
sb.append("***************************************");
sb.append("\n* [ALERT] : CRITICAL EVENT DETECTED! ");
sb.append("\n* " + temp1 + " > " + temp2 + " > " + temp3 + " > " + temp4);
sb.append("\n***************************************");
System.out.println(sb);
}
}
Francesco NOCERA
package com.sisInfLab.cep.subscriber;
import java.io.*;
import java.util.Map;
/**
*
*/
public class MonitorEventSubscriber {
public MonitorEventSubscriber(){};
return "select avg(temperature) as avg_val from
TemperatureEvent.win:time_batch(5 sec)";
}
public void update(Map<String, Double> eventMap) {
Double avg = (Double) eventMap.get("avg_val");
sb.append("---------------------------------");
sb.append("\n- [MONITOR] Average Temp = " + avg);
sb.append("\n---------------------------------");
}
}
Francesco NOCERA
public class WarningEventSubscriber {
private static final String WARNING_EVENT_THRESHOLD = "400";
public WarningEventSubscriber(){};
String warningEventExpression = "select * from TemperatureEvent "
+ "match_recognize ( "
+"
measures A as temp1, B as temp2 "
+"
pattern (A B) "
+"
define "
+"
A as A.temperature > " + WARNING_EVENT_THRESHOLD + ", "
+"
B as B.temperature > " + WARNING_EVENT_THRESHOLD + ")";
return warningEventExpression;
}
Francesco NOCERA
public void update(Map<String, TemperatureEvent> eventMap) {
TemperatureEvent temp1 = (TemperatureEvent) eventMap.get("temp1");
TemperatureEvent temp2 = (TemperatureEvent) eventMap.get("temp2");
sb.append("--------------------------------------------------");
sb.append("\n- [WARNING] : TEMPERATURE SPIKE DETECTED = " + temp1 + "," +
temp2);
sb.append("\n--------------------------------------------------");
}
}
Francesco NOCERA
in
Action!
Francesco NOCERA
Apache
Flink®
Francesco NOCERA
• Apache Flink è un framework open source per calcolo distributo
tramite stream o batch data, facente parte dei top-level project
dell’Apache Foundation
• Nato nel 2010 con il nome di Stratosphere e creato dalla Germany
Research Foundation in collaborazione con la Technical University di
Berlino, nel 2014 viene accolto sotto l’ala della Apache Foundation
cambiando il suo nome in Flink
• Il cuore di Flink è lo streaming dataflow engine che permette la
distribuzione dei dati, la comunicazione, e la gestione di errori su
calcolo distribuito su data stream
Francesco NOCERA
Le API di Flink che permettono di sfruttare il Flink engine sono:
• API per Datastream (Java e Scala), per stream di dati
• API per Dataset (Java, Scala e Python) per utilizzare dati statici
• Table API che permettono di sfruttare SQL-Like
Francesco NOCERA
Concetti base
•
Il costituente base dei programmi Flink sono gli stream e le trasformazioni.
- Uno stream è un risultato intermedio
- Una trasformazione è un'operazione che prende uno o più stream come input, e
dopo la trasformazione da in output uno o più stream.
•
Una volta eseguiti, i programmi vengono mappati in streaming dataflow, costituiti
da stream e operatori di trasformazione.
- Ogni streaming dataflow iniziano da uno o più source e finisce in uno o più sink.
Francesco NOCERA
Francesco NOCERA
Francesco NOCERA
Francesco NOCERA
Gli stream possono trasportare dati tra 2 operatori :
● One-to-One: ad esempio tra una sorgente e un operatore preservando il
partizionamento e l’ordinamento degli elementi;
● Redistributing: quando vengono inviati dati a attività secondarie a seconda della
trasformazione.
I processi di Flink che vengono eseguiti a runtime sono di 2 tipi:
● master: chiamati anche JobManagers che coordinano l’esecuzione distribuita
dei task, schedulando la loro esecuzione;
● worker: chiamati anche TaskManagers che eseguono un task su uno stream di
dati. Risulta ovvio che ci sia sempre almeno un processo worker.
Francesco NOCERA
-
Ogni worker è un processo della
JavaVirtualMachine e può eseguire uno
o più task in thread separati.
-
Il numero di task che un worker può
accettare è dato dai task slots.
- Ogni task slot rappresenta un
sottoinsieme fissato delle risorse, quindi ad
esempio un TaskManager (worker) ha 3
task slot, vuole dire che un terzo delle
proprie risorse sarà assegnato ad ogni slot,
questo vuol dire che i task in esecuzione
non andranno in conflitto tra loro per la
memoria, ma avranno un certo ammontare
dedicato di memoria.
Francesco NOCERA
Scegliere il numero di task slot può essere importante per isolare i subtask, ad esempio se
decidiamo di assegnare uno slot ci ritroviamo che i task risultano isolati tra loro ed eseguiti da JVM
diverse tra loro, di contro invece avere più slot, più task possono essere eseguiti sulla stessa JVM
e quindi condividere dati riducendo l'overhead e ottimizzando l’esecuzione.
Francesco NOCERA
Definizione Finestre: questo poiché i normali eventi di aggregazione funziona differentemente
su stream piuttosto che processi batch. Dato che è impossibile contare gli elementi di uno stream,
perchè uno stream di sua natura è un flusso infinito di dati, per fare operazioni di aggregazione su
stream, come ad esempio una semplice operazione di conta su uno stream deve essere eseguita
per finestre di tipo temporale (ad esempio: conta ogni 10 minuti) o di tipo data (ad esempio:
esegui la media ogni 200 elementi).
Francesco NOCERA
Francesco NOCERA
FlinkCEP
- Libreria che permette di determinare pattern in stream di dati in ingresso.
- nasce dall’esigenza di far corrispondere eventi in arrivo, in modo continuativo, a
pattern prefissati (Solitamente si tratta di eventi complessi). Si può comprendere
meglio il funzionamento paragonandolo ai DBMS, in cui viene eseguita una query su
dati memorizzati, nel caso del CEP si eseguono dati su query memorizzate. Tutti i
dati inutili all’elaborazione vengono immediatamente scartati.
- La necessità fondamentale, è che i dati in ingresso siano elaborati immediatamente,
e una volta che viene verificato un pattern il risultato deve essere subito emesso
- Si presta bene a questi ambiti data la sua natura basata su stream di dati e l’alta
capacità di eleborazione unita alla bassa latenza anche con carichi elevati.
Francesco NOCERA
FlinkCEP: Esempio
Francesco NOCERA
Classe CEPMonitoring:
public class CEPMonitoring {
private static final double SOGLIA= 1000;
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env = StreamExecutionEnvironment
.getExecutionEnvironment();
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
// Stream in input degli eventi da monitorare
DataStream<MonitoringEvent> inputEventStream = env
.addSource(new MonitoringEventSource(Sensore_ID, TEMP))
.assignTimestampsAndWatermarks(new IngestionTimeExtractor<>());
………….
Francesco NOCERA
……
//impostiamo un Warning Pattern quando superiamo la soglia di temperatura
//nell’arco di 60 secondi
Pattern<MonitoringEvent, ?> warningPattern = Pattern.<MonitoringEvent>begin("first")
.subtype(TemperatureEvent.class)
.where(evt -> evt.getTemperature() >= SOGLIA)
.next("second")
.subtype(TemperatureEvent.class)
.where(evt -> evt.getTemperature() >= SOGLIA)
.within(Time.seconds(60));
//Creiamo un PatternStream suddividendo gli input per ID del sensore
PatternStream<MonitoringEvent> tempPatternStream = CEP.pattern(
inputEventStream.keyBy("Sensore_ID"),
warningPattern);
…………
Francesco NOCERA
……..
// infine creiamo un DataStream che restituisce un warning con id sensore
// e le due temperature rilevate
DataStream<TemperatureWarning> warnings = tempPatternStream.select(
(Map<String, MonitoringEvent> pattern) -> {
TemperatureEvent first = (TemperatureEvent) pattern.get("first");
TemperatureEvent second = (TemperatureEvent) pattern.get("second");
return new TemperatureWarning(first.Sensore_ID(), (first.getTemperature() + “-”
+ second.getTemperature()));
}
);
warnings.writeAsText(outputPath);
env.execute("CEP monitoring job");
}
}
Francesco NOCERA
Apache
FlinkCEP
in
Action!
Francesco NOCERA
Bibliografia
[1] Gianpaolo Cugola and Alessandro Margara. 2012. Processing flows of information: From
data stream to complex event processing. ACM Comput. Surv. 44, 3, Article 15 (June 2012),
62 pages. DOI=http://dx.doi.org/10.1145/2187671.2187677.
[2] Martin Atzmueller, Samia Oussena, and Thomas Roth-Berghofer. 2016. Enterprise Big
Data Engineering, Analytics, and Management (1st ed.). IGI Global, Hershey, PA, USA.
[3] http://www.espertech.com/esper/.
[4] https://flink.apache.org/
Francesco NOCERA

Complex Event Processing(CEP)

Transcript

Documenti analoghi

Istituto Superiore di Studi Musicali “Pyotr Ilyich Tchaikovsky” di

Sessanta immagini, due secoli di storia industriale al Museo della

Locandina corsi serali gratuiti per adulti

lettera tiroide - Associazione Medici Endocrinologi

formazione genitori SCUOLA VIVA

CV Sarah Nocera

Q"/r-î"u,

Profilo di Paolo Pandozy

Art. vendita beneficenza - Suore Serve di Maria Addolorata