ten post jest publikacją gościnną, której autorem jest Yaroslav Tkachenko, architekt oprogramowania w Activision.
Apache Spark jest jedną z najpopularniejszych i najbardziej wydajnych platform przetwarzania danych na dużą skalę. Został stworzony jako alternatywa dla Hadoop MapReduce framework dla wsadowych obciążeń, ale teraz obsługuje również SQL, uczenie maszynowe i przetwarzanie strumieniowe. Dziś chcę skupić się na strumieniowaniu Spark i pokazać kilka dostępnych opcji przetwarzania strumienia.
przetwarzanie danych strumieniowych jest używane, gdy dane dynamiczne są generowane w sposób ciągły i często występuje w przypadkach użycia dużych zbiorów danych. W większości przypadków dane są przetwarzane w czasie zbliżonym do rzeczywistego, po jednym rekordzie naraz, a informacje uzyskane z danych są również wykorzystywane do dostarczania alertów, renderowania pulpitów nawigacyjnych i modeli uczenia maszynowego feed, które mogą szybko reagować na nowe trendy w danych.
DStreams vs.DataFrames
Spark Streaming poszedł w Alfę z Spark 0.7.0. Opiera się na idei dyskretnych strumieni lub strumieni Dstream. Każdy strumień DStream jest reprezentowany jako sekwencja RDD, więc jest łatwy w użyciu, jeśli korzystasz z niskopoziomowych obciążeń wsadowych opartych na RDD. DStreams przeszedł wiele ulepszeń w tym okresie czasu, ale wciąż były różne wyzwania, przede wszystkim dlatego, że jest to bardzo niskopoziomowe API.
jako rozwiązanie tych problemów, strumieniowanie strumieniowe Spark zostało wprowadzone w Spark 2.0 (i stało się stabilne w 2.2) jako rozszerzenie zbudowane na bazie Spark SQL. Z tego powodu korzysta z kodu Spark SQL i optymalizacji pamięci. Structured Streaming daje również bardzo potężne abstrakcje, takie jak API Dataset/DataFrame, a także SQL. Koniec z bezpośrednim kontaktem z RDD!
zarówno strumieniowanie strumieniowe strumieniowe, jak i strumieniowe za pomocą strumieni Dstream wykorzystują mikro-dozowanie. Największą różnicą jest opóźnienie i gwarancja dostarczania wiadomości: strumieniowanie strumieniowe oferuje dokładnie jedną dostawę z opóźnieniem 100+ milisekund, podczas gdy Streaming z podejściem DStreams gwarantuje tylko co najmniej jedną dostawę, ale może zapewnić opóźnienia milisekundowe.
osobiście wolę strumieniowanie strumieniowe Spark w prostych przypadkach użycia, ale strumieniowanie Spark z DStreams jest naprawdę dobre dla bardziej skomplikowanych topologii ze względu na swoją elastyczność. Dlatego poniżej chcę pokazać, jak używać streamingu z DStreams i streamingu z DataFrames (który jest zwykle używany z strumieniowaniem strukturalnym Spark) do spożywania i przetwarzania danych z Apache Kafka. Użyję Scali, Apache Spark 2.3 i Apache Kafka 2.0.
również dla przykładu będę uruchamiał swoje zadania przy użyciu notebooków Apache Zeppelin dostarczonych przez Qubole. Qubole to platforma danych, z której korzystam na co dzień. Zarządza klastrami Hadoop i Spark, ułatwia uruchamianie zapytań ad hoc Hive i Presto, a także zapewnia zarządzane Notebooki Zeppelin, z których chętnie korzystam. Z Qubole nie muszę się zbytnio zastanawiać nad konfiguracją i strojeniem Spark ’ a i Zeppelina, jest to po prostu dla mnie.
rzeczywisty przypadek użycia, który mam, jest bardzo prosty:
- jakiś rodzaj telemetrii jest napisany do Kafki: małe wiadomości JSON z metadanymi i dowolnymi parami klucz/wartość
- chcę połączyć się z Kafką, skonsumować i deserializować te wiadomości
- następnie zastosować transformacje w razie potrzeby
- zebrać kilka agregacji
- wreszcie interesują mnie anomalie i ogólnie złe dane — ponieważ nie kontroluję producenta, chcę wychwycić takie rzeczy jak NULLs, puste ciągi znaków, może błędne daty i inne wartości za pomocą konkretne formaty itp.
- zadanie powinno działać przez jakiś czas, a następnie automatycznie zakończyć. Zazwyczaj zadania przesyłania strumieniowego Spark działają w sposób ciągły, ale czasami przydatne może być uruchamianie go ad hoc w celu analizy/debugowania (lub jako przykład w moim przypadku, ponieważ tak łatwo jest uruchomić zadanie Spark w notebooku).
Streaming z DStreams
w tym podejściu używamy DStreams, które są po prostu zbiorem RDD.
Streaming z DataFrames
teraz możemy spróbować połączyć Streaming z DataFrames API, aby uzyskać najlepsze z obu światów!
wniosek
które podejście jest lepsze? Ponieważ DStream jest tylko zbiorem RDD, jest zwykle używany do niskopoziomowych transformacji i przetwarzania. Dodanie API DataFrames do tego zapewnia bardzo potężne abstrakcje, takie jak SQL, ale wymaga nieco większej konfiguracji. A jeśli masz prosty przypadek użycia, strumieniowanie strumieniowe Spark może być ogólnie lepszym rozwiązaniem!