Transcription

Apache Kafka to platforma do przetwarzania strumieni danych w czasie rzeczywistym. W ciągu ostatnich kilkunastu lat stała się jednym z najważniejszych narzędzi w dużych systemach, a według raportu Solid Jobs w poprzednim roku Kafka wskoczyła do top 10 najczęściej występujących technologii w ofertach pracy. Samo wielokrotnie ją wymieniałem opisując przykładowe architektury YouTube'a, Twitter'a czy Uber'a, gdzie Kafka pełni kluczową rolę przy analizowaniu danych w czasie rzeczywistym, zbieraniu logów czy informacji o akcjach użytkowników. Dlatego tworzę kurs Kafka Chef, który aktualnie jest w przedsprzedaży i do 8 kwietnia w promocyjnej cenie. Nie chcę tutaj przedłużać, bo wszystkie szczegóły znajdziesz na stronie kafkaszef.pl. Kafka działa w klastrze, czyli grupy serwerów zwanych brokerami. Broker to po prostu jedna instancja Kafka odpowiedzialna za przechowywanie i przekazywanie danych. Kafka organizuje dane na kilku poziomach. Pierwszy z nich to tak zwany topic, który jest jakby nazwanym kanałem albo szuną danych dla określonego rodzaju wiadomości. Topic jest tylko pojęciem logicznym, bo sam w sobie nie jest ani plikiem, ani żadnym fizycznym magazynem danych. Każdy topic może być podzielony na partycje, czyli niezależne fragmenty danych. Dzięki partycjom można równolegle przetwarzać te dane, co zwiększa skalowalność i wydajność, bo różne serwery mogą obsługiwać różne partycje tego samego topicu jednocześnie. Kafka gwarantuje, że wiadomości, które trafiają do partycji, to w tej samej partycji będą one uporządkowane w kolejności, w jakiej do niej trafiły. Działa to na zasadzie unikalnych identyfikatorów zwanych offsetami, przepisywanych każdej wiadomości trafiającej do Kafka, gdzie offsety to liczby całkowite przepisywane sekwencyjnie. Natomiast partycja to nie jest ostatnia warstwa Kafka. Każda partycja topicu odpowiada katalogowi na dysku. I w tym katalogu znajdują się pliki segmentów, i musisz wiedzieć, że Kafka przechowuje dane w postaci logów, czyli plików z rozszerzeniem log. I właśnie, aby zarządzać długimi logami w partycjach, Kafka dzieli fizyczny log każdej partycji na mniejsze pliki zwane segmentami. Czyli dla przykładu, jeżeli utworzy topic o nazwie mytopic z czterema partycjami na jednym brokerze, to na dysku będzie to przechowywane w taki sposób. Mamy więc cztery partycje, których nazwa składa się z nazwy topica i kolejnych cyfr od 0 do 3, reprezentujących kolejne partycje. I każda z tych partycji przechowuje segmenty, czyli pliki z rozszerzeniem log, których nazwa oznacza przechowywane przez nich offsety. Na przykład ten plik składa się z samych zer, bo przechowuje dane od offsetu równego 0. A gdy będzie potrzebny kolejny segment, to zostanie utworzony kolejny plik log, z nazwą zawierającą liczbę pierwszego offsetu, który ten log zawiera. Do każdego segmentu Kafka utrzymuje pliki index, które wspierają szybki dostęp do dany. Znamy podstawy architektury Kafka, więc poznajmy kto wysyła i kto odbiera te dane. Rolą nadawców pełnią tzw. producenci, czyli aplikacje lub usługi, które publikują wiadomości do Kafka. Producent wysyła komunikat, np. informację o nowym zamówieniu w sklepie internetowym, do wybranego topiku. Z drugiej strony mamy konsumentów, czyli aplikacje, które subskrybują dany temat i odczytują z nich nadchodzące wiadomości. Konsumenci mogą działać niezależnie lub w ramach tzw. grup konsumerów. Grupa konsumerów to kilka instancji odczytujących wspólnie dane z danego topiku. Kafka zapewnia wtedy, że każda wiadomość z danej partycji trafi tylko do jednego konsumenta z danej grupy. Dzięki temu możemy skalować odbiór danych. Np. jeśli mamy topik z czterema partycjami i dwóch konsumentów w grupie, to wtedy konsumenci podzielą pracę między siebie. Jeśli natomiast konsumenci należą do różnych grup, to każdy z nich dostanie pełny zestaw wiadomości z danego tematu niezależnie od pozostałych. Pozwala to wielu aplikacjom korzystać z tych samych danych bez wzajemnego wpływu, bo jedna grupa konsumentów nie podbiera wiadomości tej drugiej. Zbliżymy się teraz, jak przebiega przesyłanie i przetwarzanie danych w Kafce, czyli co dzieje się z wiadomością od momentu wysłania przez producenta do momentu odczytu przez konsumenta. Gdy producent wysyła wiadomość, kieruje ją do określonego topiku, np. zamówienia. Broker przyjmuje wiadomość i zapisuje ją na dysku, dopisując na koniec pliku przypisanego do tej partycji. Każda nowa wiadomość dostaje kolejny numer w sekwencji, czyli offset. Kafka przechowuje dane w formacie uporządkowanego logu, co oznacza, że wiadomości są trwale zapisywane w takiej kolejności, w jakiej przychodzą. Każdy konsument, który subskrybuje dany temat, regularnie pyta brokera, czy są nowe wiadomości dla tematu X. Jest to tzw. model pool, bo to konsument sam pobiera dane, zamiast otrzymywać je automatycznie. Broker, mając zapisane wiadomości, przekazuje je konsumentowi w takiej kolejności, w jakiej zostały zapisane, czyli według rosnących offsetów. Konsument przetwarza każdą wiadomość i za pomocą tzw. commit offsetu zaznacza, że ją odczytał. Dzięki temu wiadomo, przy którym miejscu w logu konsument zakończył odbiór. Przy kolejnym pobieraniu danych dostanie następną, nieodczytaną wiadomość. Konsument odczytując wiadomość nie usuwa jej z kafki. Dane pozostają w systemie, a przynajmniej przez pewien skonfigurowany czas, doby do osiągnięcia określonego rozmiaru. I mogą być odczytane przez innych konsumentów, a nawet ponownie odczytane później przez tego samego konsumenta, np. aby zrobić jakąś analizę na historycznych danych. Partycje i grupy konsumentów sprawiają, że kafka wyróżnia się na tle innych brokerów. Jeśli chcesz równomiernie rozłożyć obciążenie, to zwiększasz liczbę partycji i uruchamiasz wielu konsumentów w jednej grupie, dzięki czemu kafka automatycznie rozdzieli partycje między nich i proces ten nazywa się rebalans, czyli ponowne zrównoważenie obciążenia, gdy dołączony konsument lub inny odpada. Z drugiej strony, jeśli chcesz, aby różne aplikacje otrzymywały te same dane, to dajesz im po prostu różne nazwy grup. Wtedy każda z grup dostanie pełną kopię strumienia wiadomości. Ogromną zaletą kafki jest wbudowana odporność na awarię dzięki replikacji. A jak to działa? Każdą partycję można powielić na kilku brokerach. Liczba kopii jest określana w konfiguracji topiku jako współczynnik replikacji. Załóżmy, że wynosi on trzy. Wówczas dana partycja istnieje równocześnie na trzech brokerach. Wtedy z tych kopii wybierana jest jedna jako lider, a pozostałe nazywane followers na bieżąco synchronizują się z liderem. Producent zawsze wysyła wiadomości właśnie do lidera, który zaraz po zapisaniu danych na dysku replikuje je do wszystkich followersów. Dopiero gdy wiadomość znajdzie się na wymaganej liczby replik, np. na wszystkich jeśli kluczowa jest wysoka trwałość, to lider potwierdza producentowi przyjęcie komunikatu. Jeżeli jeden z brokerów przestanie działać, to kawka przeprowadza automatyczny wybór nowego lidera spośród pozostałych dostępnych kopii partycji. Za koordynację tego procesu w starszych wersjach kawki odpowiadał Apache Zookeeper, natomiast w nowszych tzw. kraft, czyli kawka raft. Dzięki replikacji kluster może nadal obsługiwać operacje zapisu i odczytu, nawet jeśli któryś z węzłów ulegnie awarii. Dane nie zostaną utracone, ponieważ fizycznie istnieją ich kopie na innych brokerach. Teoretycznie przy współczynniku replikacji N kluster może przetrwać awarię nawet N-1 brokerów bez utraty danych, o ile choć jedna NSYNC replika jest wciąż dostępna. W praktyce jednak faktyczny poziom dostępności zależy też od ustawień, takich jak minISR, czyli minimalna liczba replik, które muszą być w pełni zsynchronizowane, oraz od trybu wyboru lidera kontrolowanego np. przez parametr unclean leader election enable. Dzięki takiej architekturze kawka stała się podstawą przy budowie dużych, wydajnych i skalowalnych systemów. Np. w architekturze mikroserwisów różne usługi mogą komunikować się poprzez kawkę, zamiast bezpośrednich połączeń typu REST. Serwis obsługujący zamówienia publikuje zdarzenie nowe zamówienie do tematu zamówienia. Inne mikroserwisy, które są tym zainteresowane, czyli magazyn, fakturowanie itd., subskrybują ten temat i reagują na zdarzenia we własnym zakresie, czyli jeden rezerwuje towar w magazynie, drugi wystawia fakturę, trzeci wysyła email do klienta itd. Dzięki kawce te komponenty są luźno powiązane, bo mogą działać niezależnie i w różnym tempie, a dodanie nowego odbiorcy np. nowego modułu analizującego sprzedaż nie wymaga zmian w kodzie producenta zdarzeń. Wystarczy tylko, że nowa usługa zacznie subskrybować odpowiedni temat. Innym zastosowaniem mogą być systemy Big Data, gdzie kawka często stanowi centralną magistralę danych, czyli zbiera strumień informacji z wielu źródeł, np. kliknięcia użytkowników na stronie, logi aplikacji, dane z czujników IoT czy transakcje finansowe i przekazuje je dalej do systemów przetwarzających te dane. Jeśli wytrwałeś do tego momentu i coś pożytecznego wyniosłeś z tego filmu, to zostaw łapkę w górę i suba.