it-swarm.dev

Quali sono/sono le principali differenze tra Flink e Storm?

Flink è stato confrontato con Spark , che, a mio avviso, è il confronto sbagliato perché confronta un sistema di elaborazione degli eventi con finestre contro il micro-batching; Allo stesso modo, per me non ha molto senso confrontare Flink con Samza. In entrambi i casi confronta una strategia di elaborazione degli eventi in tempo reale o in batch, anche se su scala minore nel caso di Samza. Ma mi piacerebbe sapere come Flink paragona a Storm, che sembra concettualmente molto più simile ad esso.

Ho trovato this (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, lo stesso Fabian Hueske osserva 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 il punto. Qualcuno può spiegare quale problema (s?) Con l'elaborazione del flusso in Storm è (sono?) Risolto esattamente da Flink? A che cosa si riferisce Hueske in merito ai problemi dell'API e alla loro "più leggera strategia di tolleranza agli errori"?

113
fnl

Disclaimer: Sono un committer Apache Flink e membro PMC e conosco solo il design di alto livello di Storm, non i suoi interni. 

Apache Flink è un framework per lo streaming unificato e l'elaborazione batch. Il runtime di Flink supporta nativamente entrambi i domini a causa del trasferimento di dati in pipeline tra attività parallele, che include il shuffle pipeline. I record vengono immediatamente spediti dalla produzione delle attività alle attività di ricezione (dopo essere stati raccolti in un buffer per il trasferimento di rete). I lavori batch possono essere facoltativamente eseguiti 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 di utilizzo simili a Spark, ma si differenzia negli interni. Per lo streaming, entrambi i sistemi seguono approcci molto diversi (mini-batch e streaming) che li rendono adatti a diversi tipi di applicazioni. Direi che confrontare Spark e Flink è valido e utile, tuttavia, Spark non è il motore di elaborazione dei flussi più simile a Flink.

Venendo alla domanda originale, Apache Storm è un processore di flusso di dati senza capacità batch. In effetti, il motore pipeline di Flink internamente sembra un po 'simile a Storm, cioè le interfacce dei task paralleli di Flink sono simili ai bulloni di Storm. Storm e Flink hanno in comune il fatto che mirano all'elaborazione del flusso a bassa latenza tramite trasferimenti di dati pipeline. Tuttavia, Flink offre un'API di livello superiore rispetto a Storm. Invece di implementare la funzionalità di un bullone 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 almeno una volta l'elaborazione mentre Flink fornisce esattamente una volta. Le implementazioni che danno queste garanzie di elaborazione differiscono un po '. Mentre Storm usa riconoscimenti a livello di record, Flink usa una variante dell'algoritmo Chandy-Lamport. In poche parole, le fonti di dati inseriscono periodicamente dei marcatori nel flusso di dati. Ogni volta che un operatore riceve un tale indicatore, controlla il suo stato interno. Quando un marker è stato ricevuto da tutti i sink di dati, il marker (e tutti i record che sono stati elaborati prima) vengono impegnati. In caso di errore, tutti gli operatori delle fonti vengono reimpostati al loro stato quando hanno visto l'ultimo marker impegnato e l'elaborazione è proseguita. Questo approccio al punto di controllo dei marker è più leggero rispetto ai riconoscimenti a livello di record di Storm. Questo set di diapositive e il corrispondente talk discutono l'approccio di elaborazione dello streaming di Flink che include tolleranza agli errori, checkpoint e gestione dello stato.

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

La latenza impostabile di Flink si riferisce al modo in cui Flink invia i record da un'attività all'altra. Ho detto prima che Flink utilizza i trasferimenti di dati pipeline e i record in avanti non appena vengono prodotti. Per l'efficienza, questi record sono raccolti in un buffer che viene inviato sulla rete una volta che è pieno o una certa soglia di tempo è soddisfatta. Questa soglia controlla la latenza dei record perché specifica la quantità massima di tempo in cui un record rimarrà in un buffer senza essere inviato all'attività successiva. Tuttavia, non può essere utilizzato per fornire garanzie rigide sul tempo necessario affinché un record entri in uscita da un programma, poiché ciò dipende anche dal tempo di elaborazione all'interno delle attività e dal numero di trasferimenti di rete tra le altre cose.

171
Fabian Hueske

In aggiunta alla risposta di Fabian Hueske:

Flink migliora anche su Storm anche nei seguenti modi:

  • Backpressure: il runtime streaming di Flink si comporta bene quando operatori diversi vengono eseguiti a velocità diverse, poiché gli operatori downstream eseguono una contropressione degli operatori upstream molto bene sebbene il pool layer gestisca i bufferpool.

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

  • Streaming di Windows: le finestre di streaming e le aggregazioni di finestre sono un elemento fondamentale per l'analisi dei flussi di dati. Flink è dotato di un potente sistema di finestre che supporta molti tipi di finestre.

41
Stephan Ewen

Basato sulla mia esperienza di Storm and Flink. Ritengo che questi strumenti possano risolvere lo stesso problema con approcci diversi. Ogni funzionalità di Flink menzionata da @Stephan Ewen può essere abbinata a Storm con API interne (ad esempio, spolts e bolts) e Trident API ora. Qualcuno sostiene che Trident sia in stile mini-batch, mentre penso che la maggior parte delle app complesse con aggregazione dello stato o dipendano solo dall'elaborazione in batch con lo stile di una finestra. Quindi elencherò alcune differenze principali qui senza dire quale sia meglio.

  • Stile di sviluppo . orientato al calcolo (ad esempio, operatore concatenabile) in Flink rispetto a orientato al flusso di dati (ad esempio, addSpolt()/addBolt()) in Storm.
  • API di alto livello . Funzioni (ad esempio, Mappa, Finestra, Join in Streaming level) in Flink vs. Native Window e Trident in Storm.
  • Elaborazione dei messaggi garantita (GMP, cioè, {esattamente-una volta sola) . Punto di controllo con connettore di commit a due fasi (ad esempio, KafkaConsumer) in Flink rispetto a albero di tuple con la macchina di stato esterna o Trident in Storm.
  • Tolleranza ai guasti . Marker-checkpoint in Flink vs. record-level-ACK in Storm.
  • Architettura interna . Astrazione semplice e parallelismo relativo (ad esempio, slot per ogni thread considerato con core CPU) in Flink rispetto a astrazioni multistrato (ad esempio, slot per ogni JVM come worker in supervisor e ciascun supervisore può avere molti worker) in Storm.
0
LeoZhang