Secondo un recente rapporto di IBM Marketing cloud, “il 90% dei dati nel mondo di oggi è stato creato solo negli ultimi due anni, creando 2. 5 quintilioni di byte di dati ogni giorno – e con l’emergere di nuovi dispositivi, sensori e tecnologie, è probabile che la crescita dei dati acceleri ulteriormente”.5 quintilioni di byte di dati ogni giorno – e con l’emergere di nuovi dispositivi, sensori e tecnologie, il tasso di crescita dei dati probabilmente accelererà ancora di più”.
Tecnicamente questo significa che il nostro mondo del Big Data Processing sarà più complesso e più impegnativo. E molti casi d’uso (ad esempio gli annunci delle app mobili, il rilevamento delle frodi, la prenotazione di taxi, il monitoraggio dei pazienti, ecc) hanno bisogno di un’elaborazione dei dati in tempo reale, come e quando i dati arrivano, per prendere decisioni rapide. Questo è il motivo per cui il Distributed Stream Processing è diventato molto popolare nel mondo dei Big Data.

Oggi ci sono un certo numero di framework di streaming open source disponibili. È interessante notare che quasi tutti sono abbastanza nuovi e sono stati sviluppati solo negli ultimi anni. Quindi è abbastanza facile per una persona nuova confondersi nella comprensione e nella differenziazione tra i framework di streaming. In questo post parlerò prima dei tipi e degli aspetti dello Stream Processing in generale e poi confronterò i più popolari framework di Streaming open source: Flink, Spark Streaming, Storm, Kafka Streams. Cercherò di spiegare come funzionano (brevemente), i loro casi d’uso, i punti di forza, le limitazioni, le somiglianze e le differenze.

Che cos’è lo Streaming/Stream Processing :
La definizione più elegante che ho trovato è: un tipo di motore di elaborazione dei dati che è progettato con set di dati infiniti in mente. Niente di più.

A differenza dell’elaborazione Batch dove i dati sono delimitati con un inizio e una fine in un lavoro e il lavoro finisce dopo l’elaborazione di quei dati finiti, lo Streaming è pensato per l’elaborazione di dati illimitati che arrivano in tempo reale continuamente per giorni, mesi, anni e per sempre. Come tale, essendo sempre pensato per essere attivo e funzionante, un’applicazione di streaming è difficile da implementare e più difficile da mantenere.

Aspetti importanti dell’elaborazione degli stream:

Ci sono alcune importanti caratteristiche e termini associati all’elaborazione degli stream che dovremmo conoscere per capire i punti di forza e i limiti di qualsiasi framework di streaming :

• Garanzie di consegna :
  Significa qual è la garanzia che non importa cosa, un particolare record in entrata in un motore di streaming sarà elaborato. Può essere Atleast-once (sarà processato almeno una volta anche in caso di errori), Atmost-once (potrebbe non essere processato in caso di errori) o Exactly-once (sarà processato una ed esattamente una volta anche in caso di errori). Ovviamente Exactly-once è desiderabile, ma è difficile da raggiungere nei sistemi distribuiti e viene a compromessi con le prestazioni.
• Fault Tolerance :
  In caso di guasti come guasti dei nodi, guasti di rete, ecc, il framework dovrebbe essere in grado di recuperare e dovrebbe ricominciare l’elaborazione dal punto in cui è partito. Questo si ottiene attraverso il checkpointing dello stato dello streaming in qualche memoria persistente di volta in volta. es. checkpointing kafka offsets a zookeeper dopo aver ottenuto un record da Kafka e averlo elaborato.
• Gestione dello stato :
  In caso di requisiti di elaborazione statica in cui abbiamo bisogno di mantenere un certo stato (es.Ad esempio il conteggio di ogni parola distinta vista nei record), il framework dovrebbe essere in grado di fornire qualche meccanismo per preservare e aggiornare le informazioni di stato.
• Performance :
  Questo include la latenza (quanto velocemente un record può essere elaborato), il throughput (record elaborati/secondo) e la scalabilità. La latenza dovrebbe essere la minima possibile mentre il throughput dovrebbe essere il più possibile. È difficile ottenere entrambi allo stesso tempo.
