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 / Kinesis jest modelowany jako strumień. Strumień ma inne właściwości niż wiadomości.
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 :
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.
źródło
KafkaProducer
,Kafka
iKafkaConsumer
. Załóżmy, żeKafkaProducer
mieszka w aplikacji Java, któraKafkaConsumer
działa na niektórych aplikacjach / backendach Rubiego.KafkaProducer
wysyłaMessage1
do Kafki, która wymaga przekształceniaFunction1
. GdzieFunction1
mieszka kod? Na Kafce (poprawnie) czy wKafkaConsumer
(aplikacji Ruby)?