Google Dataflow vs Apache Storm

Question

Leggendo l'API di Dataflow di Google, ho l'impressione che sia molto simile a ciò che fa Apache Storm. Elaborazione dati in tempo reale tramite flusso di pipeline. A meno che non mi sfugga completamente il punto qui, invece di costruire ponti su come eseguire pipeline scritte l'una contro l'altra, mi aspetterei qualcosa di diverso da Google e non reinventare la ruota. Apache Storm è già ben posizionato e utilizzabile con qualsiasi linguaggio di programmazione. Qual è il vero valore per fare qualcosa del genere?

Answer 1

Grazie per l'interesse nel modello di programmazione Dataflow! E 'vero che sia flusso di dati e Apache Tempesta supporto stream processing, ma ci sono differenze importanti:

• Dataflow supporta sia in batch e lo streaming di calcolo sotto lo stesso "a finestre" API, mentre Tempesta, per quanto ne so, è specificamente un sistema di streaming.

• L'API per la definizione della topologia del calcolo è molto diversa in Dataflow e Storm. L'API di Dataflow riproduce in gran parte lo FlumeJava: si manipolano gli oggetti logici PCollection (raccolte parallele, si possono considerare come set di dati logici) come si gestiscono raccolte reali e si creano nuove raccolte dai risultati dell'applicazione di diverse operazioni parallelizzabili (ad esempio ParDo) ad altre raccolte. Al contrario, in Apache Storm si costruisce la rete del calcolo direttamente da "spout" e "bulloni"; non esiste una nozione esplicita di un set di dati logici o un'operazione parallela di cui sono a conoscenza.

• La rappresentazione logica di una pipeline in Dataflow consente al framework di eseguire ottimizzazioni simili a quelle eseguite da Query Optimizer nei sistemi di database, ad es. evitare o introdurre la materializzazione di determinati risultati intermedi, spostarsi o eliminare le operazioni group-by-key, ecc. È possibile visualizzare una panoramica di queste ottimizzazioni nel documento FlumeJava. Questo è utile sia in modalità batch che streaming.

• Le garanzie di coerenza tra il modello di calcolo streaming di Dataflow e Storm sono diverse. Questo è in realtà un argomento affascinante! Suggerisco di leggere la carta Millwheel (che è ciò su cui si basa la parte di streaming di Dataflow) per una panoramica dei problemi di tolleranza d'errore e coerenza in un sistema di streaming. Credo che il documento paragoni brevemente anche Millwheel con Storm. È possibile trovare una discussione più ampia sull'importanza delle garanzie di coerenza nei sistemi di streaming e la potenza della coerenza data da Dataflow, nel talk Have Your Cake and Eat It Too -- Further Dispelling the Myths of the Lambda Architecture.

• Una delle principali proposizioni di valore di Dataflow come parte della piattaforma cloud di Google è a zero problemi: non è necessario impostare un cluster, configurare un sistema di monitoraggio, ecc .: basta inviare la pipeline all'API cloud e il sistema assegna le risorse per esso, esegue la pipeline che le utilizza, monitora per te.Questo forse non è correlato alla tua domanda sulla somiglianza del modello di programmazione, però.

Answer 2

No, questi sono quadri molto diversi. Dataflow è un successore di FlumeJava, nel modo in cui Crunch e in misura minore Spark è. Funziona davvero su Spark. Il progetto Streaming di Spark è mappato al supporto Streaming di Dataflow, entrambi questi sono l'analogo più simile a Storm (+ Trident). Ma è davvero un pezzo di Dataflow che si associa a Storm.

Spark Streaming e lo streaming di Dataflow sono più simili tra loro che a Storm + Trident. Se leggi qualsiasi confronto tra Spark Streaming e Storm online, si applicherà anche a Dataflow.

Una cosa bella dello streaming di Dataflow è che è extra-integrato con il core non streaming. Il flusso di dati per lo più non è correlato allo streaming; Storm è tutto in streaming.