• Caratteristiche avanzate: Event Time Processing, Watermark, Windowing
  Queste sono caratteristiche necessarie se i requisiti di elaborazione del flusso sono complessi. Per esempio, l’elaborazione dei record in base al tempo in cui è stato generato alla fonte (elaborazione del tempo dell’evento). Per saperne di più in dettaglio, leggi questi post imperdibili di Tyler Akidau di Google: parte1 e parte2.
• Maturità :
  Importante dal punto di vista dell’adozione, è bello se il framework è già provato e testato in scala da grandi aziende. È più probabile ottenere un buon supporto della comunità e aiuto su stackoverflow.

Due tipi di elaborazione di flussi:

Ora che siamo consapevoli dei termini che abbiamo appena discusso, è facile capire che ci sono 2 approcci per implementare un framework di streaming:

Streaming nativo :
Conosciuto anche come Streaming nativo. Significa che ogni record in arrivo viene elaborato non appena arriva, senza aspettare gli altri. Ci sono alcuni processi in esecuzione continua (che chiamiamo operatori/task/bulloni a seconda del framework) che vengono eseguiti per sempre e ogni record passa attraverso questi processi per essere elaborato. Esempi: Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Anche noto come Fast Batching. Significa che i record in arrivo ogni pochi secondi sono raggruppati e poi processati in un unico mini-batch con un ritardo di pochi secondi. Esempi: Spark Streaming, Storm-Trident.

Entrambi gli approcci hanno alcuni vantaggi e svantaggi.
Lo Streaming nativo sembra naturale in quanto ogni record viene elaborato non appena arriva, permettendo al framework di raggiungere la minima latenza possibile. Ma significa anche che è difficile raggiungere la tolleranza d’errore senza compromettere il throughput, poiché per ogni record, abbiamo bisogno di tracciare e fare il checkpoint una volta elaborato. Inoltre, la gestione dello stato è facile perché ci sono processi a lungo termine che possono mantenere lo stato richiesto facilmente.

Micro-batching , d’altra parte, è abbastanza opposto. La tolleranza ai guasti è gratuita in quanto è essenzialmente un batch e il throughput è anche elevato in quanto l’elaborazione e il checkpointing saranno fatti in un colpo solo per un gruppo di record. Ma sarà al costo di una certa latenza e non si sentirà come uno streaming naturale. Anche la gestione efficiente dello stato sarà una sfida da mantenere.

Streaming Frameworks One By One:

Storm :
Storm è il hadoop del mondo dello streaming. È il più vecchio framework di streaming open source e uno dei più maturi e affidabili. È un vero streaming ed è buono per semplici casi d’uso basati su eventi. Ho condiviso i dettagli su Storm a lungo in questi post: parte1 e parte2.

Svantaggi:

• Latenza molto bassa, vero streaming, maturo ed elevato throughput
• Eccellente per casi d’uso di streaming non complicati

Svantaggi

• Nessuna gestione dello stato
• No funzioni avanzate come l’elaborazione del tempo degli eventi, aggregazione, windowing, sessioni, watermark, ecc
• Garanziatleast-once

Spark Streaming :

Spark è emerso come vero successore di Hadoop nell’elaborazione Batch e il primo framework a supportare completamente l’architettura Lambda (dove sono implementati sia Batch che Streaming; Batch per la correttezza, Streaming per la velocità). È immensamente popolare, maturato e ampiamente adottato. Spark Streaming viene fornito gratuitamente con Spark e utilizza il micro batching per lo streaming. Prima della versione 2.0, Spark Streaming aveva alcune serie limitazioni di prestazioni, ma con la nuova versione 2.0+, è chiamato streaming strutturato ed è dotato di molte buone caratteristiche come la gestione della memoria personalizzata (come Flink) chiamata tungsten, watermark, supporto all’elaborazione degli eventi, ecc. Anche lo Structured Streaming è molto più astratto e nella versione 2.3.0 c’è la possibilità di passare dalla modalità micro-batching a quella streaming continuo. La modalità di streaming continuo promette di dare una sub latenza come Storm e Flink, ma è ancora in una fase iniziale con molte limitazioni nelle operazioni.

