Tradycyjni brokerzy wiadomości i dane strumieniowe

14

Według strony Kafka :

Kakfa służy do tworzenia potoków danych w czasie rzeczywistym i aplikacji do przesyłania strumieniowego ”.

Przeszukując Internet daleko i szeroko, znalazłem następującą ogólnie przyjętą definicję tego, czym jest „ strumień danych ”:

  • Strumień danych to dane, które przepływają w sposób ciągły od źródła do miejsca docelowego przez sieć; i
  • Strumień danych nie ma charakteru atomowego, co oznacza, że ​​jakakolwiek część przepływającego strumienia danych jest znacząca i przetwarzalna, w przeciwieństwie do pliku, którego bajty nic nie znaczą, chyba że masz je wszystkie; i
  • Strumieniowe przesyłanie danych można rozpocząć / zatrzymać w dowolnym momencie; i
  • Konsumenci mogą dowolnie dołączać i odłączać się od strumienia danych i przetwarzać tylko te części, które chcą

Teraz, jeśli coś, co powiedziałem powyżej, jest nieprawidłowe, niekompletne lub całkowicie błędne, zacznij od poprawienia mnie! Zakładając, że jestem mniej więcej na dobrej drodze, to ...

Teraz, gdy rozumiem, co to jest „przesyłanie strumieniowe danych”, rozumiem, co oznaczają Kafka i Kinesis, gdy rozliczają się jako oprogramowanie pośredniczące do przetwarzania / pośrednictwa dla aplikacji z przesyłaniem strumieniowym danych. Ale wzbudziło moje zainteresowania: czy można / należy „przesyłać strumieniowo oprogramowanie pośrednie”, takie jak Kafka lub Kinesis, do transmisji danych nieprzesyłanych strumieniowo, takich jak tradycyjni brokerzy wiadomości? I odwrotnie: czy do przesyłania strumieniowego danych można używać tradycyjnych MQ, takich jak RabbitMQ, ActiveMQ, Apollo itp.?

Weźmy przykład, w którym aplikacja będzie wysyłać ciągłą zaporę dla komunikatów JSON, które muszą być przetwarzane, a przetwarzanie jest dość złożone (sprawdzanie poprawności, przekształcanie danych, filtrowanie, agregowanie itp.):

  • Przypadek 1: Każda wiadomość zawiera każdą klatkę filmu; to jest jeden komunikat JSON na ramkę wideo zawierający dane ramki i niektóre obsługiwane metadane
  • Przypadek nr 2: wiadomości to dane szeregów czasowych, być może czyjeś bicie serca w funkcji czasu. Więc wiadomość nr 1 jest wysyłana reprezentując moje bicie serca przy t = 1, wiadomość nr 2 zawiera moje bicie serca przy t = 2 itd.
  • Przypadek nr 3: Dane są całkowicie rozbieżne i niezwiązane z czasem ani w ramach „strumienia danych”. Być może zdarzenia audytu / bezpieczeństwa, które są uruchamiane, gdy setki użytkowników poruszają się po aplikacji, klikając przyciski i podejmując działania

W oparciu o sposób naliczania opłat za Kafkę / Kinesis i moje rozumienie, czym są „dane przesyłane strumieniowo”, wydają się oczywistymi kandydatami na przypadki nr 1 (ciągłe dane wideo) i nr 2 (ciągłe dane szeregów czasowych). Nie widzę jednak żadnego powodu, dla którego tradycyjny broker komunikatów, taki jak RabbitMQ, nie byłby w stanie skutecznie obsłużyć obu tych danych wejściowych.

W przypadku nr 3 otrzymaliśmy tylko zdarzenie, które miało miejsce i musimy przetworzyć reakcję na to zdarzenie. Tak więc dla mnie przemawia to za potrzebą tradycyjnego brokera, takiego jak RabbitMQ. Ale nie ma również powodu, dla którego Kafka lub Kinesis nie mogliby obsłużyć przetwarzania danych zdarzeń.

