Storm or Spark: Wybierz swoją broń w czasie rzeczywistym

Idea analizy biznesowej w czasie rzeczywistym istnieje już od jakiegoś czasu (zobacz stronę Wikipedii na ten temat, która rozpoczęła się w 2006 roku). Ale chociaż ludzie rozmawiali o tym pomyśle od lat, nie widziałem, aby wiele przedsiębiorstw faktycznie przyjęło tę wizję, a tym bardziej zdało sobie sprawę z korzyści, jakie ona umożliwia.

Przynajmniej jednym z powodów był brak narzędzi do wdrażania BI i analityki w czasie rzeczywistym. Tradycyjne środowiska hurtowni danych były mocno zorientowane na operacje wsadowe z ekstremalnie dużymi opóźnieniami, były niewiarygodnie drogie lub jedno i drugie.

Aby to zmienić, pojawiło się wiele potężnych, łatwych w użyciu platform open source. Dwa z najbardziej godnych uwagi to Apache Storm i Apache Spark, które oferują możliwości przetwarzania w czasie rzeczywistym znacznie szerszemu gronu potencjalnych użytkowników. Oba są projektami w ramach Apache Software Foundation i chociaż oba narzędzia zapewniają nakładające się możliwości, każde z nich ma odrębne cechy i role do odegrania.

Storm: The Hadoop przetwarzania w czasie rzeczywistym

Storm, rozproszona platforma obliczeniowa do przetwarzania strumieni zdarzeń, rozpoczęła się jako projekt BackType, firmy zajmującej się analizą marketingową kupioną przez Twittera w 2011 roku. Wkrótce Twitter udostępnił projekt i umieścił go na GitHub, ale Storm ostatecznie przeniósł się do Apache Incubator i stał się projektem najwyższego poziomu Apache we wrześniu 2014.

Storm jest czasami nazywany Hadoopem przetwarzania w czasie rzeczywistym. Dokumentacja Storm wydaje się zgadzać: „Storm ułatwia niezawodne przetwarzanie nieograniczonych strumieni danych, robiąc w czasie rzeczywistym to samo, co Hadoop robił w przypadku przetwarzania wsadowego”.

Aby sprostać temu wyzwaniu, Storm został zaprojektowany z myślą o ogromnej skalowalności, obsługuje odporność na awarie dzięki podejściu do procesów „szybkie awarie i automatyczny restart” i oferuje silną gwarancję, że każda krotka zostanie przetworzona. Storm domyślnie zapewnia gwarancję „co najmniej raz” dla wiadomości, ale oferuje również możliwość zaimplementowania przetwarzania „dokładnie raz”.

Storm jest napisany głównie w Clojure i jest przeznaczony do obsługi „wylewek” okablowania (pomyśl o strumieniach wejściowych) i „śrub” (moduły przetwarzania i wyjścia) razem jako skierowany graf acykliczny (DAG) zwany topologią. Topologie Storm działają w klastrach, a harmonogram Storm dystrybuuje pracę do węzłów w obrębie klastra, w oparciu o konfigurację topologii.

Możesz myśleć o topologiach jako z grubsza analogicznych do zadania MapReduce na Hadoop, z wyjątkiem tego, że biorąc pod uwagę fakt, że Storm koncentruje się na przetwarzaniu strumieniowym w czasie rzeczywistym, topologie domyślnie działają w nieskończoność lub do momentu ręcznego zakończenia. Po uruchomieniu topologii wylewki wprowadzają dane do systemu i przekazują je do śrub (które z kolei mogą przekazywać dane kolejnym śrubom), gdzie wykonywana jest główna praca obliczeniowa. W miarę postępu przetwarzania jedna lub więcej śrub może zapisywać dane do bazy danych lub systemu plików, wysyłać wiadomość do innego systemu zewnętrznego lub w inny sposób udostępniać wyniki obliczeń użytkownikom.

