Tradycyjni brokerzy wiadomości i dane strumieniowe

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?

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.

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.