Według ostatniego raportu IBM Marketing cloud, „90 procent danych na dzisiejszym świecie zostało stworzonych tylko w ciągu ostatnich dwóch lat, tworząc 2.5 kwintylionów bajtów danych każdego dnia – a wraz z pojawianiem się nowych urządzeń, czujników i technologii tempo wzrostu ilości danych prawdopodobnie przyspieszy jeszcze bardziej”.
Technicznie oznacza to, że nasz świat Big Data Processing będzie bardziej złożony i bardziej wymagający. Wiele przypadków użycia (np. reklamy w aplikacjach mobilnych, wykrywanie oszustw, rezerwacje taksówek, monitorowanie pacjentów itp.) wymaga przetwarzania danych w czasie rzeczywistym, w miarę napływu danych, w celu podejmowania szybkich decyzji. Dlatego właśnie Distributed Stream Processing stało się bardzo popularne w świecie Big Data.

Dzisiaj dostępnych jest wiele frameworków strumieniowych typu open source. Co ciekawe, prawie wszystkie z nich są dość nowe i zostały opracowane w ciągu ostatnich kilku lat. Tak więc jest to dość łatwe dla nowej osoby, aby uzyskać mylić się w zrozumieniu i rozróżnianiu wśród frameworków strumieniowych. W tym poście najpierw omówię rodzaje i aspekty przetwarzania strumieniowego w ogóle, a następnie porównam najpopularniejsze frameworki strumieniowe open source: Flink, Spark Streaming, Storm, Kafka Streams. Postaram się wyjaśnić jak one działają (krótko), ich przypadki użycia, mocne strony, ograniczenia, podobieństwa i różnice.

Co to jest Streaming/Stream Processing :
Najbardziej elegancka definicja jaką znalazłem to: rodzaj silnika przetwarzania danych, który został zaprojektowany z myślą o nieskończonych zbiorach danych. Nic więcej.

W odróżnieniu od przetwarzania wsadowego, gdzie dane są ograniczone początkiem i końcem zadania, a zadanie kończy się po przetworzeniu tych skończonych danych, Streaming jest przeznaczony do przetwarzania nieograniczonych danych przychodzących w czasie rzeczywistym w sposób ciągły przez dni, miesiące, lata i na zawsze. Jako taka, będąc zawsze przeznaczona do pracy i działania, aplikacja strumieniowa jest trudna do wdrożenia i trudniejsza do utrzymania.

Important Aspects of Stream Processing:

Istnieją pewne ważne cechy i terminy związane z przetwarzaniem strumieniowym, których powinniśmy być świadomi w celu zrozumienia mocnych stron i ograniczeń każdego frameworka strumieniowego :

• Gwarancje dostawy :
  To znaczy, jaka jest gwarancja, że bez względu na wszystko, konkretny przychodzący rekord w silniku strumieniowym zostanie przetworzony. Może to być Atleast-once (będzie przetwarzany co najmniej jeden raz nawet w przypadku niepowodzeń) , Atmost-once (może nie być przetwarzany w przypadku niepowodzeń) lub Exactly-once (będzie przetwarzany jeden i dokładnie jeden raz nawet w przypadku niepowodzeń) . Oczywiście Exactly-once jest pożądane, ale jest trudne do osiągnięcia w systemach rozproszonych i pochodzi w kompromisów z wydajności.
• Fault Tolerance :
  W przypadku awarii, takich jak awarie węzłów, awarii sieci, itp, ramy powinny być w stanie odzyskać i powinien rozpocząć przetwarzanie ponownie od punktu, w którym opuścił. Osiąga się to poprzez checkpointing stanu strumienia do jakiegoś trwałego magazynu od czasu do czasu. np. checkpointing kafka offsets do zookeeper po uzyskaniu rekordu z Kafki i przetworzeniu go.
