Complex Event Processing(CEP)
Transcript
Complex Event Processing(CEP)
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! Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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. Advanced Software Engineering 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] Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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 Advanced Software Engineering Francesco NOCERA Complex Event Processing (CEP) System 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. Advanced Software Engineering Francesco NOCERA Complex Event Processing (CEP) System Modello funzionale di un sistema IFP: Il flusso di output è influenzato da: set rules knowledge base history Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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. Advanced Software Engineering 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 Advanced Software Engineering 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. Advanced Software Engineering 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) Advanced Software Engineering Francesco NOCERA CEP Systems Progress Apama OracleCEP StreamBase CEP Esper Apace Flink Advanced Software Engineering 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 Advanced Software Engineering Francesco NOCERA APPLICAZIONI DEL COMPLEX EVENT PROCESSING IN AMBITO SANITARIO A SYSTEMATIC MAPPING STUDY Advanced Software Engineering Francesco NOCERA Electronic databases (paper pubblicati dal 2010 ad oggi) - ACM - IEEE - Springer - ScienceDirect - Google scholar Paper selezionati: 25 Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering Francesco NOCERA RBL,SQ RBL,SQ,CO RBL RBL RBL,SQ,CO Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering Francesco NOCERA Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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] Advanced Software Engineering 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. Advanced Software Engineering 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 } } Advanced Software Engineering Francesco NOCERA package com.sisInfLab.cep.event; import java.util.Date; /** * * @author francesco nocera */ 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; Advanced Software Engineering } 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; /** * * @author francesco nocera */ Advanced Software Engineering 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(); } Advanced Software Engineering 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); } Advanced Software Engineering Francesco NOCERA = public void handle(TemperatureEvent event) { epService.getEPRuntime().sendEvent(event); dell'engine } public TemperatureEventHandler() { initService(); } Advanced Software Engineering 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; /** * * @author francesco nocera */ 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; } Advanced Software Engineering Francesco NOCERA public void update(Map<String, TemperatureEvent> eventMap) { TemperatureEvent TemperatureEvent TemperatureEvent TemperatureEvent temp1 = (TemperatureEvent) eventMap.get("temp1"); temp2 = (TemperatureEvent) eventMap.get("temp2"); temp3 = (TemperatureEvent) eventMap.get("temp3"); temp4 = (TemperatureEvent) eventMap.get("temp4"); 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); } } Advanced Software Engineering Francesco NOCERA package com.sisInfLab.cep.subscriber; import java.io.*; import java.util.Map; /** * * @author francesco nocera */ public class MonitorEventSubscriber { public MonitorEventSubscriber(){}; public String getStatement() { 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"); StringBuilder sb = new StringBuilder(); sb.append("---------------------------------"); sb.append("\n- [MONITOR] Average Temp = " + avg); sb.append("\n---------------------------------"); System.out.println(sb); } Advanced Software Engineering } Francesco NOCERA public class WarningEventSubscriber { private static final String WARNING_EVENT_THRESHOLD = "400"; public WarningEventSubscriber(){}; public String getStatement() { 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; } Advanced Software Engineering Francesco NOCERA public void update(Map<String, TemperatureEvent> eventMap) { TemperatureEvent temp1 = (TemperatureEvent) eventMap.get("temp1"); TemperatureEvent temp2 = (TemperatureEvent) eventMap.get("temp2"); StringBuilder sb = new StringBuilder(); sb.append("--------------------------------------------------"); sb.append("\n- [WARNING] : TEMPERATURE SPIKE DETECTED = " + temp1 + "," + temp2); sb.append("\n--------------------------------------------------"); System.out.println(sb); } } Advanced Software Engineering Francesco NOCERA in Action! Advanced Software Engineering Francesco NOCERA Apache Flink® Advanced Software Engineering 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 Advanced Software Engineering 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 Advanced Software Engineering 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. Advanced Software Engineering Francesco NOCERA Advanced Software Engineering Francesco NOCERA Advanced Software Engineering Francesco NOCERA Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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. Advanced Software Engineering 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). Advanced Software Engineering Francesco NOCERA Advanced Software Engineering 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. Advanced Software Engineering Francesco NOCERA FlinkCEP: Esempio Advanced Software Engineering 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<>()); …………. Advanced Software Engineering Francesco NOCERA Classe CEPMonitoring: …… //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); ………… Advanced Software Engineering Francesco NOCERA Classe CEPMonitoring: …….. // 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"); } } Advanced Software Engineering Francesco NOCERA Apache FlinkCEP in Action! Advanced Software Engineering 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/ Advanced Software Engineering Francesco NOCERA