Aurora

Aurora `e un sistema di gestione di dati a flusso nato da un progetto di col-laborazione fra la Brandeis University, la Brown University ed il Massachussets Institute of Technology [1].

Il suo compito `e gestire lo stream di dati in arrivo da una variet`a di sorgenti ad intervalli regolari o irregolari. Ciascuna sorgente ha un suo identificativo univoco

e Aurora gestisce il timestamp di ciascuna tupla entrante. L’architettura imple-mentata dal sistema Aurora `e basata sul paradigma a ’scatole’ e ’frecce’ tipico dei modelli workflow e una sua rappresentazione `e mostrata in figura 2.6. La

Figura 2.6: Architettura del sistema AURORA.

figura mostra come il sistema si frapponga fra un set di sorgenti di dati a flusso e un insieme di applicazioni. Esso mette a disposizione delle query un insieme di operatori (operator boxes) che sono capaci di operare su dati a flusso e che pos-sono essere concatenati per ottenere il risultato atteso dalle applicazioni in fondo alla catena come mostrato in figura 2.8. Ogni insieme di operatori in cascata rappresenta una query ad hoc o di tipo continuo (continuous query); inoltre le query possono essere progettate per salvare una versione compressa oppure una certa porzione dei dati a flusso che stanno analizzando all’interno del repository dei dati storici (Historical Storage) e tali dati rimarranno a disposizione delle ap-plicazioni grazie alle query ad-hoc. Il grafo individuato dagli operatori in Aurora `e aciclico (vedi figura 2.7.a) ed inoltre ogni grafo di esecuzione implementa delle code che fungono da buffer per le tuple in arrivo dalle sorgenti o dagli operatori a monte (vedi figura 2.7.b).

`

E importante sottolineare come il sistema assuma che i dati provengono da una serie di sorgenti i cui dati, a differenza dei sistemi transazionali tradizionali, non hanno origine da transazioni generate da attivit`a umane. In questa visione il sistema deve essere di supporto all’operatore affinch`e, tramite un certo numero di query sui dati a flusso, sia possibile attivare allarmi o notificare il verificarsi di particolari eventi e condizioni analizzando continuamente i dati che stanno af-fluendo dalle sorgenti. Il sistema Aurora non fa differenza tra generatori di dati

Figura 2.7: GUI del sistema Aurora con un grafo di esecuzione: (a) a sinistra si notano gli stream sorgenti, al centro il grafo composto dai vari operatori ed a destra gli stream di uscita disponibili per le applicazioni client; (b) la fase di monitoraggio delle code implementate da un particolare grafo di esecuzione. software o hardware (sensori), entrambi sono definiti data source. La collezione dei dati generati da un particolare data source viene indicata col termine stream. Il sistema Aurora fornisce agli utenti un insieme di operatori primitivi predefini-ti, appositamente progettati per operare sugli stream di dati continui. I tipi di query supportate dal sistema sono:

• Query continue: Possono operare su un insieme di stream di input e su una certa finestra temporale oppure, in alternativa, su di un certo insieme di tuple per volta.

• Query Ad-Hoc: Sono query supportate per permettere alle applicazioni di fare interrogazione sui dati storici memorizzati nell’apposito repository del sistema.

• Viste: Permettono di riorganizzare e di filtrare i dati in appositi schemi richiesti dalle applicazioni.

Una caratteristica particolarmente rilevante del sistema Aurora `e che, ad ogni query, viene associato un grafo di Qualit`a del Servizio (QoS, Quality of Service). Aurora tenta sempre di massimizzare il valore di QoS percepito per gli output che produce (i risultati delle query), che sono a loro volta degli stream. Il QoS `e una funzione multidimensionale di una serie di attributi del sistema Aurora:

Figura 2.8: Aurora query model.

• Tempi di risposta: Le tuple in uscita vengono fornite tenendo conto dei tempi di risposta prestabiliti, altrimenti il QoS degrada proporzionalmente all’aumentare dei tempi di attesa.

• Eliminazione delle tuple: Se alcune tuple vengono eliminate per abbassare il carico del sistema, il QoS percepito in output degrader`a.

• Valori prodotti : il QoS dipende da quanto i valori prodotti in output sono rilevanti e riconducibili al flusso di partenza.

Chiedere all’amministratore di ogni applicazione di fornire una descrizione della funzione multidimensionale QoS desiderata e’ ovviamente improponibile. L’ap-proccio scelto dai progettisti di Aurora `e molto piu ragionevole. Un ammin-istratore deve specificare, per ogni stream al quale e interessato solo il grafico che lega il QoS al ritardo dei dati ricevuti (vedi figura 2.9). Dal grafico si puo notare come il QoS sia massimizzato se il ritardo in uscita e minore del valore delta δ specificato dall’amministratore. Gli altri due grafici mostrati in figura sono opzionali e permettono rispettivamente di: (i) specificare la percentuale di tuple consegnate in uscita (rispetto a quelle arrivate in ingresso) e (ii) indicare al sistema l’importanza di alcuni valori rispetto ad altri. Di particolare rilevanza sono gli operatori a finestra (windowed operators), che permettono di operare su pi`u tuple di dati contemporaneamente, essendo fissata la finestra temporale di

Figura 2.9: Grafici relativi al QoS.

interesse. Ogni operatore a finestra pu`o applicare una funzione di input defini-ta dall’utente, per poi avanzare alla finestra temporale successiva e catturare le nuove tuple da rendere disponibili al prossimo ciclo di esecuzione. Questa funzionalit`a di spostamento fra le finestre `e offerta in modo differente a seconda dell’operatore scelto:

• Slide: Permette di spostare la finestra di n tuple in avanti.

• Tumble: Garantisce che due finestre consecutive non abbiano mai tuple in comune.

• Latch: Assomiglia all’operatore Tumble ma `e capace di mantenere uno stato fra una operazione e l’altra. E’ utile quando si deve calcolare, ad esempio, un valore massimo fra tutte le finestre.

• Resample: Produce uno stream parzialmente sintetico interpolando le tuple di uno stream di input e fornendo un nuovo stream in uscita.

Oltre agli operatori a finestra in Aurora sono disponibili altri operatori che permettono di manipolare una tupla per volta:

• Filter : Controlla le tuple in uno stream e seleziona solo quelle che verificano una particolare condizione (come la clausola ’WHERE’ dell’SQL).

• Drop: E’ un caso speciale di Filter che elimina delle tuple in modo random con una frequenza specificata da un operatore di input.

• GroupBy: Partiziona le tuple di vari stream in un nuovo stream di uscita contenente gli stessi valori rispetto ad un set di attributi di input.

• Join: Accoppia le tuple provenienti da pi`u stream di input la cui distanza (definibile dall’utente) ricade in un certo intervallo.