“Micro big data”, torna in auge l’approccio Data Stream: elaborazione di flussi di dati

La produzione e la disponibilità di grandissime masse di dati di varia natura – i cosiddetti Big Data – vengono solitamente associate alle grandi banche di dati presenti nei Sistemi Informativi, alle pagine web, alle immagini, ai suoni e ad altre forme di informazione relativamente statiche. Tuttavia, l’avvento di nuove sorgenti di informazione sta cambiando, o meglio, aggiungendo nuove prospettive al già variegato panorama. In questi sistemi, grandi quantità di dati fluiscono continuamente e autonomamente dalle sorgenti e devono essere elaborati “al volo” (on the fly). Ci riferiamo in particolare alla Internet of Things (IoT), alle reti di sensori, agli RFID, alle reti sociali e quindi a quelli che potremmo chiamare “micro Big Data”. In realtà, l’uso massiccio di flussi di dati (Data Stream) risale ai primi anni settanta con i sistemi di elaborazione delle informazioni trasmesse dai satelliti artificiali e al loro sfruttamento commerciale, come la commutazione nei sistemi di telecomunicazione, il controllo del territorio, la sorveglianza meteorologica, ecc .; oggi tuttavia, con l’avvento dei sistemi pervasivi, l’uso dei Data Stream è passato da domini applicativi specializzati a una platea vastissima di utenti non specialistici.

In questo articolo esamineremo l’approccio alla elaborazione di flussi di dati usato da chi si occupa di gestione dei dati; occorre, però, anche segnalare che la prospettiva di chi si occupa di ingegneria del software nei sistemi distribuiti ricorre prevalentemente ad un altro paradigma, quello dei Complex Event Processing Systems (CEP) [1].

Il principale obiettivo funzionale dei sistemi di gestione di Data Stream (DSMS) [2], nei quali a ciascun elemento di dati (p. e.: record, tuple relazionali, triple RDF, …) viene associata una marca di tempo (time stamp), generalmente relativa all’istante della sua generazione, consiste nel produrre i risultati delle elaborazioni in tempo reale, mentre i dati in ingresso continuano ad arrivare. Infatti, a causa della natura illimitata e massiccia dei flussi di dati, questi non possono essere memorizzati per usi futuri; solo alcune sinossi possono essere conservate in una memoria permanente. Ciò influisce anche sulla possibilità di eseguire le usuali operazioni sui dati e sulla modalità della loro implementazione e costituisce un’ulteriore perdita di potere espressivo rispetto alle limitazioni presenti nei linguaggi relazionali quali, ad esempio, SQL.

In particolare:

1. nelle interrogazioni è possibile utilizzare solamente operatori di tipo monotono – quali select, project, join, union e pochi altri – che possono essere valutati incrementalmente, mentre non si possono usare quegli operatori di aggregazione, largamente presenti nei sistemi di Basi di Dati (DBMS), che richiedono la disponibilità di un blocco completo di elementi di dati prima di poter produrre il primo elemento del risultato (blocking operator);
2. le librerie di funzioni disponibili nei DBMS sono molto meno efficienti se utilizzate su piccole quantità di dati incrementali, tipiche dei Data Stream;
3. inserire le interrogazioni sui dati nei linguaggi di programmazione procedurali (p. e. : embedded SQL), pratica molto usata nei DBMS, risulta scarsamente efficace.

I sistemi e le applicazioni che gestiscono Data Stream devono consentire di operare su di essi per calcolare funzioni di aggregazione sui dati, per unire flussi diversi in un unico flusso o, viceversa, per decomporre un flusso in più flussi distinti, per ricercare dati frequenti e possibilmente eseguire funzioni di Data Mining su di essi.

Il modo più usato per superare il problema della illimitatezza del flusso dei dati è di “affettarlo” in una serie di “finestre” di lunghezza finita. L’ampiezza della finestra può essere definita come numero di elementi di dati, in tal caso si parla di “ snapshot” (Fig. 1-a), oppure come intervallo di tempo prefissato, indipendentemente dal numero di elementi di dati in esso contenuti. Nel secondo caso, le finestre scorrono nel tempo e possono essere disgiunte o parzialmente sovrapposte (sliding, overlapping windows) (Fig. 1-b).

Fig. 1 – Finestre su Data Stream

Le finestre di tipo snapshot possono essere usate nella modalità di elaborazione backward, nella quale vengono elaborati i dati già arrivati entro un intervallo, dettato dall’ampiezza della finestra; quelle a scorrimento vengono invece utilizzate nella modalità di elaborazione forward, nella quale i dati vengono elaborati man mano che arrivano con la limitazione, in questo caso, alle sole operazioni monotone.

Bisogna inoltre osservare che I flussi di dati sono spesso affetti da irregolarità e/o errori quali, ad esempio, ritardi, omissione di un dato, arrivo dei dati in un ordine temporale differente da quello di origine. I DSMS pertanto, oltre alle consuete funzioni legate all’affidabilità e alla sicurezza delle informazioni, devono poter gestire queste anomalie per poter fornire risposte consistenti alle interrogazioni; essendo inoltre sistemi che lavorano in tempo reale, devono poter gestire situazioni di sovraccarico eventualmente fornendo risultati approssimati entro limiti accettabili [3].

Avendo descritto le principali caratteristiche dei sistemi di Data Stream, in un prossimo articolo verranno introdotti alcuni linguaggi e sistemi proposti dalla ricerca per il loro trattamento, facendo in particolare riferimento alle reti di sensori e ai sistemi pervasivi.