Jedną z mocnych stron ekosystemu Storm jest bogata gama dostępnych wylewek wyspecjalizowanych do odbierania danych ze wszystkich typów źródeł. Chociaż być może będziesz musiał napisać niestandardowe wylewki dla wysoce wyspecjalizowanych aplikacji, istnieje duża szansa, że ​​możesz znaleźć istniejący dziobek dla niewiarygodnie dużej różnorodności źródeł - od interfejsu API przesyłania strumieniowego na Twitterze do Apache Kafka, brokerów JMS i wszystkiego pomiędzy.

Istnieją adaptery, które ułatwiają integrację z systemami plików HDFS, co oznacza, że ​​Storm może w razie potrzeby łatwo współpracować z Hadoop. Kolejną zaletą Storm jest wsparcie dla programowania wielojęzycznego. Chociaż sam Storm jest oparty na Clojure i działa na JVM, wylewki i śruby mogą być napisane w prawie każdym języku, w tym w językach innych niż JVM, które wykorzystują protokół do komunikacji między komponentami za pomocą JSON przez stdin / stdout.

Krótko mówiąc, Storm to bardzo skalowalny, szybki, odporny na błędy system open source do obliczeń rozproszonych, ze szczególnym naciskiem na przetwarzanie strumieniowe. Storm wyróżnia się przetwarzaniem zdarzeń i obliczeniami przyrostowymi, obliczając wskaźniki kroczące w czasie rzeczywistym na podstawie strumieni danych. Chociaż Storm zapewnia również prymitywy umożliwiające generyczne rozproszone RPC i teoretycznie może być używany do składania prawie każdego rozproszonego zadania obliczeniowego, jego siłą jest oczywiście przetwarzanie strumienia zdarzeń.

Spark: rozproszone przetwarzanie dla wszystkich

Spark, kolejny projekt przystosowany do obliczeń rozproszonych w czasie rzeczywistym, zaczynał jako projekt AMPLab na Uniwersytecie Kalifornijskim w Berkeley, zanim dołączył do Apache Incubator i ostatecznie ukończył jako projekt najwyższego poziomu w lutym 2014 r. Podobnie jak Storm, Spark wspiera stream zorientowane na przetwarzanie, ale jest to raczej platforma przetwarzania rozproszonego ogólnego przeznaczenia.

W związku z tym Spark może być postrzegany jako potencjalny zamiennik funkcji MapReduce Hadoop, podczas gdy Spark może działać na istniejącym klastrze Hadoop, polegając na YARN do planowania zasobów. Oprócz Hadoop YARN, Spark może nakładać warstwy na Mesos w celu planowania lub uruchamiać jako samodzielny klaster za pomocą wbudowanego harmonogramu. Zwróć uwagę, że jeśli Spark nie jest używany z Hadoop, pewien typ sieci / rozproszonego systemu plików (NFS, AFS itd.) Jest nadal wymagany, jeśli działa w klastrze, więc każdy węzeł będzie miał dostęp do bazowych danych.

Spark jest napisany w Scali i, podobnie jak Storm, obsługuje programowanie wielojęzyczne, chociaż Spark zapewnia określoną obsługę interfejsu API tylko dla Scala, Java i Python. Spark nie ma specyficznej abstrakcji „dziobka”, ale zawiera adaptery do pracy z danymi przechowywanymi w wielu różnych źródłach, w tym w plikach HDFS, Cassandra, HBase i S3.

Tam, gdzie Spark świeci, jest wsparcie dla wielu paradygmatów przetwarzania i bibliotek pomocniczych. Tak, Spark obsługuje model przesyłania strumieniowego, ale tę obsługę zapewnia tylko jeden z kilku modułów Spark, w tym specjalnie zbudowane moduły dostępu SQL, operacji na wykresach i uczenia maszynowego, a także przetwarzania strumieniowego.

