Google Dataflow vs Apache Storm

Question

Czytanie Google Dataflow API, mam wrażenie, że jest bardzo podobny do tego, co robi Apache Storm. Przetwarzanie danych w czasie rzeczywistym przez przepływ potokowy. Chyba, że ​​całkowicie pomijam tę kwestię, zamiast budować mosty na temat wykonywania rurociągów napisanych przeciwko sobie, oczekiwałbym czegoś innego od Google, a nie wymyślania na nowo koła. Apache Storm jest już dobrze rozmieszczony i można go używać z dowolnym językiem programowania. Jaka jest prawdziwa wartość za zrobienie czegoś takiego?

Answer 1

Dziękujemy za zainteresowanie modelem programowania danych! Prawdą jest, że zarówno Dataflow i Apache Burza wsparcie przetwarzania strumienia, ale istnieją ważne różnice:

• Dataflow obsługuje zarówno partię i strumieniowe obliczeń pod tym samym „graficzną” API, podczas burzy, o ile mi wiadomo, jest konkretnie systemem przesyłania strumieniowego.

• Interfejs API do określania topologii obliczeń różni się znacznie w przepływie danych i burzy. Interfejs API przepływ danych w znacznym stopniu naśladuje FlumeJava: można manipulować obiektami logicznymi (kolekcje równoległe, można je traktować jak zbiory danych logicznych), tak jak można manipulować rzeczywistymi kolekcjami i tworzyć nowe kolekcje z wyników stosowania różnych operacji zrównoległych (takich jak ParDo) do innych kolekcji. Przeciwnie, w Apache Storm budujesz sieć obliczeń bezpośrednio z "wylewek" i "zasuw"; nie ma wyraźnego pojęcia logicznego zestawu danych lub operacji równoległej, o której jestem świadomy.

• Logiczna reprezentacja potoku w przepływie danych umożliwia systemowi wykonywanie optymalizacji podobnych do przeprowadzanych przez optymalizatory zapytań w systemach baz danych, np. unikać lub wprowadzać materializację pewnych pośrednich wyników, poruszać się lub eliminować operacje grupowo-klawiszowe, itp. Przegląd tych optymalizacji można znaleźć w artykule FlumeJava. Jest to przydatne zarówno w trybie wsadowym, jak i strumieniowym.

• Gwarancja spójności między modelem Dataflow a modelem przetwarzania strumieniowego Storma jest różna. To naprawdę fascynujący temat! Proponuję zapoznać się z artykułem Millwheel (na którym opiera się strumieniowa część Dataflow), aby zapoznać się z problemami związanymi z tolerancją błędów i konsekwencją w systemie przesyłania strumieniowego. Wydaje mi się, że artykuł ten krótko porównuje Millwheel z Storm. Można znaleźć szerszą dyskusję na temat znaczenia gwarancji konsystencji w systemach transmisji strumieniowej oraz mocy spójności danych dostarczanych przez Dataflow w rozmowie Have Your Cake and Eat It Too -- Further Dispelling the Myths of the Lambda Architecture.

• Jedną z głównych propozycji wartości Dataflow w ramach Google Cloud Platform jest zero problemów: nie musisz konfigurować klastra, skonfigurować systemu monitorowania itp .: po prostu przesyłaj swój rurociąg do API w chmurze, a system alokuje dla niego zasoby, uruchamia twój potok za ich pomocą, monitoruje go dla ciebie.Być może nie jest to jednak związane z pańskim pytaniem o podobieństwo modelu programistycznego.

Answer 2

Nie, to są całkiem różne ramy. Dataflow jest następcą FlumeJava, podobnie jak Crunch i w mniejszym stopniu Spark. To naprawdę przypomina Sparka. Projekt Spark's Streaming jest mapowany na obsługę przesyłania strumieniowego Dataflow, a oba są najbliższymi odpowiednikami Storm (+ Trident). Ale to naprawdę część przepływu danych, która jest mapowana na Storm.

Strumieniowe przesyłanie strumieniowe i transmisje danych są bardziej podobne do siebie niż do Storm + Trident. Jeśli przeczytasz porównanie Spark Streaming i Storm online, będzie to dotyczyło głównie Dataflow.

Jedną z zalet przesyłania strumieniowego danych jest to, że jest ona bardziej zintegrowana z rdzeniem nieodtwarzanym strumieniowo. Przepływ danych w większości nie ma związku z przesyłaniem strumieniowym; Storm cały streamuje.