Jakie są zalety Apache Beam nad Spark / Flink w przetwarzaniu wsadowym?

Apache Beam obsługuje wiele backendów runner, w tym Apache Spark i Flink. Znam Spark / Flink i próbuję zobaczyć zalety / wady Beam do przetwarzania wsadowego.

Patrząc na przykład liczby słów Beam , wydaje się, że jest bardzo podobny do rodzimych odpowiedników Spark / Flink, może z nieco bardziej szczegółową składnią.

Obecnie nie widzę dużej korzyści z wyboru Beam over Spark / Flink do takiego zadania. Jedyne obserwacje, jakie mogę poczynić do tej pory:

• Pro: Abstrakcja w stosunku do różnych backendów wykonawczych.
• Wada: ta abstrakcja kosztuje mniejszą kontrolę nad tym, co dokładnie jest wykonywane w Spark / Flink.

Czy są lepsze przykłady, które podkreślają inne zalety / wady modelu Beam? Czy są jakieś informacje, jak utrata kontroli wpływa na wydajność?

Zwróć uwagę, że nie proszę o różnice w aspektach przesyłania strumieniowego, które są częściowo omówione w tym pytaniu i podsumowane w tym artykule (nieaktualne ze względu na Spark 1.X).

Jest kilka rzeczy, które Beam dodaje do wielu istniejących silników.

• Ujednolicenie partii i przesyłania strumieniowego. Wiele systemów obsługuje zarówno przetwarzanie wsadowe, jak i przesyłanie strumieniowe, ale często robią to za pośrednictwem oddzielnych interfejsów API. Jednak w Beam wsad i przesyłanie strumieniowe to tylko dwa punkty w spektrum opóźnień, kompletności i kosztów. Nie ma uczenia się / przepisywania klifu z partii do przesyłania strumieniowego. Więc jeśli dzisiaj napiszesz potok wsadowy, ale jutro twoje opóźnienie będzie wymagało zmiany, jest to niezwykle łatwe do dostosowania. Ten rodzaj podróży możesz zobaczyć w przykładach gier mobilnych .

• Interfejsy API, które podnoszą poziom abstrakcji : interfejsy API Beam koncentrują się na przechwytywaniu właściwości danych i logiki, zamiast przepuszczać szczegóły podstawowego środowiska uruchomieniowego. Ma to kluczowe znaczenie dla przenośności (patrz następny akapit), a także może zapewnić środowisku wykonawczym dużą elastyczność w sposobie ich wykonywania. Coś w rodzaju fuzji ParDo (zwanej również kompozycją funkcji) jest dość podstawową optymalizacją, którą wykonuje już większość biegaczy. W przypadku niektórych biegaczy nadal wdrażane są inne optymalizacje. Na przykład Source APIs firmy Beamsą specjalnie zbudowane, aby uniknąć nadmiernej specyfikacji fragmentowania w potoku. Zamiast tego dają biegaczom odpowiednie zaczepy do dynamicznego równoważenia pracy na dostępnych maszynach. Może to spowodować ogromną różnicę w wydajności, zasadniczo eliminując odłamki maruderów. Ogólnie rzecz biorąc, im więcej sprytu uda nam się wbudować w biegaczy, tym lepiej nam będzie. Nawet najbardziej staranne dostrojenie ręczne zakończy się niepowodzeniem, gdy dane, kod i środowisko ulegną zmianie.

• Przenośność w różnych środowiskach wykonawczych. : Ponieważ kształty danych i wymagania dotyczące środowiska wykonawczego są starannie rozdzielone, ten sam potok można uruchomić na wiele sposobów. A to oznacza, że ​​nie kończysz przepisywania kodu, gdy musisz przejść z systemu lokalnego do chmury lub ze wypróbowanego i prawdziwego systemu do czegoś najnowocześniejszego. Możesz bardzo łatwo porównać opcje, aby znaleźć połączenie środowiska i wydajności, które najlepiej odpowiada Twoim aktualnym potrzebom. Może to być kombinacja rzeczy - przetwarzanie poufnych danych na miejscu za pomocą narzędzia do uruchamiania oprogramowania typu open source i przetwarzanie innych danych w usłudze zarządzanej w chmurze.

Zaprojektowanie modelu Beam jako użytecznej abstrakcji dla wielu różnych silników jest trudne. Belka nie jest ani przecięciem funkcjonalności wszystkich silników (zbyt ograniczona!), Ani złączem (za dużo zlewu kuchennego!). Zamiast tego Beam stara się być liderem w dziedzinie przetwarzania danych, zarówno wprowadzając funkcjonalność do silników wykonawczych, jak i wyciągając wzorce z nich.

• Keyed State to doskonały przykład funkcjonalności, która istniała w różnych silnikach i umożliwiała interesujące i powszechne przypadki użycia, ale pierwotnie nie była możliwa do wyrażenia w Beam. Niedawno rozszerzyliśmy model Beam o wersję tej funkcji zgodną z zasadami projektowania Beam .
• I na odwrót, mamy nadzieję, że Beam wpłynie również na mapy drogowe różnych silników. Na przykład na semantykę Flink's DataStreams wpłynął model Beam (z domu Dataflow).
• Oznacza to również, że możliwości nie zawsze będą dokładnie takie same dla różnych biegaczy Beam w danym momencie. Dlatego właśnie używamy macierzy możliwości, aby spróbować jasno przedstawić stan rzeczy.