• Zarządzanie stanem :
  W przypadku stanowych wymagań przetwarzania, gdzie musimy utrzymać jakiś stan (np.g. counts of each distinct word seen in records), framework powinien być w stanie zapewnić jakiś mechanizm do zachowania i aktualizacji informacji o stanie.
• Wydajność :
  To obejmuje latencję (jak szybko rekord może być przetworzony), przepustowość (rekordy przetwarzane/sekundę) i skalowalność. Latencja powinna być tak minimalna, jak to tylko możliwe, podczas gdy przepustowość powinna być tak duża, jak to tylko możliwe. Trudno jest uzyskać obie te wartości w tym samym czasie.
• Funkcje zaawansowane : Event Time Processing, Watermarks, Windowing
  Te funkcje są potrzebne, jeśli wymagania dotyczące przetwarzania strumienia są złożone. Na przykład, przetwarzanie rekordów w oparciu o czas, w którym zostały wygenerowane w źródle (przetwarzanie czasu zdarzenia). Aby wiedzieć więcej w szczegółach, proszę przeczytać te obowiązkowe posty gościa Google Tyler Akidau: część1 i część2.
• Dojrzałość :
  Ważne z punktu widzenia adopcji, miło jest, jeśli framework jest już sprawdzony i przetestowany w skali przez duże firmy. Bardziej prawdopodobne jest uzyskanie dobrego wsparcia społeczności i pomocy na stackoverflow.

Dwa typy przetwarzania strumienia:

Teraz będąc świadomym terminów, które właśnie omówiliśmy, łatwo jest teraz zrozumieć, że istnieją 2 podejścia do wdrożenia frameworka Streaming:

Natywny Streaming :
Znany również jako Natywny Streaming. Oznacza to, że każdy przychodzący rekord jest przetwarzany natychmiast po jego nadejściu, bez czekania na inne. Istnieją pewne stale działające procesy (które nazywamy operatorami/zadaniami/śrubami w zależności od frameworka), które działają wiecznie i każdy rekord przechodzi przez te procesy, aby zostać przetworzony. Przykłady : Storm, Flink, Kafka Streams, Samza.

Oba podejścia mają pewne zalety i wady.
Natywny Streaming czuje się naturalnie, ponieważ każdy rekord jest przetwarzany tak szybko, jak tylko nadejdzie, pozwalając frameworkowi osiągnąć minimalne możliwe opóźnienie. Ale oznacza to również, że trudno jest osiągnąć odporność na błędy bez uszczerbku dla przepustowości, ponieważ dla każdego rekordu musimy śledzić i sprawdzać punkt kontrolny po jego przetworzeniu. Również zarządzanie stanem jest łatwe, ponieważ istnieją długo działające procesy, które mogą łatwo utrzymać wymagany stan.

Micro-batching , z drugiej strony, jest zupełnie odwrotnie. Odporność na błędy przychodzi za darmo, ponieważ jest to zasadniczo partia i przepustowość jest również wysoka, ponieważ przetwarzanie i checkpointing zostanie wykonane w jednym strzale dla grupy rekordów. Ale będzie to kosztem opóźnień i nie będzie się czuć jak naturalny streaming. Również efektywne zarządzanie stanem będzie wyzwaniem do utrzymania.

Streaming Frameworks One By One:

Storm :
Storm jest hadoopem świata streamingu. Jest to najstarszy open source’owy framework streamingowy i jeden z najbardziej dojrzałych i niezawodnych. Jest to prawdziwy streaming i jest dobry dla prostych przypadków użycia opartych na zdarzeniach. Szczegółami na temat Storma podzieliłem się w tych postach: część1 i część2.

Zalety:

• Bardzo niska latencja,true streaming, dojrzała i wysoka przepustowość
• Doskonały do nieskomplikowanych przypadków użycia opartych na strumieniowaniu

Wady

• Brak zarządzania stanem
• Brak zaawansowanych funkcji takich jak przetwarzanie czasu zdarzeń, agregacja, windowing, sesje, znaki wodne, itp
• Gwarancja Atleast-once

