Nel primo post di questa serie, ho presentato The Case for Hybrid Batch and Streaming Architecture for Data Integration e mi sono concentrato sulla comprensione del calcolo batch. In questo post mi concentrerò sulla comprensione del calcolo in streaming. Nel post conclusivo, invece, analizzerò i vantaggi dell'unificazione di batch e streaming per l'integrazione dei dati.
Comprendere il calcolo in streaming
I motori di elaborazione dei dati in streaming hanno diverse funzionalità e strategie di implementazione. In un certo senso, un motore di streaming può elaborare i dati man mano che arrivano, a differenza di un sistema batch che deve disporre di tutti i dati prima di avviare un calcolo. L'obiettivo del calcolo in streaming può essere quello di filtrare i dati non necessari o di trasformare i dati in arrivo prima di inviare i dati risultanti alla destinazione finale. Se ogni pezzo di dati in streaming può essere trattato in modo indipendente, i requisiti di memoria dei nodi di elaborazione dello streaming possono essere limitati, purché la computazione in streaming riesca a tenere il passo con i dati in arrivo. Inoltre, spesso non è necessario o auspicabile persistere i dati di streaming in arrivo su disco.
Un'altra visione più sofisticata dell'elaborazione dei flussi prevede l'esecuzione di calcoli su insiemi di dati in arrivo, come l'aggregazione per trovare una somma o una media. Questo è utile in molti contesti in cui si desidera rispondere ai dati in arrivo in tempo reale per identificare il comportamento o rilevare i problemi. Un insieme di dati può essere definito da un numero fisso di elementi di dati, ad esempio ogni 10 messaggi. In alternativa, un set di dati può essere definito come gli elementi di dati che arrivano in un determinato periodo di tempo, ad esempio ogni 30 secondi. Infine, un insieme di dati in streaming può anche essere definito da una finestra scorrevole in cui viene eseguito un calcolo in streaming, ad esempio sugli ultimi 30 secondi di dati ogni 10 secondi. In questo modo si creano insiemi di dati sovrapposti.
Proprio come nell'elaborazione dei dati orientata al batch, il calcolo in streaming richiede un mezzo per gestire i guasti durante l'esecuzione. Gli attuali motori di elaborazione in streaming, come Apache Storm, Apache Flink e Spark Streaming, hanno tutti approcci diversi per ottenere la tolleranza ai guasti. Uno di questi approcci consiste nel salvare periodicamente i checkpoint dei nodi di flusso su uno storage persistente e ripristinare il tutto dal checkpoint in caso di guasto. Apache Flink utilizza una forma di checkpoint per tollerare i guasti. Un altro approccio consiste nel recuperare i guasti riproducendo il flusso di dati in arrivo da uno storage affidabile, come Apache Kafka. Apache Storm utilizza un approccio di replay. Un altro approccio adottato da Spark Streaming consiste nel leggere i dati in arrivo in microbatch replicati nella memoria del cluster di elaborazione dei flussi. In questo modo, i dati in arrivo possono essere recuperati da una replica.
I diversi motori di elaborazione dei flussi hanno anche una semantica di elaborazione diversa, influenzata dal loro approccio alla tolleranza ai guasti. Sia Storm che Flink possono elaborare i dati non appena arrivano, mentre Spark deve combinare i dati in arrivo in microbatch prima di elaborarli. Tuttavia, l'approccio dei microbatch può portare a un throughput complessivo più elevato, al costo della latenza. Un'altra differenza semantica riguarda l'elaborazione dei messaggi almeno una volta rispetto a quella esattamente una volta. Spark Streaming e Flink hanno una semantica "exactly once", più semplice da interpretare per un programmatore. Storm supporta la semantica almeno una volta per impostazione predefinita, ma la semantica esattamente una volta può essere ottenuta utilizzando il livello API Trident per Storm.
Sebbene questi motori di streaming si sovrappongano in una certa misura per quanto riguarda le funzionalità, alcuni motori saranno più adatti a diversi tipi di problemi. A questo punto, non esiste un framework universale che risolva tutti i problemi di streaming. Sempre più spesso, le attività di integrazione dei dati dovranno essere eseguite sia in un contesto di streaming che in un contesto batch.
Nell'ultimo post di questa serie, illustrerò i vantaggi dell'unificazione di batch e streaming per l'integrazione dei dati aziendali.
