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

Question

Flink è stato compared to Spark, che, a mio avviso, è il confronto errato perché confronta un sistema di elaborazione degli eventi a finestre con il micro-batching; Allo stesso modo, non ha molto senso per me confrontare Flink con Samza. In entrambi i casi confronta una strategia di elaborazione degli eventi in tempo reale e 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 (Diapositiva n. 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 non vengono menzionati né citati dettagli reali. Infine, lo stesso Fabian Hueske nota in an interview 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 esattamente le garanzie di elaborazione una volta."

Tutto ciò è un po 'scarso per me e non ho proprio capito. 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"?

Answer 1

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 in modo nativo 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 aver raccolto un buffer per il trasferimento di rete). I lavori batch possono essere opzionalmente 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 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 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 guasto, 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 slide set e il corrispondente talk discutono l'approccio di elaborazione dello streaming di Flink, compresa la tolleranza agli errori, il checkpoint e la 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 usa i trasferimenti di dati pipeline e inoltra i record non appena vengono prodotti. Per l'efficienza, questi record vengono raccolti in un buffer che viene inviato attraverso la 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.

Answer 2

Aggiungendo alla risposta di Fabian Hueske:

Flink migliora Tempesta inoltre anche nei seguenti modi:

• contropressione: runtime di streaming di Flink è ben comportata quando diversi operatori corrono a velocità diverse, perché gli operatori a valle eseguono una contropressione molto efficace degli operatori a monte, sebbene il livello di rete gestisca i pool di buffer.

• Stato definito dall'utente: Flink consente ai programmi di mantenere lo stato personalizzato negli operatori. Tale stato può effettivamente partecipare al checkpoint per la tolleranza agli errori, fornendo garanzie esattamente una volta per lo stato personalizzato definito dall'utente. Vedere this example 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 flusso 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.