Spark Streaming :

Spark wyłonił się jako prawdziwy następca hadoopa w przetwarzaniu wsadowym i pierwszy framework w pełni wspierający architekturę Lambda (w której zaimplementowano zarówno przetwarzanie wsadowe, jak i strumieniowe; przetwarzanie wsadowe dla poprawności, strumieniowe dla szybkości). Jest ogromnie popularny, dojrzały i szeroko zaadoptowany. Spark Streaming jest dostarczany za darmo ze Sparkiem i używa mikropatchingu do przesyłania strumieniowego. Przed wydaniem 2.0, Spark Streaming miał pewne poważne ograniczenia wydajności, ale z nowym wydaniem 2.0+ , jest nazywany strukturalnym streamingiem i jest wyposażony w wiele dobrych funkcji, takich jak niestandardowe zarządzanie pamięcią (jak flink) zwane wolframem, znaki wodne, wsparcie dla przetwarzania czasu zdarzenia, itp. Również Structured Streaming jest znacznie bardziej abstrakcyjny i istnieje możliwość przełączania się między mikropatchingiem a trybem ciągłego strumieniowania w wydaniu 2.3.0. Tryb Continuous Streaming obiecuje dać sub latency jak Storm i Flink, ale wciąż jest w fazie niemowlęcej z wieloma ograniczeniami w działaniu.

Zalety:

• Wspiera architekturę Lambda, przychodzi za darmo ze Sparkiem
• Wysoka przepustowość, dobre dla wielu przypadków użycia, w których sub-latency nie jest wymagane
• Odporność na błędy domyślnie ze względu na naturę mikropatch
• Proste w użyciu interfejsy API wyższego poziomu
• Duża społeczność i agresywne ulepszenia
• Exactly Once

Wady

• Nie prawdziwy streaming, nie nadaje się do wymagań niskiej latencji
• Zbyt wiele parametrów do dostrojenia. Trudno uzyskać to dobrze. Napisałem post o moich osobistych doświadczeniach podczas dostrajania Spark Streaming
• Stateless by nature
• Lags behind Flink in many advanced features

Flink :

Flink jest również z podobnego akademickiego tła jak Spark. Podczas gdy Spark pochodzi z UC Berkley, Flink pochodzi z berlińskiego TU University. Podobnie jak Spark również wspiera architekturę Lambda. Ale implementacja jest zupełnie odwrotna niż w przypadku Sparka. Podczas gdy Spark jest zasadniczo wsadowy, a Spark streaming jest mikropatchingiem i specjalnym przypadkiem Spark Batch, Flink jest zasadniczo prawdziwym silnikiem streamingowym traktującym wsad jako specjalny przypadek streamingu z ograniczonymi danymi. Chociaż API w obu frameworkach są podobne, ale nie mają one żadnego podobieństwa w implementacjach. W Flink, każda funkcja jak map,filter,reduce,etc jest zaimplementowana jako długo działający operator (podobny do Bolt w Storm)

Flink wygląda jak prawdziwy następca Storma, tak jak Spark zastąpił hadoop w batchu.

Zalety:

• Lider innowacji w krajobrazie open source Streaming
• Pierwszy True streaming framework ze wszystkimi zaawansowanymi funkcjami, takimi jak przetwarzanie czasu zdarzeń, znaki wodne, itp
• Niska latencja z wysoką przepustowością, konfigurowalny zgodnie z wymaganiami
• Auto-adjusting, nie za dużo parametrów do dostrojenia
• Dokładnie raz
• Powszechnie akceptowany przez duże firmy w skali jak Uber,Alibaba.

Wady

• Nieco późno w grze, początkowo brakowało adopcji
• Społeczność nie jest tak duża jak Spark, ale rośnie teraz w szybkim tempie
• Brak znanej adopcji Flink Batch jak na razie, popularny tylko do streamingu.

