Google Dataflow vs. Apache Storm

Question

Wenn ich die Dataflow-API von Google gelesen habe, habe ich den Eindruck, dass sie Apache Storm sehr ähnlich ist. Echtzeit-Datenverarbeitung durch Pipeline-Fluss. Wenn ich den Punkt hier nicht völlig vermisse, würde ich, anstatt Brücken zu bauen, wie Pipelines gegeneinander geschrieben werden, etwas anderes von Google erwarten und das Rad nicht neu erfinden. Apache Storm ist bereits gut platziert und mit jeder Programmiersprache verwendbar. Was ist der wahre Wert, um so etwas zu tun?

Answer 1

Vielen Dank für Ihr Interesse am Dataflow-Programmiermodell! Es ist wahr, dass beide Datenfluss und Apache Sturm Unterstützung Stream-Verarbeitung, aber es gibt wichtige Unterschiede:

• Datenfluss sowohl Chargen- und Streaming-Berechnung unter dem gleichen „Windowing“ API unterstützt, während Sturm, soweit ich weiß, ist speziell ein Streaming-System.

• Die API zum Definieren der Topologie der Berechnung ist in Dataflow und Storm sehr unterschiedlich. Die Dataflow-API entspricht weitgehend FlumeJava: Sie manipulieren logische Objekte (parallele Sammlungen; Sie können sich diese als logische Datasets vorstellen), als ob Sie echte Sammlungen manipulieren und neue Sammlungen aus den Ergebnissen der Anwendung verschiedener parallelisierbarer Operationen erstellen würden (z. B. ParDo)) zu anderen Sammlungen. Im Gegensatz dazu bauen Sie in Apache Storm das Netzwerk der Berechnung direkt aus "Tüllen" und "Schrauben"; Es gibt keine explizite Vorstellung eines logischen Datensatzes oder einer mir bekannten Paralleloperation.

• Die logische Darstellung einer Pipeline in Dataflow ermöglicht es dem Framework, Optimierungen durchzuführen, die denen ähneln, die von Abfrageoptimierern in Datenbanksystemen, z. Vermeide oder führe die Materialisierung bestimmter Zwischenergebnisse ein, bewege oder entferne Gruppen-für-Schlüssel-Operationen usw. Du kannst einen Überblick über diese Optimierungen im FlumeJava-Papier sehen. Dies ist sowohl im Batch- als auch im Streaming-Modus nützlich.

• Die Konsistenzgarantien zwischen Dataflow und dem Streaming-Berechnungsmodell von Storm sind unterschiedlich. Das ist eigentlich ein faszinierendes Thema! Ich schlage vor, das Dokument Millwheel (auf das der Streaming-Teil von Dataflow basiert) zu lesen, um einen Überblick über die Probleme der Fehlertoleranz und Konsistenz in einem Streaming-System zu erhalten. Ich glaube, die Zeitung vergleicht auch kurz Millwheel mit Storm. Eine ausführlichere Diskussion der Bedeutung von Konsistenzgarantien in Streaming-Systemen und der Stärke der Konsistenz, die von Dataflow gegeben wird, finden Sie in der Diskussion Have Your Cake and Eat It Too -- Further Dispelling the Myths of the Lambda Architecture.

• Eines der Hauptvorteile von Dataflow als Teil der Google Cloud Platform ist kein Aufwand: Sie müssen keinen Cluster einrichten, ein Überwachungssystem einrichten usw.: Sie reichen einfach Ihre Pipeline ein an die Cloud-API und das System weist Ressourcen dafür zu, führt Ihre Pipeline mit diesen aus, überwacht sie für Sie.Das hängt vielleicht nicht mit Ihrer Frage nach der Ähnlichkeit des Programmiermodells zusammen.

Answer 2

Nein, das sind recht unterschiedliche Frameworks. Dataflow ist ein Nachfolger von FlumeJava, ähnlich wie Crunch und in geringerem Maße Spark. Es ist wirklich Spark zugeordnet. Das Streaming-Projekt von Spark wird der Streaming-Unterstützung von Dataflow zugeordnet, und diese beiden sind das am nächsten kommende Analog zu Storm (+ Trident). Aber es ist wirklich ein Teil von Dataflow, der Storm zugeordnet ist.

Spark Streaming und Dataflow-Streaming sind einander ähnlicher als Storm + Trident. Wenn Sie einen Vergleich von Spark Streaming und Storm online lesen, wird dies auch für Dataflow gelten.

Eine schöne Sache über Dataflow-Streaming ist, dass es extra mit dem nicht-Streaming-Kern integriert ist. Der Datenfluss bezieht sich meist nicht auf das Streaming. Sturm streamt alles.