New horizons for stream processing

Stream processing has gained tremendous attention over the last years and many Stream Processors (SPs) have been designed and engineered to cope with huge volumes of data coming at high velocity. Streams could contain stock options, user clicks in web applications, customer purchases in an e-commerce application, positions of robots in a warehouse, or temperature measurements from sensors. The common requirement for streaming applications is to process unbounded streams of elements and continuously compute queries like "what is the top purchased product?", or "what was the average temperature in the server room in the last second?" in order to take rapid compensating actions such as ordering a new stock of the top purchased product, or prevent fire in the server room. In order to continuously process huge amounts of elements and take real-time decisions, SPs exploit the computational power offered by multiple machines by distributing the computation and dividing data in shared-nothing partitions to avoid expensive data race management while processing. Stream processing is also a programming paradigm suited for designing novel event-driven applications with high throughput and low-latency requirements. Streams offer decoupling among the processing modules and, thus, enhance application modularity and composability. Indeed, SPs are playing a central role in the technology stacks of modern companies and they are covering more and more tasks that, in standard deployments, compete to other tools. The employment of one system instead of multiple ones reduces system integration complexity, communication latency, and facilitates application maintenance and modeling. Novel event-driven applications require a Database Management System (DBMS) for state management that is, indeed, embedded in the state of computation of the SP. However, due to its embedding, the DBMS suffers from some limitations such as the lack of multi-key transactions and consistent external querying. Eventually, their central role requires SPs to conform to a standardized execution semantics in order to improve their usability, interoperability, and interchangeability. This thesis takes a step towards SPs standardization through highlighting the discrepancies between them, and a step towards their integration with DBMSs by extending their computational model to deal with transactional computation. For SPs standardization, we use SECRET, a well recognized mathematical model to express their execution semantics, to model five distributed SPs that were developed after the introduction of SECRET itself and are today widely used in companies at the scale of Google, Twitter, and Netflix. We show that SECRET properly models a subset of the behavior of these systems and we shed light on the recent evolution of SPs by analyzing the elements that SECRET cannot fully capture. In order to decrease system integration overhead and to overcome the limitations of the current approaches for DBMS over SP, we enhance the capabilities of the SP with DBMS's ones by extending the SP computational model with transactional semantics: we develop a unified approach for multi-key transactions on the internal state of the SP, consistent external querying with respect to transactional operations on the state, and streaming data analysis. We implement TSpoon, a prototypal implementation of our extended model, as an extension to the open-source SP Apache Flink. We evaluate our prototype using synthetic workloads in various configurations to understand which metrics mostly impact its performance. Eventually, we evaluate a real use-case scenario and compare the results with the ones obtained from VoltDB, a commercial in-memory database known for its excellent level of performance: TSpoon outperforms VoltDB in the execution of multi-key transactions and proves to be a promising future direction for the integration of DBMSs and SPs.

Lo stream processing, ovvero, l'elaborazione di flussi di dati, ha richiamato grande attenzione negli ultimi anni. L'interesse crescente alla gestione di grandi volumi di dati prodotti ad altissime velocità ha dato vita alla progettazione ed allo sviluppo di molti Stream Processor (SP) ---gli strumenti volti a processare tali flussi. I dati contenuti nei flussi possono essere di molteplice natura: fluttuazioni degli indici di borsa; click in applicazioni web; acquisti in un'applicazione e-commerce; posizioni dei robot nei magazzini; misurazioni di temperature da sensori o altro. I requisiti comuni per le applicazioni in questo dominio sono l'elaborazione continua di infiniti flussi di dati espressa per mezzo di query (i.e., interrogazioni sui dati) in modo da intraprendere azioni di compensazione in base ai risultati ottenuti. Per esempio, la query "qual è il prodotto più acquistato?" al fine di ordinarne una nuova provvista, oppure "qual era la temperatura media nella stanza server nell'ultimo secondo?" per prevenire un possibile incendio. Per processare grandi moli di dati senza soluzione di continuità e prendere decisioni in tempo reale, gli SP sfruttano la potenza computazionale offerta da più macchine distribuendo su di esse il calcolo e separando i dati in partizioni indipendenti, in modo da evitare costose operazioni di coordinazione. Lo stream processing è anche un paradigma di programmazione adatto alla progettazione di nuove applicazioni orientate agli eventi che richiedono alto throughput e bassa latenza. I flussi di dati, infatti, garantiscono disaccoppiamento tra i moduli applicativi e migliorano la componibilità e la modularità delle applicazioni stesse. Dato ciò, gli SP ricoprono un ruolo sempre più centrale nel portafoglio delle tecnologie utilizzate nelle aziende moderne e vengono utilizzati per svolgere compiti per cui, in passato, venivano impiegati altri strumenti. L'utilizzo di un solo sistema, infatti, evita la complessità di integrazione di diversi, riduce le latenze di comunicazione tra sistemi e facilita la manutenibilità e il design delle applicazioni stesse. Le nuove applicazioni orientate agli eventi, infatti, richiedono un Database Management System (DBMS) (i.e., un sistema per la gestione dei dati) per gestire lo stato della computazione, il quale viene incluso direttamente all'interno dello SP. Tuttavia, il DBMS così progettato soffre di limitazioni, come l'assenza di transazioni su più chiavi e l'impossibilità di garantire la consistenza delle interrogazioni esterne allo stato della computazione. Infine, dato il loro ruolo centrale, gli SP devono conformarsi ad una semantica di esecuzione standardizzata per migliorarne l'usabilità, l'interoperabilità e per poter essere intercambiabili. Questa tesi si muove verso la standardizzazione degli SP delineandone le discrepanze, e verso la loro integrazione con i DBMS estendendone il modello computazionale. Per quanto riguarda la standardizzazione degli SP, viene utilizzato SECRET, un modello matematico per la semantica di esecuzione degli SP riconosciuto dal mondo accademico, per modellare cinque diversi SP distribuiti sviluppati dopo l'introduzione di SECRET stesso e che sono oggi ampiamente utilizzati in aziende come Google, Twitter e Netflix. Nella tesi, si mostra che SECRET modella propriamente un sottoinsieme dei comportamenti di questi sistemi e si pone evidenza su alcuni aspetti della recente evoluzione degli SP per mezzo dell'analisi di quegli elementi che SECRET stesso non riesce a catturare. Per l'attenuazione delle problematiche e delle limitazioni degli attuali approcci di integrazione tra DBMS ed SP, viene adottato un approccio che porta le capacità di gestione dei dati degli SP ad essere più vicine a quelle dei DBMS tradizionali. In primo luogo, viene infatti esteso il modello computazionale degli SP con semantiche transazionali, dando vita ad un approccio unificato per: transazioni su chiavi multiple sullo stato interno allo SP; query esterne consistenti rispetto ad esse; ed analisi dei flussi di dati. In secondo luogo, viene implementato il sistema TSpoon: l'implementazione prototipale del nostro modello come estensione dello SP open-source Apache Flink. Per capire quali siano le metriche che più impattano le performance del prototipo, viene dettagliata la sua valutazione per mezzo di workload sintetici con varie configurazioni. Infine, viene fornito un caso d'uso reale, i cui risultati vengono paragonati a quelli di VoltDB, un database commerciale in-memory noto per le sue elevate performance: TSpoon ottiene risultati migliori di VoltDB nell'esecuzione di transazioni su chiavi multiple, provando di costituire una promettente direzione futura per l'integrazione tra DBMS ed SP.