Qual è / sono le principali differenze tra Flink e Storm?


137

Flink è stato paragonato a Spark , che, a mio modo di vedere, è il confronto sbagliato perché confronta un sistema di elaborazione degli eventi con finestra con il micro-batch; Allo stesso modo, per me non ha molto senso paragonare Flink a Samza. In entrambi i casi confronta una strategia di elaborazione degli eventi in tempo reale rispetto a quella in batch, anche se su una "scala" più piccola nel caso di Samza. Ma vorrei sapere come Flink paragona a Storm, che concettualmente sembra molto più simile ad esso.

Ho trovato questo (Slide # 4) che documenta la differenza principale come "latenza regolabile" per Flink. Un altro suggerimento sembra essere un articolo di Slicon Angle che suggerisce che Flink si integri meglio in un mondo Spark o HadoopMR, ma nessun dettaglio reale è menzionato o referenziato. Infine, Fabian Hueske stesso nota in un'intervista che "Rispetto ad Apache Storm, la funzionalità di analisi del flusso di Flink offre un'API di alto livello e utilizza una strategia di tolleranza agli errori più leggera per fornire garanzie di elaborazione esattamente una volta".

Tutto ciò è un po 'scarso per me e non capisco bene il punto. Qualcuno può spiegare quali problemi (s?) Con l'elaborazione del flusso in Storm sono (sono?) Risolti esattamente da Flink? A cosa si riferisce Hueske per i problemi API e la loro "strategia di tolleranza agli errori più leggera"?


2
Nota che Apache Spark (il focus della domanda collegata) non è lo stesso di Apache Storm (questa domanda qui) - quindi no, questo non è affatto un duplicato.
fnl,

Risposte:


213

Disclaimer : sono un committer Apache Flink e membro PMC e ho familiarità solo con il design di alto livello di Storm, non con i suoi interni.

Apache Flink è un framework per l'elaborazione unificata e batch. Il runtime di Flink supporta nativamente entrambi i domini a causa del trasferimento di dati in pipeline tra attività parallele che include shuffle di pipeline. I record vengono immediatamente spediti dalla produzione delle attività alla ricezione delle attività (dopo essere stati raccolti in un buffer per il trasferimento di rete). I lavori batch possono essere eseguiti facoltativamente utilizzando il blocco dei trasferimenti di dati.

Apache Spark è un framework che supporta anche l'elaborazione batch e stream. L'API batch di Flink sembra abbastanza simile e affronta casi d'uso simili a Spark ma differisce negli interni. Per lo streaming, entrambi i sistemi seguono approcci molto diversi (mini-batch vs. streaming) che li rendono adatti a diversi tipi di applicazioni. Direi che il confronto tra Spark e Flink è valido e utile, tuttavia Spark non è il motore di elaborazione del flusso più simile a Flink.

Venendo alla domanda originale, Apache Storm è un processore di flusso di dati senza funzionalità batch. In effetti, il motore a pipeline di Flink internamente sembra un po 'simile a Storm, cioè le interfacce dei compiti paralleli di Flink sono simili ai bulloni di Storm. Storm e Flink hanno in comune l'obiettivo di elaborare flussi a bassa latenza mediante trasferimenti di dati in pipeline. Tuttavia, Flink offre un'API di livello più elevato rispetto a Storm. Invece di implementare la funzionalità di un bolt con uno o più lettori e collezionisti, l'API DataStream di Flink fornisce funzioni come Map, GroupBy, Window e Join. Molte di queste funzionalità devono essere implementate manualmente quando si utilizza Storm. Un'altra differenza è l'elaborazione della semantica. Storm garantisce l'elaborazione almeno una volta, mentre Flink fornisce esattamente una volta. Le implementazioni che danno queste garanzie di elaborazione differiscono abbastanza. Mentre Storm utilizza riconoscimenti a livello record, Flink utilizza una variante dell'algoritmo Chandy-Lamport. In breve, le origini dati iniettano periodicamente marcatori nel flusso di dati. Ogni volta che un operatore riceve un tale marker, controlla il suo stato interno. Quando un marker è stato ricevuto da tutti i sink di dati, viene eseguito il commit del marker (e di tutti i record che sono stati elaborati in precedenza). In caso di errore, tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker commesso e l'elaborazione è continuata. Questo approccio marcatore-checkpoint è più leggero rispetto ai riconoscimenti a livello record di Storm. Questo le origini dati iniettano periodicamente marcatori nel flusso di dati. Ogni volta che un operatore riceve un tale marker, controlla il suo stato interno. Quando un marker è stato ricevuto da tutti i sink di dati, viene eseguito il commit del marker (e di tutti i record che sono stati elaborati in precedenza). In caso di errore, tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker commesso e l'elaborazione è continuata. Questo approccio marcatore-checkpoint è più leggero rispetto ai riconoscimenti a livello record di Storm. Questo le origini dati iniettano periodicamente marcatori nel flusso di dati. Ogni volta che un operatore riceve un tale marker, controlla il suo stato interno. Quando un marker è stato ricevuto da tutti i sink di dati, viene eseguito il commit del marker (e di tutti i record che sono stati elaborati in precedenza). In caso di errore, tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker commesso e l'elaborazione è continuata. Questo approccio marcatore-checkpoint è più leggero rispetto ai riconoscimenti a livello record di Storm. Questo tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker commesso e l'elaborazione è continuata. Questo approccio marcatore-checkpoint è più leggero rispetto ai riconoscimenti a livello record di Storm. Questo tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker commesso e l'elaborazione è continuata. Questo approccio marcatore-checkpoint è più leggero rispetto ai riconoscimenti a livello record di Storm. Questoil set di diapositive e il discorso corrispondente descrivono l'approccio di elaborazione dello streaming di Flink tra cui tolleranza agli errori, checkpoint e gestione dello stato.

Storm offre anche un'API di alto livello esattamente una volta chiamata Trident. Tuttavia, Trident si basa su mini-batch e quindi più simile a Spark che a Flink.

La latenza regolabile di Flink si riferisce al modo in cui Flink invia i record da un'attività all'altra. Ho detto prima che Flink utilizza trasferimenti di dati con pipeline e inoltra i record non appena vengono prodotti. Per motivi di efficienza, questi record vengono raccolti in un buffer che viene inviato sulla rete quando è pieno o quando viene raggiunta una determinata soglia di tempo. Questa soglia controlla la latenza dei record perché specifica il tempo massimo in cui un record rimarrà in un buffer senza essere inviato all'attività successiva. Tuttavia, non può essere utilizzato per fornire garanzie concrete circa il tempo impiegato da un record per entrare in un programma perché dipende anche dal tempo di elaborazione all'interno delle attività e dal numero di trasferimenti di rete tra le altre cose.


2
Molte grazie! Un punto in sospeso forse, se potessi disturbarti ancora una volta: di cosa tratta questo problema di "latenza regolabile"? Sembra che potrebbe essere abbastanza rilevante dato che domini applicativi diversi avranno requisiti diversi a questo proposito. Puoi spiegare cosa questo implica, almeno in termini di Flink?
fnl

6
Certo, ho esteso la mia risposta e discusso della latenza regolabile. Fammi sapere se hai ulteriori domande.
Fabian Hueske,

Flink consente modifiche "a caldo" al flusso di lavoro del DAG, come si può implementare, ad esempio, usando Erlang? IE. È possibile modificare il DAG durante il runtime?
Thomas Browne,

1
Lo scambio di codice a caldo non è possibile. Tuttavia, è possibile mantenere lo stato di un'applicazione come punto di salvataggio. Il punto di salvataggio può essere utilizzato per avviare un'applicazione modificata. Questo può essere fatto mentre l'applicazione originale è ancora in esecuzione in modo tale che l'output possa essere girato ad un certo punto. Si noti che le app non possono essere modificate arbitrariamente quando si riprende da un punto di salvataggio esistente.
Fabian Hueske,

1
Flink interessante e enorme vantaggio di Flink è la capacità di eseguire Apache Beam con API di livello ancora più elevato. È uno dei corridori più ricchi e completi per Beam.
Piotr Gwiazda,

47

Aggiungendo alla risposta di Fabian Hueske:

Flink migliora ulteriormente Storm anche nei seguenti modi:

  • Backpressure: il runtime di streaming di Flink si comporta bene quando diversi operatori funzionano a velocità diverse, perché gli operatori a valle eseguono una contropressione degli operatori a monte benché il livello di rete gestisca i pool di buffer.

  • Stato definito dall'utente: Flink consente ai programmi di mantenere lo stato personalizzato nei propri operatori. Tale stato può effettivamente partecipare al checkpoint per la tolleranza agli errori, fornendo esattamente una volta garanzie per lo stato personalizzato definito dall'utente. Vedi questo esempio di una macchina a stati definita dall'utente all'interno di un operatore, che viene costantemente controllata insieme al flusso di dati.

  • Streaming di Windows: lo streaming di finestre e aggregazioni di finestre sono elementi fondamentali per l'analisi dei flussi di dati. Flink viene fornito con un sistema di finestre abbastanza potente che supporta molti tipi di finestre.


2
Per quanto riguarda il tuo primo punto, Storm è ben educato alla contropressione a partire dall'1.0 (rilasciato aprile 2016)
Colin Nichols,

La contropressione della tempesta può essere mitigata usando la proprietà "spout_max_pending". Imposta una soglia per le tuple massime che possono essere presenti in un beccuccio in attesa di conferma. Il beccuccio non consumerà più tuple andando avanti fino a quando non si verifica l'accumulo.
Aman Garg,

3

Basato sulla mia esperienza di Storm and Flink. Sento che questi strumenti possono risolvere lo stesso problema con approcci diversi. Ogni funzionalità di Flink menzionata da @Stephan Ewen può essere abbinata a Storm con API interne (ad es. Spolts e bolt ) e API Trident ora. Qualcuno afferma che Trident è in stile mini-batch mentre penso che la maggior parte delle app complesse con stato o aggregazione possa dipendere solo dall'elaborazione batch con stile finestra. Quindi elencherò qui alcune differenze principali senza dire quale sia la migliore.

  • Stile di sviluppo . orientato al calcolo (ad esempio, operatore concatenabile) in Flink vs. orientato al flusso di dati (ad esempio, addSpolt()/addBolt()) in Storm.
  • API di alto livello . Funzioni (ad es. Mappa, Finestra, Partecipa a livello di streaming) in Flink vs. Native Window e Trident in Storm.
  • Elaborazione dei messaggi garantita (GMP. Cioè, esattamente una volta ) . Checkpoint con connettore Commit bifase (ad es. KafkaConsumer) in Flink vs. Tuple-tree con la macchina a stati esterna o Trident in Storm.
  • Tolleranza ai guasti . Marker-checkpoint in Flink vs. record-level-ACK in Storm.
  • Architettura interna . Astrazione semplice e relativo parallelismo (ad esempio, slot per ogni thread considerato con core della CPU) in astrazioni Flink vs. Multi-layer (ad esempio, slot per ogni JVM come lavoratore in supervisore e ogni supervisore può avere molti lavoratori) in Storm.

3

Disclaimer: sono un dipendente di Cloudera, un grande sostenitore di Storm e (presto) Flink.

Funzionale

Sono già stati presentati molti buoni punti tecnici. Un breve riassunto dei punti salienti:

  • Sia Flink che Storm possono eseguire l'elaborazione per evento
  • Storm non sembra supportare il time-out immediato
  • Storm non ha rimosso il supporto SQL dalla fase sperimentale

Non funzionale

  • Molti clienti hanno trovato Storm (troppo) difficile da usare
  • L'adozione di Storm ha rallentato e la comunità di Flink ora sembra essere più attiva di Storm
  • Flink ha ancora qualcosa da recuperare (ad esempio esempi documentati), ma nel complesso ha raggiunto quasi ogni area a cui potresti pensare

Conclusione

Cloudera ha recentemente annunciato la deprecazione di Storm (in HDP). E contemporaneamente Flink fu annunciato come suo successore.

Quindi, se hai delle valigie in tempesta, ovviamente continueranno a funzionare. Ma per i nuovi casi d'uso esaminerei Flink o altri motori di streaming.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.