Zasadniczo więc chcę ustanowić rubrykę, która mówi: Mam dane X o charakterystyce Y. Do obsługi tego powinienem użyć procesora strumieniowego, takiego jak Kafka / Kinesis. Lub odwrotnie, taki, który pomaga mi ustalić: Mam dane W o charakterystyce Z. Do obsługi tego powinienem użyć tradycyjnego brokera wiadomości.

Pytam więc: jakie czynniki dotyczące danych (lub w inny sposób) pomagają kierować decyzją między procesorem strumieniowym lub brokerem wiadomości, ponieważ oba mogą obsługiwać przesyłanie danych, a oba mogą obsługiwać (nieprzesyłające) dane wiadomości?

smeeb
źródło

Odpowiedzi:

6

Kafka zajmuje się uporządkowanymi dziennikami wiadomości atomowych. Możesz postrzegać to jak pub/subtryb brokerów wiadomości, ale z rygorystycznym porządkowaniem i możliwością odtwarzania lub wyszukiwania wokół strumienia wiadomości w dowolnym momencie w przeszłości, który jest nadal przechowywany na dysku (co może trwać wiecznie).

Smak Kafki polegający na przesyłaniu strumieniowym w przeciwieństwie do zdalnego wywoływania procedur takich jak Thrift lub HTTP oraz przetwarzania wsadowego jak w ekosystemie Hadoop. W przeciwieństwie do RPC, komponenty komunikują się asynchronicznie: mogą upłynąć godziny lub dni między wysłaniem wiadomości a budzeniem się odbiorcy i działaniem na jego podstawie. Może być wielu adresatów w różnych momentach, a może nikt nigdy nie będzie się starał odebrać wiadomości. Wielu producentów mogłoby produkować na ten sam temat bez wiedzy konsumentów. Kafka nie wie, czy jesteś subskrybentem, czy wiadomość została zużyta. Wiadomość jest po prostu zapisywana w dzienniku, gdzie każda zainteresowana strona może ją odczytać.

W przeciwieństwie do przetwarzania wsadowego, interesują Cię pojedyncze wiadomości, a nie tylko gigantyczne kolekcje wiadomości. (Chociaż często zdarza się, że archiwizujesz wiadomości Kafki w plikach Parquet na HDFS i przeszukujesz je jako tabele gałęzi).

Przypadek 1 : Kafka nie zachowuje żadnej szczególnej relacji czasowej między producentem a konsumentem. Nie nadaje się do przesyłania strumieniowego wideo, ponieważ Kafka może spowolnić, przyspieszyć, dopasować się i uruchamiać itp. W przypadku mediów strumieniowych chcemy wymienić ogólną przepustowość w zamian za niskie i, co ważniejsze, stabilne opóźnienie (w przeciwnym razie znany jako niski jitter). Kafka bardzo się stara, aby nigdy nie stracić wiadomości. W przypadku przesyłania strumieniowego wideo zwykle używamy UDP i jesteśmy zadowoleni z upuszczania ramki tu i tam, aby utrzymać działanie wideo. SLA w procesie wspieranym przez Kafka trwa zwykle od sekund do minut, gdy jest zdrowy, od godzin do dni, gdy jest zdrowy. Umowa SLA dotycząca mediów strumieniowych trwa kilkadziesiąt milisekund.

Netflix może używać Kafki do przenoszenia ramek w wewnętrznym systemie, który transkoduje terabajty wideo na godzinę i zapisuje go na dysku, ale nie wysyła ich na ekran.

Przypadek 2 : Oczywiście. Używamy Kafki w ten sposób u mojego pracodawcy.

Przypadek 3 : Możesz użyć Kafki do tego rodzaju rzeczy, a my tak, ale płacisz za niepotrzebne koszty ogólne, aby zachować porządek. Ponieważ nie zależy Ci na porządku, prawdopodobnie możesz wycisnąć więcej wydajności z innego systemu. Jeśli jednak Twoja firma już utrzymuje klaster Kafka, prawdopodobnie lepiej go użyć ponownie niż przejąć obowiązki związane z konserwacją innego systemu przesyłania wiadomości.