Avantaggi:

• Supporta l’architettura Lambda, viene fornito gratuitamente con Spark
• Alto throughput, buono per molti casi d’uso in cui la sub-latenza non è richiesta
• Tolleranza ai guasti per impostazione predefinita a causa della natura micro-batch
• Semplice per usare API di livello superiore
• Grande comunità e miglioramenti aggressivi
• Esattamente una volta

Svantaggi

• Non vero streaming, non adatto a requisiti di bassa latenza
• Troppi parametri da regolare. Difficile da mettere a punto. Ho scritto un post sulla mia esperienza personale durante la messa a punto di Spark Streaming
• Stateless per natura
• Lascia indietro Flink in molte caratteristiche avanzate

Flink :

Flink ha anche un background accademico simile a Spark. Mentre Spark viene da UC Berkley, Flink viene dall’Università TU di Berlino. Come Spark supporta anche l’architettura Lambda. Ma l’implementazione è abbastanza opposta a quella di Spark. Mentre Spark è essenzialmente un batch con Spark streaming come micro-batching e caso speciale di Spark Batch, Flink è essenzialmente un vero motore di streaming che tratta il batch come caso speciale di streaming con dati limitati. Anche se le API in entrambi i framework sono simili, ma non hanno alcuna somiglianza nelle implementazioni. In Flink, ogni funzione come map, filter, reduce, ecc è implementata come operatore di lunga durata (simile a Bolt in Storm)

Flink sembra un vero successore di Storm come Spark è riuscito a hadoop in batch.

Avantaggi:

• Leader dell’innovazione nel panorama dello streaming open source
• Primo vero framework di streaming con tutte le caratteristiche avanzate come l’elaborazione temporale degli eventi, watermark, ecc
• Bassa latenza con alto throughput, configurabile secondo i requisiti
• Auto-regolazione, non troppi parametri da sintonizzare
• Esattamente una volta
• Vendendo ampiamente accettato da grandi aziende in scala come Uber, Alibaba.

Svantaggi

• Poco più tardi nel gioco, c’è stata una mancanza di adozione inizialmente
• La comunità non è grande come Spark ma cresce a ritmo veloce ora
• Nessuna adozione nota del Flink Batch per ora, solo popolare per lo streaming.

Kafka Streams :

Kafka Streams , a differenza di altri framework di streaming, è una libreria leggera. E’ utile per lo streaming dei dati da Kafka, per fare trasformazioni e poi rispedirli a Kafka. Possiamo intenderla come una libreria simile a Java Executor Service Thread pool, ma con il supporto integrato per Kafka. Può essere integrato bene con qualsiasi applicazione e funzionerà out of the box.

A causa della sua natura leggera, può essere utilizzato in architetture di tipo microservices. Non c’è partita in termini di prestazioni con Flink, ma non ha anche bisogno di un cluster separato per funzionare, è molto pratico e facile da distribuire e iniziare a lavorare. Internamente utilizza il gruppo Kafka Consumer e lavora sulla filosofia dei log Kafka.
Questo post spiega accuratamente i casi d’uso di Kafka Streams vs Flink Streaming.

Un grande vantaggio di Kafka Streams è che la sua elaborazione è Esattamente una volta end to end. È possibile perché la fonte e la destinazione sono entrambe Kafka e dalla versione Kafka 0.11 rilasciata intorno a giugno 2017, Exactly once è supportata. Per abilitare questa funzione, abbiamo solo bisogno di abilitare una bandiera e funzionerà fuori dalla scatola. Per ulteriori dettagli condivisi qui e qui.

Svantaggi:

• Leggera libreria, buona per microservizi, applicazioni IOT
• Non ha bisogno di cluster dedicati
• Eredita tutte le buone caratteristiche di Kafka
• Supporta gli Stream join, internamente usa rocksDb per mantenere lo stato.
• Exactly Once ( Kafka 0.11 in poi).

Svantaggi

• Strettamente accoppiato con Kafka, non può usare senza Kafka nella foto
• Quasi nuovo in fase iniziale, ancora da testare in grandi aziende
• Non per lavori pesanti come Spark Streaming, Flink.

