Kafka: Consumer API vs Streams API

Niedawno zacząłem uczyć się języka Kafka i otrzymałem te pytania.

1. Jaka jest różnica między Consumer i Stream? Dla mnie, jeśli jakiekolwiek narzędzie / aplikacja konsumuje wiadomości od Kafki, jest konsumentem w świecie Kafki.

2. Czym różni się usługa Stream, skoro również pobiera wiadomości z platformy Kafka lub generuje je do niej? i dlaczego jest to potrzebne, skoro możemy napisać własną aplikację konsumencką przy użyciu Consumer API i przetwarzać je w razie potrzeby lub wysyłać do Spark z aplikacji konsumenckiej?

Zrobiłem to w Google, ale nie otrzymałem żadnych dobrych odpowiedzi. Przepraszam, jeśli to pytanie jest zbyt trywialne.

Aktualizacja z 9 kwietnia 2018 r . : Obecnie można również używać ksqlDB , bazy danych strumieniowania zdarzeń dla platformy Kafka, do przetwarzania danych w Kafce. ksqlDB jest zbudowany na bazie interfejsu API strumieni firmy Kafka, a także zapewnia pierwszorzędną obsługę „strumieni” i „tabel”.

Jaka jest różnica między Consumer API a Streams API?

Biblioteka strumieni Kafki ( https://kafka.apache.org/documentation/streams/ ) jest zbudowana na podstawie producenta i klientów konsumenckich Kafki. Strumienie Kafki są znacznie potężniejsze, a także bardziej wyraziste niż zwykli klienci.

O wiele prostsze i szybsze jest pisanie aplikacji w świecie rzeczywistym od początku do końca za pomocą strumieni Kafka niż w przypadku zwykłego konsumenta.

Oto niektóre funkcje interfejsu API strumieni Kafka, z których większość nie jest obsługiwana przez klienta konsumenckiego (wymagałoby to samodzielnego zaimplementowania brakujących funkcji, zasadniczo ponownego wdrożenia strumieni Kafka).

• Obsługuje semantykę przetwarzania dokładnie raz za pośrednictwem transakcji Kafka ( co oznacza EOS )
• Obsługuje odporne na błędy stanowe (i oczywiście bezstanowe) przetwarzanie, w tym łączenie strumieniowe , agregacje i okienkowanie . Innymi słowy, obsługuje zarządzanie stanem przetwarzania aplikacji od razu po wyjęciu z pudełka.
• Podpory przetwarzania zdarzeń w czasie , jak również przetwarzanie w oparciu o przetwarzanie w czasie i połykanie czasie . Bezproblemowo przetwarza również dane poza kolejnością .
• Ma pierwszorzędne wsparcie zarówno dla strumieni, jak i tabel , czyli tam, gdzie przetwarzanie strumieniowe łączy się z bazami danych; w praktyce większość aplikacji do przetwarzania strumieniowego potrzebuje obu strumieni ORAZ tabel do implementacji odpowiednich przypadków użycia, więc jeśli technologia przetwarzania strumieniowego nie ma żadnej z dwóch abstrakcji (powiedzmy, że nie obsługuje tabel), albo utkniesz, albo musisz ręcznie zaimplementować tę funkcję samodzielnie (Powodzenia z tym...)
• Obsługuje zapytania interaktywne (zwane również „stanem zapytań”) w celu udostępnienia najnowszych wyników przetwarzania innym aplikacjom i usługom
• Jest bardziej wyraziste: to statki z (1) funkcjonalny programowania styl DSL z operacji, takich jak map, filter, reduceoraz (2) imperatywem stylu Processor API na przykład robi złożonego przetwarzania zdarzeń (CEP) i (3) można nawet łączyć DSL i API procesora.
• Posiada własny zestaw testowy do testów jednostkowych i integracyjnych.

Zobacz http://docs.confluent.io/current/streams/introduction.html, aby uzyskać bardziej szczegółowe, ale wciąż ogólne wprowadzenie do interfejsu API strumieni Kafka, które powinno również pomóc ci zrozumieć różnice w stosunku do konsumenta Kafki niższego poziomu klient.

Poza strumieniami Kafka możesz również używać bazy danych ksqlDB do przesyłania strumieniowego zdarzeń do przetwarzania danych w Kafka. ksqlDB jest zbudowany na bazie strumieni Kafka. Obsługuje zasadniczo te same funkcje, co strumienie Kafka, ale zamiast języka Java lub Scala piszesz strumieniowe SQL. Programowo można współdziałać z ksqlDB za pośrednictwem interfejsu wiersza polecenia lub interfejsu API REST; ma również natywnego klienta Java na wypadek, gdybyś nie chciał używać REST.

Czym więc różni się interfejs API strumieni Kafka, skoro również pobiera wiadomości z platformy Kafka lub generuje je?

Tak, interfejs API Kafka Streams może zarówno odczytywać dane, jak i zapisywać dane w Kafce. Obsługuje transakcje Kafka, więc możesz np. Przeczytać jedną lub więcej wiadomości z jednego lub więcej tematów, opcjonalnie zaktualizować stan przetwarzania, jeśli zajdzie taka potrzeba, a następnie napisać jeden lub więcej komunikatów wyjściowych do jednego lub więcej tematów - wszystko jako jeden operacja atomowa.

i dlaczego jest to potrzebne, skoro możemy napisać własną aplikację konsumencką przy użyciu Consumer API i przetwarzać je w razie potrzeby lub wysyłać do Spark z aplikacji konsumenckiej?

Tak, możesz napisać własną aplikację konsumencką - jak wspomniałem, interfejs API Kafka Streams korzysta z samego klienta konsumenckiego Kafka (plus klient producenta) - ale musiałbyś ręcznie zaimplementować wszystkie unikalne funkcje, które zapewnia Streams API . Zobacz powyższą listę wszystkiego, co otrzymujesz „za darmo”. Dlatego raczej rzadko zdarza się, że użytkownik wybrałby zwykłego klienta konsumenckiego, a nie bardziej wydajną bibliotekę Kafka Streams.

Komponent Kafka Stream zbudowany do obsługi transformacji wiadomości typu ETL. Oznacza wprowadzenie strumienia z tematu, przekształcenie i wyjście do innych tematów. Obsługuje przetwarzanie w czasie rzeczywistym, a jednocześnie obsługuje zaawansowane funkcje analityczne, takie jak agregacja, okienkowanie, łączenie itp.

„Kafka Streams upraszcza tworzenie aplikacji, opierając się na bibliotekach producenta i konsumenckiego platformy Kafka oraz wykorzystując natywne możliwości platformy Kafka do oferowania równoległości danych, koordynacji rozproszonej, odporności na błędy i prostoty operacyjnej”.

Poniżej znajdują się kluczowe elementy architektoniczne Kafka Stream. Proszę zapoznać się tutaj

1. Strumieniowe partycje i zadania : strumienie Kafka używają koncepcji partycji i zadań jako jednostek logicznych modelu równoległości opartego na partycjach tematycznych Kafki.
2. Model wątkowania: strumienie Kafka umożliwiają użytkownikowi skonfigurowanie liczby wątków, których biblioteka może użyć do zrównoleglenia przetwarzania w ramach wystąpienia aplikacji.
3. Lokalne magazyny stanowe: Kafka Streams zapewnia tak zwane magazyny stanu, które mogą być używane przez aplikacje przetwarzania strumieniowego do przechowywania i wyszukiwania danych, co jest ważną funkcją podczas wdrażania operacji stanowych
4. Odporność na awarie: Kafka Streams opiera się na możliwościach odporności na awarie zintegrowanych natywnie w Kafka. Partycje Kafka są wysoce dostępne i replikowane, więc gdy dane strumieniowe są utrwalane w Kafka, są dostępne nawet w przypadku awarii aplikacji i konieczności ponownego przetworzenia.

Na podstawie mojego zrozumienia poniżej znajdują się kluczowe różnice, które jestem otwarty na aktualizację, jeśli brakuje jakiegokolwiek punktu lub wprowadzają go w błąd

Gdzie używać Konsument - Producent:

1. Jeśli są pojedynczy klienci, wykorzystaj proces przesyłania wiadomości, ale nie przejmuj się innymi tematami.
2. Jako punkt 1, jeśli mamy tylko producenta produkującego wiadomość, nie potrzebujemy Kafka Stream.
3. Jeśli komunikat konsumenta z jednego klastra Kafka, ale publikuje w różnych tematach klastra Kafka. W takim przypadku możesz nawet użyć Kafka Stream, ale musisz użyć oddzielnego producenta do publikowania wiadomości w różnych klastrach. Lub po prostu użyj mechanizmu Kafka Konsument - Producent.
4. Przetwarzanie wsadowe - jeżeli istnieje wymóg odebrania wiadomości lub rodzaj przetwarzania wsadowego to warto skorzystać z tradycyjnej metody.

Gdzie korzystać z Kafka Stream:

1. Jeśli korzystasz z wiadomości z jednego tematu, przekształcaj i publikuj w innych tematach, najlepiej nadaje się Kafka Stream.
2. Przetwarzanie w czasie rzeczywistym, analiza w czasie rzeczywistym i uczenie maszynowe.
3. Transformacja stanowa, taka jak agregacja, okno łączenia itp.
4. Planowanie wykorzystania lokalnych sklepów państwowych lub zamontowanych sklepów państwowych, takich jak Portworx itp.
5. Osiągnij dokładnie jedno przetwarzanie semantyczne i automatycznie zdefiniowaną odporność na błędy.