Kafka - platforma przesyłania strumieniowego

Kafka? Bardzo chętnie. Czyli klarowne, zrozumiałe objaśnienie czym naprawdę jest Kafka.

W Internecie znajdziecie mnóstwo artykułów o Kafce. Są te z bardzo ogólnym objaśnieniem co to takiego jest, są i tutoriale jak zainstalować Kafkę. Niewiele jest jednak artykułów które by pozwoliły szybko zrozumieć co do czego to oprogramowanie służy, jak działa, jaka jest różnica miedzy Kafką a innymi rozwiązaniami do wymiany informacji między systemami.

Zacznijmy od podstawy podstaw. Słyszeliście pewnie niejednokrotnie skrót "API". To "interfejs programistyczny aplikacji". Po angielsku będzie to brzmieć "application programming interface" (API). Jesli zadasz w Internecie pytanie "co to jest API", najprawdopodobniej trafisz na filmy pokazuące że "API jest jak kelner u którego składasz zamówienia na dania, napoje, drinki. Ty wybierasz z karty, a kelner realizuje Twoje zamówienie".

Ale nie potrzebujemy aż takiego łopatologicznego porównania. API to interfejs/funkcja dzięki któremy możesz wysłać do danej aplikacji/systemu dane i możesz je stamtąd odebrać. Nawet jeśli nie jesteś osobą ze świata informatyki łatwo możesz sobie wyobrazić sysutacje gdzie potrzebujesz np. wysłać do systemu kadrowego plik z przepracowanymi godzinami, pobrać z Internetu kody pocztowe przypisane do miast i województw, wysłać rozliczenie PIT. Ty wysyłasz plik, program po drugiej stronie wie jak go odebrać i co z nim zrobić. Albo; Ty potrzebujesz informacji, program po tamtej stronie wie jak ją przygotować i Ci ja dostarczyć.

API czyli... nie wiadomo co

Powiedzieć "API" to powiedzieć "samochód". API nie oznacza żadnego standardu, nie jest żadną określoną formą interfejsu dzieki któremu możliwe jest wysyłanie czy odbieranie danych. Znaczy tylko tyle że jakaś forma komunikacji jest możliwa. Najprostsze API mogą być zdolne obsłużyc tylko manualny proces (np formularz do pobierania/wysyłania plików). Te bardziej zaawansowane umożliwiają zautomatyzowanie procesu. Warto to wiedzieć bo coraz więcej osób wymienia ten zwrot nie mając pojęcia że mówi o niczym.

Różne formy wymiany danych

Choć dane wymieniać z systemami mogą ludzie, główną przyczyną rozwoju tej dziedziny informatyki była potrzeba stworzenia rozwiązań do komunikacji systemów w rozproszonym środowisku komputerowym - czyli tam gdzie mamy więcej niż jeden serwer, często w różnych lokalizacjach.

We wczesnych latach 90tych komputery używały mechanizmu Remote Procedure Call by komunikować się między sobą. Z RPC, poprzez IDL (Interface Definition Language), wykształcił się XML-RPC gdzie formatem wiadomości był XML. Tutaj świat miał zawrót głowy i by uprzykrzyć sobie życie postanowił tak prostą formę jak XML-RPC przekształcić w SOAP (Simple Object Access Protocol) i Web Services Description Language (WSDL). O SOAP można powiedzieć wszystko ale nie to że jest "simple". To wzorcowy przykład jak rzeczy proste skomplikować ponad miarę.

Następnym rejonem ewolucji była zmiana protokołu do komunikacji - warstwa sieciowa. HTTP stał się na tyle popularny (mamy już Internet) że wymiany danych zaczeły odbywać się właśnie z użyciem tego protokołu - protokołu "web" (http). Zatem serwisy obsługujące wymianę danych stały się "web serwisami". Podobnie jak w przypadku "API" - określenie "web service" jest bardzo ogólne. Web serwisem jest zarówno SOAP jak i nowsze formy takich serwisów; np. REST.

REST

Web serwisy REST to ewolucja SOAP; uproszczenie formatu i uproszczenie zasad komunikacji. REST oznacza "Representational State Transfer". Co to znaczy?

Chociaż REST jest bezstanowy (klient i serwer nie podtrzymują sesji), ma w swojej nazwie transfer stanu. To trochę zagmatwane dla wszystkich. W standardowej komunikacji klient i serwer wykonają uzgadnianie i zainicjują sesję (nazywaną połączeniem TCP). Następnie, w oparciu o zachowanie serwera i klienta, stan zmieni się na ESTABLISHED, IDLE, TIMEOUT itp.