Kafka Streams :

Kafka Streams , w przeciwieństwie do innych frameworków strumieniowych, jest lekką biblioteką. Jest przydatna do strumieniowania danych z Kafki, wykonywania transformacji, a następnie wysyłania z powrotem do Kafki. Możemy ją rozumieć jako bibliotekę podobną do Java Executor Service Thread pool, ale z wbudowanym wsparciem dla Kafki. Może być dobrze zintegrowany z każdą aplikacją i będzie działał po wyjęciu z pudełka.

Dzięki swojej lekkiej naturze, może być używany w architekturze typu microservices. Nie ma meczu w zakresie wydajności z Flink, ale również nie potrzebuje oddzielnego klastra do uruchomienia, jest bardzo poręczny i łatwy do wdrożenia i rozpoczęcia pracy. Wewnętrznie używa grupy Kafka Consumer i działa na filozofii dziennika Kafka.
Ten post dokładnie wyjaśnia przypadki użycia Kafka Streams vs Flink Streaming.

Jedną z głównych zalet Kafka Streams jest to, że jego przetwarzanie jest Dokładnie Raz koniec do końca. Jest to możliwe, ponieważ zarówno źródło, jak i miejsce docelowe, oba są Kafka i od wersji Kafka 0.11 wydanej około czerwca 2017, Exactly once jest obsługiwany. Aby włączyć tę funkcję, musimy tylko włączyć flagę i będzie działać po wyjęciu z pudełka. Więcej szczegółów udostępnionych tutaj i tutaj.

Zalety:

• Bardzo lekka biblioteka, dobra dla mikroserwisów,aplikacji IOT
• Nie potrzebuje dedykowanego klastra
• Odziedziczy wszystkie dobre cechy Kafki
• Obsługuje Stream joins, wewnętrznie używa rocksDb do utrzymywania stanu.
• Exactly Once ( Kafka 0.11 onwards).

Wady

• Nieznacznie sprzężony z Kafką, nie może być używany bez Kafki w obrazie
• Całkiem nowy w fazie niemowlęcej, jeszcze do przetestowania w dużych firmach
• Nie do ciężkiej pracy jak Spark Streaming,Flink.

Samza :

Obejmiemy Samzę w skrócie. Samza z odległości 100 stóp wygląda jak podobna do Kafka Streams w podejściu. Jest wiele podobieństw. Oba te frameworki zostały stworzone przez tych samych programistów, którzy wdrożyli Samzę w LinkedIn, a następnie założyli Confluent, gdzie napisali Kafka Streams. Obie te technologie są ściśle powiązane z Kafką, pobierają surowe dane z Kafki, a następnie odsyłają przetworzone dane z powrotem do Kafki. Używają tej samej filozofii Kafka Log. Samza jest swego rodzaju skalowaną wersją Kafka Streams. Podczas gdy Kafka Streams jest biblioteką przeznaczoną dla mikroserwisów, Samza jest pełnoprawnym przetwarzaniem klastrowym, które działa na Yarn.
Zalety :

• Bardzo dobre w utrzymywaniu dużych stanów informacji (dobre dla przypadków użycia łączenia strumieni) przy użyciu rocksDb i kafka log.
• Fault Tolerant and High performant using Kafka properties
• Jedna z opcji do rozważenia, jeśli już używasz Yarn i Kafka w potoku przetwarzania.
• Dobry obywatel Yarn
• Niska latencja , Wysoka przepustowość , dojrzałe i przetestowane w skali

Wady :

• Ścisłe sprzężenie z Kafką i Yarn. Niełatwy w użyciu, jeśli któryś z nich nie jest w twoim potoku przetwarzania.
• Gwarancja przetwarzania Atleast-Once. Nie jestem pewien czy obsługuje dokładnie jeden raz teraz jak Kafka Streams po Kafka 0.11
• Brak zaawansowanych funkcji strumieniowych jak Watermarks, Sessions, triggers, etc