Samza :

Copriremo Samza in breve. Samza da 100 piedi sembra simile a Kafka Streams nell’approccio. Ci sono molte somiglianze. Entrambi questi framework sono stati sviluppati dagli stessi sviluppatori che hanno implementato Samza presso LinkedIn e poi fondato Confluent dove hanno scritto Kafka Streams. Entrambe queste tecnologie sono strettamente accoppiate con Kafka, prendono i dati grezzi da Kafka e poi rimettono i dati elaborati a Kafka. Usano la stessa filosofia di Kafka Log. Samza è una sorta di versione scalata di Kafka Streams. Mentre Kafka Streams è una libreria destinata ai microservizi, Samza è un’elaborazione cluster completa che gira su Yarn.
Svantaggi :

• Molto buono nel mantenere grandi stati di informazioni (buono per il caso di utilizzo di unire i flussi) usando rocksDb e kafka log.
• Tollerante ai guasti e performante usando le proprietà di Kafka
• Una delle opzioni da considerare se si usa già Yarn e Kafka nella pipeline di elaborazione.
• Buon cittadino di Yarn
• Bassa latenza, alto rendimento, maturo e testato su scala

Svantaggi :

• Si accoppia strettamente con Kafka e Yarn. Non è facile da usare se uno di questi non è nella tua pipeline di elaborazione.
• Garanzia di elaborazionetleast-Once. Non sono sicuro se ora supporta esattamente una volta come Kafka Streams dopo Kafka 0.11
• Mancanza di caratteristiche avanzate di streaming come Watermark, Sessioni, trigger, ecc

Confronto dei Framework di Streaming:

Possiamo confrontare tecnologie solo con offerte simili. Mentre Storm, Kafka Streams e Samza sembrano ora utili per casi d’uso più semplici, la vera competizione è chiara tra i pesi massimi con le ultime caratteristiche: Spark vs Flink

Quando si parla di confronto, generalmente si tende a chiedere: Mostrami i numeri 🙂

Il benchmarking è un buon modo per confrontare solo quando è stato fatto da terzi.

Per esempio uno dei vecchi bench marking era questo.
Ma questo era a volte prima di Spark Streaming 2.0 quando aveva limitazioni con RDDs e tungsten progetto non era in atto.
Ora con Structured Streaming post 2.0 release , Spark Streaming sta cercando di recuperare molto e sembra che ci sarà una dura lotta davanti.

Recentemente il benchmarking è diventato una specie di lotta aperta tra Spark e Flink.

Spark ha recentemente fatto un confronto di benchmarking con Flink al quale gli sviluppatori di Flink hanno risposto con un altro benchmarking dopo il quale i ragazzi di Spark hanno modificato il post.

È meglio non credere al benchmarking in questi giorni perché anche un piccolo ritocco può cambiare completamente i numeri. Niente è meglio che provare e testare noi stessi prima di decidere.
A partire da oggi, è abbastanza ovvio che Flink sta guidando lo spazio di Streaming Analytics, con la maggior parte degli aspetti desiderati come esattamente una volta, throughput, latenza, gestione dello stato, tolleranza ai guasti, caratteristiche avanzate, ecc.

Queste sono state possibili grazie ad alcune delle vere innovazioni di Flink come snapshot leggeri e gestione della memoria personalizzata off heap.
Una preoccupazione importante con Flink era la maturità e il livello di adozione fino a qualche tempo fa, ma ora aziende come Uber, Alibaba, CapitalOne stanno usando Flink in streaming su larga scala, certificando il potenziale di Flink Streaming.

Recentemente, Uber ha aperto il loro ultimo framework di analisi in streaming chiamato AthenaX che è costruito sopra il motore Flink. In questo post, hanno discusso come hanno spostato la loro analisi in streaming da STorm ad Apache Samza e ora Flink.

Un punto importante da notare, se lo avete già notato, è che tutti i framework di streaming nativi come Flink, Kafka Streams, Samza che supportano la gestione dello stato utilizzano RocksDb internamente. RocksDb è unico nel senso che mantiene lo stato persistente localmente su ogni nodo ed è altamente performante. È diventato una parte cruciale dei nuovi sistemi di streaming. Ho condiviso informazioni dettagliate su RocksDb in uno dei post precedenti.