closeparen
źródło
1
Dzięki @closeparen (+1) - Dostaję większość tego, co mówisz, z jednym wielkim wyjątkiem. W twoim akapicie rozpoczynającym się od zdania „ Smak Kafki do streamowania stoi w opozycji… ”, jestem skłonny myśleć, że mógłbym zastąpić większość wystąpień słowa „Kafka” słowem „RabbitMQ”, a zdanie byłoby prawdziwe. W przypadku RabbitMQ: producenci mogą wysłać wiadomość, a konsument ściągnie ją i przetworzy po kilku godzinach / dniach. Konsumenci mogą dołączać do kolejki w dowolnym momencie, dlatego w RabbitMQ może być wielu różnych odbiorców w różnych momentach.
smeeb,
1
Pomyśl o Kafce jak o silniku bazy danych o szczególnej strukturze zorientowanej na logi. Producenci dołączają, konsumenci czytają. Czytanie w żaden sposób nie wpływa na stan Kafki. Konsument może utrzymywać kursor zwiększający, aby tworzyć semantykę identyczną z pub / sub RabbitMQ, i jest to częsty przypadek użycia, ale nie jest to jedyny przypadek użycia.
closeparen
1
Pomyśl o RabbitMQ jak o rozproszonej wersji struktury danych kolejki w pamięci. Gdy coś wyskoczy z kolejki, nie będzie już w kolejce. Pewnie, możesz mieć topologię, w której jest ona replikowana do innych kolejek z korzyścią dla innych konsumentów, ale ogólnie nie byłbyś w stanie powiedzieć „daj mi wiadomość, którą obsłużyłem 500 wiadomości temu” lub „uruchom kolejkę B jako kopię kolejki A, z której wczoraj była kolejka A. ”
closeparen
2
System oparty na Kafce jest wybaczający. Jeśli nie podoba ci się zachowanie programu, możesz wcisnąć zmianę kodu, a następnie przewinąć wprowadzony kod. Możesz zatrzymać konsumenta RabbitMQ bez wpływu na producentów, ale nie będziesz mógł wrócić do przeszłości.
closeparen
1
Ahhh: żarówka: dzięki (+1 za wszystkie 3)! Jest to więc zdecydowanie przekonujący argument dla Kafki: możliwość powrotu do przeszłości. Zakładam, że musi być jakiś górny limit lub obcięcie, prawda? W przeciwnym razie pamięć Kafki zawsze będzie po prostu wspinać się. Nawet jeśli dane zostaną przelane na dysk, pliki, w których przechowywane są dane tematów, bardzo szybko zapełniłyby dysk, tak?
smeeb,
6

Kafka / Kinesis jest modelowany jako strumień. Strumień ma inne właściwości niż wiadomości.

  • Strumienie mają dla nich kontekst. Mają porządek. Możesz zastosować funkcje okna do strumieni. Chociaż każdy element w strumieniu jest znaczący, może być bardziej znaczący z otaczającym go kontekstem
  • Ponieważ strumienie mają kolejność, możesz ich użyć do złożenia pewnych oświadczeń dotyczących semantyki przetwarzania. Np. Apache Trident podobno ma dokładnie taką samą semantykę, gdy korzysta ze strumienia Kafka.
  • Możesz zastosować funkcje do strumieni. Możesz przekształcić strumień, nie zużywając go. Możesz leniwie korzystać ze strumienia. Możesz pominąć części strumienia.
  • Możesz z natury odtwarzać strumienie w Kafce, ale nie możesz (bez dodatkowego oprogramowania) odtwarzać kolejek wiadomości. Jest to przydatne, gdy jeszcze nie wiesz, co chcesz zrobić z danymi. Przydaje się również do treningu AI.

Zasadniczo używaj Kafki do przetwarzania strumieniowego w trybie offline, używaj kolejek komunikatów do komunikatów klient-serwer w czasie rzeczywistym.

Przykładowe przypadki użycia z kluczowego :

Kafka: śledzenie aktywności w witrynie, wskaźniki, agregacja dzienników, przetwarzanie strumieniowe, pozyskiwanie zdarzeń i dzienniki zatwierdzania