Ale w REST używamy protokołu HTTP, który jest bezstanowy, co oznacza, że ​​serwer nie będzie przechowywać żadnych informacji o sesji "klient", nie będzie przechowywać stanu tego połączenia.
W takiej komunikacji, przeglądarka lub klient RESTprzesyłają wszystkie dane wymaganych przez serwer do obsługi, co oznacza, że ​​kiedy wywołujemy identyfikator URI http://domena/strona1 z serwera, serwer ma wystarczająco dużo informacji o kliencie do obsługi dostarczenia "strona1".

"State" w REST nie oznacza stanu połączenia między serwerem a klientem.

Co oznacza Representational?

Oznacza to komunikację poprzez przesyłanie "reprezentacji" zasobów. Kiedy przegladarka prosi o stronę http://domena/strona1, nie prosi o stronę ale o reprezentację tej strony. Strona HTML nie jest zasobem, to tylko jedna reprezentacja. A kiedy wysyłamy formularz, po prostu wysyłamy inną reprezentację z powrotem na serwer. Jeszcze prościej wyobrazić sobie "reprezentację" właśnie w web serwisie/API. Dane udostępnianie przez taki interfejs/program mogą mieć wiele reprezentacji; mieć formę HTM, JSON, XML.

Co oznacza State?

Gdy klient wysyła żądanie GET, jesli w odbpowiedzi otrzymamy JSON, zawierać będzie reprezentację jego aktualnego stanu lub aktualnych danych. A jeśli klient żąda aktualizacji tego zasobu, mówi się, że wysyła reprezentację w celu zaktualizowania „stanu” zasobu.

W języku REST klient i serwer wymieniają reprezentacje zasobu, które odzwierciedlają jego aktualny stan lub żądany stan. REST, czyli Reprezentacyjny transfer stanu, to sposób, w jaki dwie maszyny mogą przesłać stan zasobu za pośrednictwem reprezentacji.

W REST stosujemy metody http GET, HEAD, POST, PUT, PATCH, DELETE - np odczyt zasobu realizuje motodą GET, aktualizację POST a jego usunięcie metodą DELETE. Wykonujemy różne operacje na jednym zasobie używając tego samego URL i odpowiednią metode protokołu html.

Kończąc objaśnienie czym są najczęściej używane web serwisy REST należy dodać ze formatem danych może być nie tylko JSON (najczęściej stosowany) ale też XML czy zwykły HTML.

Wymiana danych z pomocą web serwisu

Kiedy klient ząda reprezentacji jakiegoś zasobu i jego stanu, wysyła zapytanie do REST API. Np. kiedy chcemy poznac dane klienta o numerze 123 łączymy się z url http://api.domena.com/v2.2/klient/123. W odpowiedzie serwer wysyła do nas odpowiedź w formacie JSON:

{ "imię": "Ala", "nazwisko": "Kowalska", "status": "1" }

W najprostszym scenariuszu samo API może być częścią serwera który przechowuje te dane. Częściej API jest warstwą pomiędzy klientem a systemem/systemami które przechowują dane. Jednak każde zapytanie musi być obsłużone procesem przygotowania danych i wysyłki tych danych do klienta. W systemach które są obciążone dużą ilością zapytań odpowiedzi są buforowane - nie przygotowuje się za każdym razem odpowiedzi na to samo zapytanie. Uproszczony scenariusz:

Zapytanie => Przygotowanie odpowiedzi => Odesłanie odpowiedzi

Jeśli z jednego zasobu korzysta wielu klientów, każdy klient łącząc się z API zleca przygotowanie tych danych na nowo i jeśli tylko nie są one buforowane, API musi za każdym razem wykonać pracę związaną z obsłużeniem takiego żądania.

Wymiana danych w Kafka

W artykułach o Kafce często traficie na informację że "Kafka dostarcza informacje błyskawicznie, niemal w czasie rzeczywistym" i że jest to głowna przewaga Kafki nad REST. To absolutnie nie jest prawda. Czy np. REST Google ktory analizuje zdjęcie w czasie jednej sekundy jest wolny? A przecież wiele "tradycyjnych" API je jeszcze szybszych (w zależności jakich informacji dostarczają); wyobraź sobie API grafowej bazy danych która zwróci rezultat Twojego zapytania w kilka milisekund przeszukując setki tysięcy nodów. Ponadto Kafka nie produkuje żadnych wiadomości. Ona udostępnia to co zostało do niej dostarczone. Kafka jest platformą przesyłania strumieniowego.