Come scegliere il miglior framework di streaming :

Questa è la parte più importante. E la risposta onesta è: dipende 🙂
È importante tenere a mente che nessun singolo framework di elaborazione può essere una pallottola d’argento per ogni caso d’uso. Ogni framework ha alcuni punti di forza e anche alcune limitazioni. Eppure, con un po’ di esperienza, condividerò alcuni suggerimenti per aiutare a prendere decisioni:

1. Dipende dai casi d’uso:
   Se il caso d’uso è semplice, non c’è bisogno di andare per l’ultimo e più grande framework se è complicato da imparare e implementare. Molto dipende da quanto siamo disposti a investire per quanto vogliamo in cambio. Per esempio, se si tratta di un semplice sistema di allarme basato su eventi IOT, Storm o Kafka Streams va benissimo per lavorare.
2. Considerazioni future:
   Al tempo stesso, dobbiamo anche avere una considerazione consapevole su quali saranno i possibili casi d’uso futuri? È possibile che le richieste di funzionalità avanzate come l’elaborazione degli eventi, l’aggregazione, le unioni di flussi, ecc. possano arrivare in futuro? Se la risposta è sì o può essere, allora è meglio andare avanti con framework di streaming avanzati come Spark Streaming o Flink. Una volta investito e implementato in una tecnologia, il suo costo difficile ed enorme per cambiare più tardi. Per esempio, nell’azienda precedente avevamo una pipeline Storm attiva e funzionante da 2 anni e funzionava perfettamente bene fino a quando non è arrivato un requisito per l’univocità degli eventi in entrata e per segnalare solo eventi unici. Ora questo richiedeva la gestione dello stato che non è intrinsecamente supportata da Storm. Anche se ho implementato utilizzando l’hashmap in-memory basata sul tempo, ma era con la limitazione che lo stato andrà via al riavvio. Inoltre, ha dato problemi durante tali modifiche che ho condiviso in uno dei post precedenti. Il punto che sto cercando di fare è che se cerchiamo di implementare da soli qualcosa che il framework non fornisce esplicitamente, siamo destinati a colpire problemi sconosciuti.
3. Existing Tech Stack :
   Un altro punto importante è considerare lo stack tecnologico esistente. Se lo stack esistente ha Kafka sul posto da un capo all’altro, allora Kafka Streams o Samza potrebbero essere più adatti. Allo stesso modo, se la pipeline di elaborazione è basata sull’architettura Lambda e Spark Batch o Flink Batch è già in atto, allora ha senso considerare Spark Streaming o Flink Streaming. Per esempio, in uno dei miei progetti precedenti avevo già Spark Batch nella pipeline e quindi quando è arrivato il requisito di streaming, è stato abbastanza facile scegliere Spark Streaming che richiedeva quasi lo stesso set di competenze e la stessa base di codice.

In breve, se capiamo bene i punti di forza e i limiti dei framework insieme ai nostri casi d’uso, allora è più facile scegliere o almeno filtrare le opzioni disponibili. Infine, è sempre bene avere POC una volta che un paio di opzioni sono state selezionate. Ognuno ha gusti diversi, dopo tutto.

Conclusione :

Lo spazio Apache Streaming si sta evolvendo a un ritmo così veloce che questo post potrebbe essere superato in termini di informazioni in un paio di anni. Attualmente Spark e Flink sono i pesi massimi che conducono dal fronte in termini di sviluppi, ma qualche nuovo ragazzo può ancora venire e unirsi alla corsa. Apache Apex è uno di questi. Ci sono anche soluzioni di streaming proprietarie che non ho coperto come Google Dataflow. Il mio obiettivo di questo post era quello di aiutare qualcuno che è nuovo allo streaming a capire, con un minimo di gergo, alcuni concetti fondamentali dello streaming insieme ai punti di forza, alle limitazioni e ai casi d’uso dei più popolari framework di streaming open source. Spero che il post sia stato utile in qualche modo.

Felice Streaming!!!

Puoi seguirmi su Linkedin e Quora