Spark zapewnia również niezwykle poręczną interaktywną powłokę, która umożliwia szybkie i łatwe prototypowanie i eksploracyjną analizę danych w czasie rzeczywistym przy użyciu interfejsów API Scala lub Python. Pracując w powłoce interaktywnej, szybko zauważysz kolejną istotną różnicę między Spark i Storm: Spark ma bardziej „funkcjonalny” smak, w którym praca z interfejsem API jest bardziej napędzana przez łączenie kolejnych wywołań metod w celu wywołania prymitywnych operacji - w przeciwieństwie do Model Storm, który zwykle jest napędzany przez tworzenie klas i implementowanie interfejsów. Żadne z podejść nie jest lepsze ani gorsze, ale preferowany styl może wpłynąć na decyzję o tym, który system będzie lepiej dostosowany do Twoich potrzeb.

Podobnie jak Storm, Spark został zaprojektowany z myślą o ogromnej skalowalności, a zespół Spark udokumentował użytkowników systemu obsługującego klastry produkcyjne z tysiącami węzłów. Ponadto Spark wygrał niedawny konkurs Daytona GraySort w 2014 r., Uzyskując najlepszy czas na obciążenie pracą polegającą na sortowaniu 100 TB danych. Zespół Spark dokumentuje również operacje Spark ETL z obciążeniami produkcyjnymi w zakresie wielu petabajtów.

Spark to szybka, skalowalna i elastyczna platforma przetwarzania rozproszonego typu open source, kompatybilna z Hadoop i Mesos, która obsługuje kilka modeli obliczeniowych, w tym przesyłanie strumieniowe, operacje oparte na wykresach, dostęp SQL i rozproszone uczenie maszynowe. Udokumentowano, że Spark jest wyjątkowo dobrze skalowalny i, podobnie jak Storm, jest doskonałą platformą do budowania systemu analizy i analizy biznesowej w czasie rzeczywistym.

Podejmowanie decyzji

Jak wybierasz między Storm a Spark?

Jeśli twoje wymagania koncentrują się głównie na przetwarzaniu strumieniowym i przetwarzaniu w stylu CEP i rozpoczynasz projekt od podstaw z klastrem specjalnie zbudowanym dla tego projektu, prawdopodobnie wolałbym Storm - zwłaszcza gdy dostępne są istniejące wylewki Storm, które pasują do twoich wymagań integracyjnych . Nie jest to bynajmniej mocna i szybka zasada, ale takie czynniki przynajmniej sugerują rozpoczęcie od Storm.

Z drugiej strony, jeśli korzystasz z istniejącego klastra Hadoop lub Mesos i / lub jeśli Twoje potrzeby przetwarzania wiążą się ze znacznymi wymaganiami dotyczącymi przetwarzania wykresów, dostępu SQL lub przetwarzania wsadowego, możesz najpierw przyjrzeć się platformie Spark.

Kolejnym czynnikiem, który należy wziąć pod uwagę, jest wielojęzyczna obsługa obu systemów. Na przykład, jeśli chcesz wykorzystać kod napisany w języku R lub innym języku, który nie jest natywnie obsługiwany przez platformę Spark, Storm ma tę zaletę, że obsługuje szersze języki. Z tego samego powodu, jeśli musisz mieć interaktywną powłokę do eksploracji danych za pomocą wywołań API, Spark oferuje funkcję, której Storm nie ma.

Na koniec prawdopodobnie będziesz chciał przeprowadzić szczegółową analizę obu platform przed podjęciem ostatecznej decyzji. Zalecam użycie obu platform do zbudowania małego dowodu słuszności koncepcji - a następnie przeprowadź własne testy porównawcze z obciążeniem, które możliwie dokładnie odzwierciedla przewidywane obciążenia, zanim w pełni się na nie zdecydujesz.

Oczywiście nie musisz podejmować decyzji ani / lub. W zależności od obciążeń, infrastruktury i wymagań może się okazać, że idealnym rozwiązaniem jest połączenie Storm i Spark - wraz z innymi narzędziami, takimi jak Kafka, Hadoop, Flume i tak dalej. Na tym polega piękno open source.

Niezależnie od wybranej ścieżki narzędzia te pokazują, że gra BI w czasie rzeczywistym uległa zmianie. Potężne opcje, które kiedyś były dostępne tylko dla nielicznych elit, są teraz w zasięgu większości, jeśli nie wszystkich, średnich i dużych organizacji. Skorzystaj z nich.