RabbitMQ: wiadomości ogólnego przeznaczenia ..., często używane w celu umożliwienia serwerom internetowym szybkiego reagowania na żądania zamiast zmuszania ich do wykonywania procedur obciążających zasoby, podczas gdy użytkownik czeka na wynik. Użyj, gdy potrzebujesz użyć istniejących protokołów, takich jak AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

Czasami może być przydatne użycie obu! Na przykład w Przypadku użycia nr 2, jeśli byłby to strumień danych od twórcy tempa, powiedzmy, kazałbym twórcy tempa przesłać dane pulsu do kolejki komunikatów RabbitMQ (używając fajnego protokołu, takiego jak MQTT), gdzie jest on natychmiast przetwarzany do sprawdź, czy serce źródła wciąż bije. Może to zasilać deskę rozdzielczą i system reagowania awaryjnego. Kolejka wiadomości zdeponowałaby również dane szeregów czasowych w Kafce, abyśmy mogli analizować dane bicia serca w czasie. Na przykład możemy wdrożyć algorytm do wykrywania chorób serca, zauważając trendy w strumieniu bicia serca.

Samuel
źródło
1
Dzięki @Samuel (+1) - to wspaniała odpowiedź i pomaga nieco lepiej umieścić kontekst. Mam kilka pytań do ciebie (jeśli nie masz nic przeciwko), ale wszystkie zależą od jednego wstępnego wyjaśnienia, którego potrzebuję: kiedy powiesz „ Możesz zastosować funkcje do strumieni. Możesz przekształcić strumień bez faktycznego zużywania go ... ”, czy te funkcje / transformacje są wykonywane w Kafce , czy też muszą zostać zużyte najpierw, zanim strumienie zostaną przetworzone przez funkcje / transformacje?
smeeb,
1
Czyli masz KafkaProducer, Kafkai KafkaConsumer. Załóżmy, że KafkaProducermieszka w aplikacji Java, która KafkaConsumerdziała na niektórych aplikacjach / backendach Rubiego. KafkaProducerwysyła Message1do Kafki, która wymaga przekształcenia Function1. Gdzie Function1mieszka kod? Na Kafce (poprawnie) czy w KafkaConsumer(aplikacji Ruby)?
smeeb,
2
Nie można wykonywać funkcji ani przetwarzać w samej Kafce. Apache Spark Streaming i Apache Storm to dwie struktury przetwarzania rozproszonego strumienia, które mogą pobierać z Kafki. Działają poza Kafką i łączą się z nią tak, jakby była bazą danych. Frameworki udostępniają użyteczne funkcje, takie jak dzielenie, agregowanie, okienkowanie itp. Możesz zaimplementować podstawowe funkcje w swoim konsumentu Ruby, ale bardzo polecam jedną z frameworków. spark.apache.org/streaming storm.apache.org/releases/2.0.0-SNAPSHOT/Trident-tutorial.html
Samuel
1
OK, jeszcze raz dziękuję i +1 - byłoby to cholernie niesamowite, gdyby Kafka mógł przetwarzać same strumienie! Tak więc, aby zagrać w adwokata diabła, nie możesz po prostu poprosić konsumenta RabbitMQ o usuwanie wiadomości z kolejki, agregowanie ich na podstawie znacznika czasu (lub innych kryteriów / atrybutów) oraz wykonywanie tego samego okna i przekształcanie funkcji w dane, które Spark Streaming czy Storm?
smeeb,
1
Tak, myślę, że możesz to zrobić za pomocą RabbitMQ, ponieważ RabbitMQ ma gwarancje dotyczące kolejności wiadomości. Możesz nie być w stanie tego zrobić z każdą kolejką komunikatów. Budowa byłaby skomplikowana. Np. Co się stanie, jeśli Twój konsument RabbitMQ, który agreguje, ulega awarii? Dzięki Kafce możesz śledzić, w którym strumieniu przetworzyłeś, abyś mógł uruchomić swojego konsumenta w miejscu, w którym przerwałeś
Samuel