Dowiedz się, czym jest Apache Kafka, jak działają tematy i partycje oraz gdzie Kafka pasuje we współczesnych systemach do obsługi zdarzeń w czasie rzeczywistym, logów i potoków danych.
Apache Kafka to rozproszona platforma do strumieniowania zdarzeń. Mówiąc prosto: to współdzielony, trwały „przewód”, który pozwala wielu systemom publikować fakty o tym, co się wydarzyło, i pozwala innym systemom czytać te fakty — szybko, na dużą skalę i w kolejności.
Zespoły używają Kafki, gdy dane muszą przepływać niezawodnie między systemami bez silnego powiązania. Zamiast jednej aplikacji wywołującej drugą bezpośrednio (i zawodzącej, gdy jest niedostępna lub wolna), producenci zapisują zdarzenia do Kafki. Konsumenci czytają je, gdy są gotowi. Kafka przechowuje zdarzenia przez konfigurowalny okres, więc systemy mogą odzyskać się po awariach, a nawet przetworzyć historię ponownie.
Przewodnik jest dla inżynierów myślących produktowo, specjalistów od danych i liderów technicznych, którzy chcą praktycznego modelu mentalnego Kafki.
Nauczysz się podstawowych elementów (producenci, konsumenci, tematy, brokerzy), jak Kafka skaluje się dzięki partycjom, jak przechowuje i odtwarza zdarzenia oraz gdzie pasuje w architekturze zdarzeniowej. Omówimy też typowe przypadki użycia, gwarancje dostarczenia, podstawy bezpieczeństwa, planowanie operacji i kiedy Kafka jest (lub nie jest) właściwym narzędziem.
Kafkę najłatwiej zrozumieć jako współdzielony log zdarzeń: aplikacje zapisują do niego zdarzenia, a inne aplikacje czytają te zdarzenia później — często w czasie rzeczywistym, czasem godzinę czy dzień po zdarzeniu.
Producenci to pisarze. Producent może opublikować zdarzenie typu „order placed”, „payment confirmed” lub „temperature reading”. Producenci nie wysyłają zdarzeń bezpośrednio do określonych aplikacji — wysyłają je do Kafki.
Konsumenci to czytelnicy. Konsument może zasilać pulpit nawigacyjny, uruchamiać workflow wysyłki lub ładować dane do analityki. Konsumenci decydują, co zrobić ze zdarzeniami, i mogą czytać we własnym tempie.
Zdarzenia w Kafce grupowane są w tematy, które są właściwie nazwanymi kategoriami. Na przykład:
orders dla zdarzeń związanych z zamówieniamipayments dla zdarzeń płatnościinventory dla zmian stanu magazynowegoTemat staje się „strumieniem prawdy” dla danego rodzaju zdarzeń, co ułatwia wielu zespołom ponowne użycie tych samych danych bez tworzenia jednorazowych integracji.
Broker to serwer Kafka, który przechowuje zdarzenia i udostępnia je konsumentom. W praktyce Kafka działa jako klaster (wiele brokerów współpracujących), dzięki czemu może obsłużyć większy ruch i działać dalej nawet przy awarii maszyny.
Konsumenci często działają w grupie konsumentów. Kafka rozdziela pracę odczytu wśród grupy, więc możesz dodać więcej instancji konsumenta, aby skalować przetwarzanie — bez tego, by każda instancja robiła to samo.
Kafka skaluje się, dzieląc pracę na tematy (strumienie powiązanych zdarzeń), a potem dzieląc każdy temat na partycje (mniejsze, niezależne kawałki strumienia).
Temat z jedną partycją może być odczytywany w danym czasie przez jednego konsumenta w grupie. Dodaj więcej partycji, a możesz dodać więcej konsumentów, żeby przetwarzać zdarzenia równolegle. W ten sposób Kafka wspiera wysokowydajne strumieniowanie zdarzeń i potoki danych w czasie rzeczywistym bez tworzenia wąskiego gardła.
Partycje pomagają też rozłożyć obciążenie na brokerach. Zamiast jednej maszyny obsługującej wszystkie zapisy i odczyty dla tematu, różne partycje mogą być hostowane na różnych brokerach i współdzielić ruch.
Kafka gwarantuje kolejność w obrębie pojedynczej partycji. Jeśli zdarzenia A, B i C zostaną zapisane do tej samej partycji w tej kolejności, konsumenci odczytają je A → B → C.
Kolejność między partycjami nie jest gwarantowana. Jeśli potrzebujesz ścisłej kolejności dla konkretnego bytu (np. klienta lub zamówienia), zwykle dbasz, by wszystkie zdarzenia dla tego bytu trafiały do tej samej partycji.
Przy wysyłaniu zdarzenia producenci mogą dołączyć klucz (np. order_id). Kafka używa klucza, by konsekwentnie kierować powiązane zdarzenia do tej samej partycji. To daje przewidywalną kolejność dla danego klucza, przy jednoczesnym skalowaniu tematu na wiele partycji.
Każda partycja może być replikowana na inne brokery. Gdy jeden broker padnie, inny z repliką może przejąć. Replikacja jest głównym powodem, dla którego Kafka jest zaufana w krytycznych systemach pub-sub messaging i systemach zdarzeniowych: poprawia dostępność i wspiera odporność na awarie bez konieczności budowania własnej logiki awaryjnego przełączania w każdej aplikacji.
Kluczową ideą w Apache Kafka jest to, że zdarzenia nie są tylko przekazywane i zapominane. Zapisuje się je na dysku w uporządkowanym logu, więc konsumenci mogą je czytać teraz — lub później. To sprawia, że Kafka jest użyteczna nie tylko do przesyłania danych, ale też do utrzymywania trwałej historii zdarzeń.
Gdy producent wysyła zdarzenie do tematu, Kafka dopisuje je do magazynu na brokerze. Konsumenci następnie czytają z tego zapisanego logu we własnym tempie. Jeśli konsument będzie nieaktywny godzinę, zdarzenia nadal istnieją i można je odczytać po jego przywróceniu.
Kafka przechowuje zdarzenia zgodnie z politykami retencji:
Retencję konfiguruje się per temat, co pozwala traktować tematy „śledzące audyt” inaczej niż tematy telemetryczne o dużym wolumenie.
Niektóre tematy są bardziej jak dziennik zmian niż archiwum historyczne — np. „bieżące ustawienia klienta”. Kompaktacja logu zachowuje przynajmniej najświeższe zdarzenie dla każdego klucza, podczas gdy starsze, nadpisane rekordy mogą być usunięte. Nadal masz trwałe źródło prawdy dla najnowszego stanu, bez nieograniczonego wzrostu danych.
Ponieważ zdarzenia są przechowywane, możesz je odtworzyć, aby zrekonstruować stan:
W praktyce odtwarzanie kontroluje punkt, od którego konsument „zaczyna czytać” (jego offset), dając zespołom potężne zabezpieczenie podczas ewolucji systemów.
Kafka jest zbudowana tak, by dane płynęły nawet wtedy, gdy części systemu zawodzą. Osiąga to dzięki replikacji, jasnym regułom, kto jest „liderem” danej partycji, oraz konfigurowalnym potwierdzeniom zapisu.
Każda partycja tematu ma jednego lidera i jednego lub więcej followerów (replik) na innych brokerach. Producenci i konsumenci rozmawiają z liderem tej partycji.
Followerzy ciągle kopiują dane lidera. Jeśli lider padnie, Kafka może wypromować aktualnego followera na lidera, by partycja pozostała dostępna.
Jeśli broker padnie, partycje, których był liderem, staną się chwilowo niedostępne. Kontroler Kafki wykrywa awarię i uruchamia wybór lidera dla tych partycji.
Jeśli przynajmniej jedna replika jest wystarczająco zaktualizowana, może przejąć rolę lidera i klienci wznowią produkcję/konsumpcję. Jeśli nie ma dostępnej repliki w sync, Kafka może wstrzymać zapisy (w zależności od ustawień), aby uniknąć utraty potwierdzonych danych.
Dwa główne ustawienia kształtują trwałość:
Na poziomie koncepcyjnym:
Aby zredukować duplikaty przy retry, zespoły często łączą bezpieczniejsze acks z idempotentnymi producentami i solidnym obsługiwaniem konsumentów.
Większe bezpieczeństwo zwykle oznacza czekanie na więcej potwierdzeń i utrzymywanie większej liczby replik w sync, co może zwiększać opóźnienie i zmniejszać maksymalną przepustowość.
Niższe opóźnienia mogą być akceptowalne dla telemetrii lub clickstreamu, gdzie sporadyczna utrata jest dopuszczalna, ale płatności, zarządzanie zapasami i logi audytu zwykle uzasadniają większe bezpieczeństwo.
Architektura zdarzeniowa (EDA) to sposób budowania systemów, w którym zdarzenia biznesowe — zamówienie złożone, płatność potwierdzona, paczka wysłana — są reprezentowane jako zdarzenia, na które inne części systemu mogą reagować.
Kafka często stoi w centrum EDA jako współdzielony „strumień zdarzeń”. Zamiast usługa A wywoływać usługę B bezpośrednio, usługa A publikuje zdarzenie (np. OrderCreated) do tematu Kafka. Dowolna liczba usług może konsumować to zdarzenie i wykonać akcję — wysłać e-mail, zarezerwować zapas, uruchomić kontrolę fraudową — bez potrzeby, by usługa A wiedziała o ich istnieniu.
Ponieważ usługi komunikują się przez zdarzenia, nie muszą koordynować API request/response dla każdej interakcji. To zmniejsza mocne powiązania między zespołami i ułatwia dodawanie nowych funkcji: możesz wprowadzić nowego konsumenta dla istniejącego zdarzenia bez zmiany producenta.
EDA jest naturalnie asynchroniczna: producenci szybko zapisują zdarzenia, a konsumenci przetwarzają je we własnym tempie. Podczas skoków ruchu Kafka pomaga zbuforować nadmiar, żeby systemy downstream nie padły natychmiast. Konsumenty mogą się skalować, by nadrobić zaległości, a jeśli jeden konsument padnie czasowo, wznowi od miejsca, w którym przerwał.
Pomyśl o Kafce jak o „feedzie aktywności” systemu. Producenci publikują fakty; konsumenci subskrybują fakty, które ich interesują. Ten wzorzec umożliwia potoki danych w czasie rzeczywistym i workflowy zdarzeniowe, jednocześnie utrzymując usługi prostsze i bardziej niezależne.
Kafka pojawia się tam, gdzie zespoły muszą przesyłać dużą ilość małych „faktów, które się wydarzyły” — szybko, niezawodnie i tak, by wiele konsumentów mogło je ponownie wykorzystać.
Aplikacje często potrzebują logu tylko-dopisującego: logowania logowań użytkowników, zmian uprawnień, aktualizacji rekordów czy działań administratorów. Kafka sprawdza się jako centralny strumień takich zdarzeń, dzięki czemu narzędzia bezpieczeństwa, raportowanie i eksporty zgodności czytają to samo źródło bez dodatkowego obciążania bazy produkcyjnej. Ponieważ zdarzenia są przechowywane przez pewien czas, można je też odtworzyć po błędzie lub zmianie schematu.
Zamiast usług wywołujących się bezpośrednio, mogą publikować zdarzenia typu „order created” lub „payment received”. Inne usługi subskrybują i reagują we własnym czasie. To zmniejsza powiązania, pomaga utrzymać działanie przy częściowych awariach i ułatwia dodawanie nowych możliwości (np. kontrole fraud) poprzez konsumpcję istniejącego strumienia zdarzeń.
Kafka jest częstym kręgosłupem do przesyłania danych z systemów operacyjnych do platform analitycznych. Zespoły mogą strumieniować zmiany z baz aplikacji i przekazywać je do magazynu danych lub jeziora z niskim opóźnieniem, trzymając aplikację produkcyjną oddzieloną od ciężkich zapytań analitycznych.
Czujniki, urządzenia i telemetria aplikacji często przychodzą w piku. Kafka może wchłonąć skoki, zbuforować je bezpiecznie i pozwolić downstreamowi nadrobić zaległości — przydatne do monitoringu, alertów i analiz długoterminowych.
Kafka to więcej niż brokerzy i tematy. Większość zespołów polega na narzędziach towarzyszących, które ułatwiają codzienne przesyłanie danych, przetwarzanie strumieni i operacje.
Kafka Connect to framework integracyjny Kafki do pobierania danych do Kafki (źródła) i wysyłania z Kafki (sinki). Zamiast budować i utrzymywać jednorazowe potoki, uruchamiasz Connect i konfigurujesz konektory.
Typowe przykłady: pobieranie zmian z baz danych, ingestowanie zdarzeń SaaS, dostarczanie danych z Kafki do hurtowni danych lub obiektu storage. Connect standaryzuje też kwestie operacyjne jak retry, offsety i równoległość.
Jeśli Connect to integracja, to Kafka Streams to obliczenia. To biblioteka, którą dodajesz do aplikacji, aby transformować strumienie w czasie rzeczywistym — filtrować zdarzenia, wzbogacać je, łączyć strumienie i budować agregaty (np. „zamówienia na minutę”).
Aplikacje Streams czytają z tematów i zapisują z powrotem do tematów, więc dobrze wpisują się w systemy zdarzeniowe i można je skalować, dodając instancje.
Gdy wiele zespołów publikuje zdarzenia, spójność ma znaczenie. Zarządzanie schematami (często za pomocą schema registry) definiuje, jakie pola powinno mieć zdarzenie i jak ewoluują w czasie. Pomaga to zapobiegać awariom, np. gdy producent zmieni nazwę pola, od którego zależy konsument.
Kafka jest wrażliwa operacyjnie, więc podstawowy monitoring jest niezbędny:
Wiele zespołów używa też UI do zarządzania i automatyzacji wdrożeń, konfiguracji tematów i polityk dostępu (zobacz /blog/kafka-security-governance).
Często zespoły pytają: czy przetworzę każde zdarzenie raz i co się stanie, gdy coś zawiedzie? Kafka daje bloki konstrukcyjne — to od Ciebie zależy, jakie kompromisy wybierzesz.
At-most-once oznacza, że możesz utracić zdarzenia, ale nie przetworzysz duplikatów. Może się tak zdarzyć, jeśli konsument zatwierdzi offset przed zakończeniem pracy i potem padnie.
At-least-once oznacza, że nie stracisz zdarzeń, ale duplikaty są możliwe (np. konsument przetwarza zdarzenie, pada, a potem przetwarza je ponownie po restarcie). To najczęstszy domyślny wzorzec.
Exactly-once ma na celu uniknięcie zarówno strat, jak i duplikatów end-to-end. W Kafce zwykle używa się transakcyjnych producentów i kompatybilnego przetwarzania (często przez Kafka Streams). To potężne, ale bardziej ograniczone i wymaga starannej konfiguracji.
W praktyce wiele systemów akceptuje at-least-once i dodaje zabezpieczenia:
Offset konsumenta to pozycja ostatnio przetworzonego rekordu w partycji. Gdy zatwierdzasz offsety, mówisz: „skończyłem do tutaj”. Zatwierdź za wcześnie — ryzykujesz utratę; za późno — zwiększasz duplikaty po awarii.
Retry powinny być ograniczone i widoczne. Typowy wzorzec:
To zapobiega blokowaniu całej grupy konsumentów przez jedną „trującą” wiadomość, jednocześnie zachowując dane do późniejszego naprawienia.
Kafka często przenosi krytyczne zdarzenia biznesowe (zamówienia, płatności, aktywność użytkowników). Dlatego bezpieczeństwo i governance są częścią projektu, nie dodatkiem.
Uwierzytelnianie odpowiada na pytanie „kim jesteś?”, autoryzacja na „co możesz robić?”. W Kafce uwierzytelnianie często realizuje się przez SASL (np. SCRAM lub Kerberos), a autoryzacja przez ACL na poziomie tematów, grup konsumentów i klastra.
Praktyczny wzorzec to zasada najmniejszych uprawnień: producenci mogą pisać tylko do swoich tematów, a konsumenci czytać tylko te tematy, których potrzebują. Zmniejsza to ryzyko niezamierzonego wycieku danych i ogranicza zasięg szkód przy wycieku poświadczeń.
TLS szyfruje dane podczas przesyłu między aplikacjami, brokerami i narzędziami. Bez TLS zdarzenia można przechwycić w sieciach wewnętrznych, nie tylko w Internecie. TLS pomaga też zapobiegać atakom typu „man-in-the-middle”, weryfikując tożsamość brokerów.
Gdy wiele zespołów dzieli klaster, warto mieć zasadnicze reguły. Jasne konwencje nazewnicze tematów (np. <team>.<domain>.<event>.<version>) ułatwiają wskazanie właściciela i pomagają narzędziom stosować polityki.
Połącz nazewnictwo z limitami i szablonami ACL, by jedna głośna aplikacja nie zagłodziła innych oraz by nowe usługi startowały z bezpiecznymi ustawieniami domyślnymi.
Traktuj Kafkę jak system zapisu historii zdarzeń tylko wtedy, gdy to zamierzasz. Jeśli zdarzenia zawierają PII, stosuj minimalizację danych (wysyłaj identyfikatory zamiast pełnych profili), rozważ szyfrowanie na poziomie pól i dokumentuj, które tematy są wrażliwe.
Ustawienia retencji powinny odpowiadać wymaganiom prawnym i biznesowym. Jeśli polityka mówi „usuń po 30 dniach”, nie przechowuj 6 miesięcy „na wszelki wypadek”. Regularne przeglądy i audyty pomagają utrzymać konfiguracje zgodne z wymaganiami.
Uruchamianie Apache Kafka to nie „zainstaluj i zapomnij”. Zachowuje się raczej jak usługa współdzielona: wiele zespołów od niej zależy i drobne błędy mogą rozlać się na systemy downstream.
Pojemność Kafki to głównie zadanie matematyczne, które warto regularnie przeglądać. Najważniejsze dźwignie to partycje (równoległość), przepustowość (MB/s in/out) i wzrost magazynu (jak długo przechowujesz dane).
Jeśli ruch się podwoi, może być potrzebnych więcej partycji, by rozłożyć obciążenie na brokerach, więcej dysku na retencję i więcej przepustowości sieci na replikację. Praktyczny nawyk to prognozowanie szczytowej szybkości zapisu i przemnożenie przez retencję, by oszacować wzrost dysku, a potem dodanie bufora na replikację i „nieoczekiwany sukces”.
Oczekuj rutynowej pracy poza utrzymaniem serwerów:
Koszty generują dyski, transfer sieciowy i liczba/rozmiar brokerów. Zarządzana Kafka może zmniejszyć nakład pracy i uprościć aktualizacje, podczas gdy samodzielne hostowanie może być tańsze przy skali, jeśli masz doświadczonych operatorów. Kompromisem jest czas przywracania i obciążenie on-call.
Zespoły zwykle monitorują:
Dobre dashboardy i alerty zamieniają Kafkę z „czarnej skrzynki” w zrozumiałą usługę.
Kafka sprawdza się, gdy potrzebujesz przesyłać dużo zdarzeń niezawodnie, przechowywać je przez pewien czas i pozwolić wielu systemom reagować na te same dane we własnym tempie. Jest szczególnie użyteczna, gdy dane powinny być odtwarzalne (do backfilli, audytów lub odbudowy nowych usług) i gdy spodziewasz się rosnącej liczby producentów/konsumentów.
Kafka błyszczy, gdy masz:
Kafka może być przerostem formy, jeśli potrzeby są proste:
W takich przypadkach koszty operacyjne (rozmiar klastra, aktualizacje, monitoring, on-call) mogą przewyższyć korzyści.
Kafka też uzupełnia — nie zastępuje — baz danych (system zapisu), cache (szybkie odczyty) i narzędzia ETL batch (duże okresowe transformacje).
Zadaj pytania:
Jeśli na większość odpowiedź brzmi „tak”, Kafka zwykle jest sensownym wyborem.
Kafka najlepiej pasuje, gdy potrzebujesz współdzielonego „źródła prawdy” dla strumieni zdarzeń w czasie rzeczywistym: wiele systemów produkujących fakty (zamówienia utworzone, płatności autoryzowane, zmiany zapasów) i wiele systemów konsumujących te fakty, by zasilać potoki, analitykę i funkcje reaktywne.
Zacznij od wąskiego, wysokowartościowego przepływu — np. publikowania zdarzeń „OrderPlaced” dla downstreamu (email, fraud, fulfilment). Unikaj traktowania Kafki jako catch-all już na dzień pierwszy.
Zapisz:
Utrzymuj wczesne schematy proste i spójne (znacznik czasu, identyfikatory, jasna nazwa zdarzenia). Zdecyduj, czy będziesz egzekwować schematy od początku, czy ewoluować ostrożnie.
Kafka działa najlepiej, gdy ktoś jest odpowiedzialny za:
Dodaj monitoring od razu (consumer lag, stan brokerów, przepustowość, błędy). Jeśli nie masz platformy, zacznij od oferty zarządzanej i jasnych limitów.
Produkuj zdarzenia z jednego systemu, konsumuj je w jednym miejscu i sprawdź pętlę end-to-end. Dopiero potem rozszerzaj do większej liczby konsumentów, partycji i integracji.
Jeśli chcesz szybko przejść od „pomysłu” do działającej usługi zdarzeniowej, narzędzia takie jak Koder.ai mogą pomóc w prototypowaniu otaczającej aplikacji (React UI, backend w Go, PostgreSQL) i stopniowym dodawaniu producentów/konsumentów Kafka przez prowadzone czaty. Przydaje się to szczególnie do budowy wewnętrznych dashboardów i lekkich usług konsumujących tematy, oferując tryb planowania, eksport kodu źródłowego, wdrożenie/hosting oraz snapshoty z możliwością rollbacku.
Jeśli mapujesz to na podejście zdarzeniowe, zobacz /blog/event-driven-architecture. Aby zaplanować koszty i środowiska, sprawdź /pricing.
Kafka to rozproszona platforma do strumieniowania zdarzeń, która zapisuje zdarzenia w trwałych, tylko-dopisujących logach.
Producenci zapisują zdarzenia do tematów, a konsumenci czytają je niezależnie (często w czasie rzeczywistym, ale też później), ponieważ Kafka przechowuje dane przez skonfigurowany okres.
Użyj Kafka, gdy wiele systemów potrzebuje tego samego strumienia zdarzeń, chcesz luźnego powiązania i możliwości odtworzenia historii.
Jest szczególnie przydatna do:
Temat (topic) to nazwana kategoria zdarzeń (np. orders albo payments).
Partycja to fragment tematu, który umożliwia:
Kafka gwarantuje zachowanie kolejności tylko w obrębie pojedynczej partycji.
Kafka używa klucza rekordu (np. order_id), aby konsekwentnie wysyłać powiązane zdarzenia do tej samej partycji.
Zasada praktyczna: jeśli potrzebujesz kolejności na poziomie encji (wszystkie zdarzenia dla zamówienia/klienta w kolejności), wybierz klucz reprezentujący tę encję, żeby zdarzenia trafiały do jednej partycji.
Grupa konsumentów to zbiór instancji konsumentów współdzielących pracę na temacie.
W grupie:
Jeśli dwie różne aplikacje mają otrzymywać każde zdarzenie niezależnie, powinny używać różnych grup konsumentów.
Kafka przechowuje zdarzenia na dysku zgodnie z politykami tematu, dzięki czemu konsumenci mogą nadrobić zaległości po przestoju lub ponownie przetworzyć historię.
Typowe rodzaje retencji:
Retencja ustawiana jest per temat, więc strumienie audytowe mogą być przechowywane dłużej niż telemetryczne o dużej objętości.
Kompakcja logu zachowuje co najmniej najnowszy rekord dla każdego klucza, usuwając z czasem starsze nadpisane rekordy.
Przydaje się dla strumieni reprezentujących „bieżący stan” (np. ustawienia klienta), gdzie zależy nam na ostatniej wartości na klucz, a nie na całej historii zmian.
Najczęstszym wzorcem end-to-end jest at-least-once: nie tracisz zdarzeń, ale mogą pojawić się duplikaty.
Aby obsługiwać to bezpiecznie:
Offset to „zakładka” konsumenta dla partycji.
Jeśli zatwierdzisz offset zbyt wcześnie, ryzykujesz utratę pracy po awarii; zbyt późno — zwiększasz prawdopodobieństwo duplikatów po restarcie.
Częstym wzorcem operacyjnym jest ograniczona liczba retry z backoffem, a następnie przesłanie problematycznego rekordu do dead-letter topic, aby pojedyncza „trująca” wiadomość nie blokowała całej grupy konsumentów.
Kafka Connect przesuwa dane do i z Kafka za pomocą konektorów (źródła i zlewy) bez potrzeby pisania własnego kodu potoków.
Kafka Streams to biblioteka do przetwarzania strumieni w aplikacji (filtrowanie, wzbogacanie, łączenie, agregowanie), która czyta z tematów i zapisuje wyniki z powrotem do tematów.
Użyj Connect do integracji; Streams do obliczeń i transformacji w czasie rzeczywistym.