Co oznacza "strumieniowy przesył danych"? Być może słyszałeś o architekturze przetwarzana opartej o "business events". W systemach powstają "zdarzenia biznesowe" które produkują dane. Przykładami takich zdarzeń biznesowych mogą być informacje z czujników (IOT), kliknięcia użytkowników sklepu internetowego, dostawy towarów do magazynu, sprzedaż, systemy rekomendacji produktów... wymyśl kilkadziesiąt następnych. Wyobraź sobie teraz wszystkie te systemy wysyłające dane płynące z systemów - nieograniczony, ciągły strumien informacji. To są właśnie strumienie. Te strumienie nigdy nie przestają płynąć - w przyszłości nie będzie czasu kiedy moglibyśmy powiedzieć "koniec, zrobione". Informacji do Kafki dostarczaja nam "producers". Tak nazywamy programy wytwarzające te informacje.

Wszystkie te informacje trafiają do Kafki. Ale gdyby trafiły tam do jednego worka, bezładnie, mielibyśmy problem w zorientowaniu się co jest co. Zatem w Kafce tworzymy kanały; informacje o odwiedzanych przez klientów stronach trafią do jednego kanału, informacje o dostawach to drugiego kanału, stany naszych maszyn vendingowych do trzeciego. Te kanały w Kafce nazywamy topikami.

OK, mamy dane z systemów. Wyprodukowane one zostały w jakichś konkretnych celach - na potrzeby aplikacji/systemów. Odbiorców tych informacji nazywamy "consumers". Aplikacje łączą się z kanałami, topikami, Kafki by pobrać potrzebne im informacje. Pamiętasz, w API REST lub SOAP aplikacja kiedy potrzebowała danych wysyłała żadanie do API a ten (lub ktoś w jego imieniu) generował potrzebne dane i zwracał do aplikacji. Tutaj gotowe dane są już do pobrania. Kafka przechowuje je zorganizowane w topiki jak MC Donalds gotowe Big Mac'i do wydania. Dane te pozostają w Kafce przez określony czas (określony przez developerów). Po tym czasie są usuwane. A to oznacza że żądania róznych aplikacji/klientów pobierają te same dane. Raz jeszcze; dane pozostają w Kafce nawet po ich pobraniu - klient nie usuwa danych.

Glowna rola Kafki to bufor pomiędzy "producentem" informacji a "konsumentem" tej informacji. Kafka sama w sobie nie przyśpiesza tworzenia informacji. Ale ponieważ informacje są już gotowe do pobrania (ktoś je wcześniej musiał wytworzyć), klient otrzymuje potrzebne informacje bardzo szybko nie obciążając zapytaniem serwerów z których te informacje mogą pochodzić.

Kafka natywnie wykorzystuje binarny protokół z wartwą transportową TCP. Zarówno "producer" (aplikacja wysyłająca informację) jak i "consumer" mają do dyspozycji gotowe biblioteki ktore umożliwią wysyłkę/odebranie rekordów z różnych systemów; Java, Python, .NET, C++...

Dlaczego przesyłamy tyle informacji?

Często słyszymy że systemy produkują coraz więcej danych. Tak jest. Jednak coraz więcej informacji przepływających między systemami to nie tylko efekt wytwarzania coraz większej ilości informacji. W latach 90-tych, 2000-nych jeden system obsługiwał wiele funkcji. Obecnie architektura systemów jest świadomie modułowa. To daje możliwość łatwej wymiany takiego modułu, optymalizacji kosztów (np. analizę danych można przeprowadzić poza systemem ERP). Mamy tez szeroko stosowane "cloud computing". By wszystkie te systemy mogły efektywnie pracować potrzebują wymieniać dane.

Historia

Tak, nazwa Kafka pochodzi od Franz'a Kafki. Kafka została pierwotnie opracowana przez Linkedin, a następnie została udostępniona jako open source na początku 2011 roku. Nie, Kafka nie jest jedynym systemem który umożliwia strumieniowe procesowanie informacji. Mamy np. https://www.rabbitmq.com/, https://spark.apache.org/