Porównanie Streaming Frameworks:

Możemy porównywać technologie tylko z podobnymi ofertami. Podczas gdy Storm, Kafka Streams i Samza wyglądają obecnie na użyteczne dla prostszych przypadków użycia, prawdziwa rywalizacja toczy się pomiędzy ciężkimi maszynami z najnowszymi funkcjami: Spark vs Flink

Gdy mówimy o porównaniu, generalnie mamy tendencję do pytania: Pokaż mi liczby 🙂

Benchmarking jest dobrym sposobem na porównanie tylko wtedy, gdy został wykonany przez osoby trzecie.

Na przykład jeden ze starych benchmarków był taki.
Ale to było w czasach przed Spark Streaming 2.0, kiedy miał ograniczenia z RDD i projekt wolfram nie był na miejscu.
Teraz z Structured Streaming post 2.0 release , Spark Streaming próbuje nadrobić wiele zaległości i wydaje się, że będzie trudna walka przed nami.

Ostatnio benchmarking stał się rodzajem otwartej walki kotów między Spark i Flink.

Spark zrobił ostatnio porównanie benchmarków z Flinkiem, na co deweloperzy Flinka odpowiedzieli innym benchmarkiem, po którym chłopaki ze Sparka zredagowali post.

W dzisiejszych czasach lepiej nie wierzyć benchmarkom, ponieważ nawet mały tweaking może całkowicie zmienić liczby. Nic nie jest lepsze niż próbowanie i testowanie siebie przed podjęciem decyzji.
Jak na dzień dzisiejszy, jest całkiem oczywiste, że Flink jest liderem w przestrzeni Streaming Analytics, z większością pożądanych aspektów, takich jak dokładnie raz, przepustowość, opóźnienia, zarządzanie stanem, odporność na błędy, zaawansowane funkcje, itp.

Były one możliwe dzięki niektórym prawdziwym innowacjom Flink, takim jak lekkie migawki i niestandardowe zarządzanie pamięcią poza stertą.
Jedną ważną kwestią związaną z Flink była dojrzałość i poziom adopcji do pewnego czasu, ale teraz firmy takie jak Uber, Alibaba, CapitalOne używają Flink streaming na masową skalę poświadczając potencjał Flink Streaming.

Ostatnio, Uber otworzył źródło ich najnowszego Streaming analytics framework o nazwie AthenaX, który jest zbudowany na szczycie silnika Flink. W tym poście omówiono, w jaki sposób przenieśli swoją analitykę strumieniową z STorm do Apache Samza, a teraz do Flink.

Jednym z ważnych punktów do odnotowania, jeśli już zauważyłeś, jest to, że wszystkie natywne frameworki strumieniowe, takie jak Flink, Kafka Streams, Samza, które wspierają zarządzanie stanem, wykorzystują wewnętrznie RocksDb. RocksDb jest unikalny w sensie utrzymywania trwałego stanu lokalnie na każdym węźle i jest wysoce wydajny. Stał się on kluczową częścią nowych systemów strumieniowych. Podzieliłem się szczegółowymi informacjami na temat RocksDb w jednym z poprzednich postów.

Jak wybrać najlepszy framework streamingowy :

To jest najważniejsza część. I szczera odpowiedź brzmi: to zależy 🙂
Ważne jest, aby pamiętać, że żaden pojedynczy framework przetwarzania nie może być srebrną kulą dla każdego przypadku użycia. Każdy framework ma pewne mocne strony i pewne ograniczenia również. Mimo to, z pewnym doświadczeniem, podzielę się kilkoma wskazówkami, które pomogą w podjęciu decyzji:

1. Zależy od przypadków użycia:
   Jeśli przypadek użycia jest prosty, nie ma potrzeby, aby przejść do najnowszego i największego frameworka, jeśli jest on skomplikowany do nauczenia się i wdrożenia. Wiele zależy od tego, ile jesteśmy gotowi zainwestować za to, ile chcemy w zamian. Na przykład, jeśli jest to prosty IOT rodzaj systemu alarmowego opartego na zdarzeniach, Storm lub Kafka Streams jest całkowicie w porządku do pracy.
2. Rozważania na przyszłość:
   W tym samym czasie, musimy również świadomie zastanowić się nad tym, jakie będą możliwe przyszłe przypadki użycia? Czy jest możliwe, że w przyszłości pojawi się zapotrzebowanie na zaawansowane funkcje, takie jak przetwarzanie czasu zdarzeń, agregacja, łączenie strumieni itp. Jeśli odpowiedź brzmi tak lub może być, to lepiej jest iść naprzód z zaawansowanymi frameworkami strumieniowymi, takimi jak Spark Streaming lub Flink. Raz zainwestowane i wdrożone w jednej technologii, jego trudne i ogromne koszty, aby zmienić później. Dla przykładu, w poprzedniej firmie mieliśmy działający od 2 lat potok Storm i działał on bez zarzutu, dopóki nie pojawił się wymóg unifikacji przychodzących zdarzeń i raportowania tylko unikalnych zdarzeń. Wymagało to zarządzania stanem, które nie jest z natury wspierane przez Storm. Co prawda zaimplementowałem to używając hashmap opartych na czasie w pamięci, ale było to ograniczone tym, że stan zniknie przy ponownym uruchomieniu. Ponadto, powodowało to problemy podczas takich zmian, którymi podzieliłem się w jednym z poprzednich postów. Chodzi mi o to, że jeśli spróbujemy zaimplementować coś na własną rękę, co nie jest wyraźnie zapewnione przez framework, jesteśmy zobowiązani do trafienia w nieznane problemy.
3. Istniejący stos technologiczny :
   Jeszcze jednym ważnym punktem jest rozważenie istniejącego stosu technologicznego. Jeśli istniejący stos ma Kafkę w miejscu od końca do końca, to Kafka Streams lub Samza mogą być łatwiejsze do dopasowania. Podobnie, jeśli potok przetwarzania jest oparty na architekturze Lambda i Spark Batch lub Flink Batch jest już na miejscu, wtedy ma sens rozważenie Spark Streaming lub Flink Streaming. Na przykład, w moim jednym z poprzednich projektów miałem już Spark Batch w rurociągu i tak, gdy wymóg strumieniowania przyszedł, było dość łatwo wybrać Spark Streaming, który wymagał prawie tego samego zestawu umiejętności i bazy kodu.

W skrócie, Jeśli rozumiemy mocne strony i ograniczenia frameworków wraz z naszymi przypadkami użycia dobrze, to łatwiej jest wybrać lub przynajmniej filtrowanie w dół dostępnych opcji. Wreszcie zawsze dobrze jest mieć POC po wybraniu kilku opcji. Każdy ma przecież inne kubki smakowe.

Podsumowanie :

Przestrzeń streamingowa Apache ewoluuje w tak szybkim tempie, że ten post może być przestarzały pod względem informacji za kilka lat. Obecnie Spark i Flink są ciężkimi ciężarami prowadzącymi z przodu pod względem rozwoju, ale jakiś nowy dzieciak może wciąż przyjść i dołączyć do wyścigu. Apache Apex jest jednym z nich. Istnieją również własnościowe rozwiązania streamingowe, których nie uwzględniłem, jak Google Dataflow. Moim celem tego postu było pomóc komuś, kto jest nowy w strumieniowaniu, aby zrozumieć, z minimalną ilością żargonu, niektóre podstawowe pojęcia Streaming wraz z mocnymi stronami, ograniczeniami i przypadkami użycia popularnych frameworków strumieniowych open source. Mam nadzieję, że ten post był w jakiś sposób pomocny.

Szczęśliwy Streaming!!

Możesz śledzić mnie na Linkedin i Quora

.