Przesyłanie strumieniowe

Co to jest Streaming

Streaming jest ciągłą reakcją na niekończące się sekwencje zdarzeń (dziennik transakcji, kliknięcia, płatności, telemetria), z minimalnym opóźnieniem i gwarancją poprawności stanu. W przeciwieństwie do partii, gdzie „bierzemy wszystkie zgromadzone w ciągu okresu”, strumień przetwarza dane w miarę ich przybywania, utrzymuje stan i uwzględnia czas zdarzenia.

Kluczowe koncepcje

Zdarzenie jest faktem niezmiennym z 'event _ time' i unikalnym 'event _ id'.
Czas zdarzenia vs czas przetwarzania - pierwszy pochodzi ze źródła, drugi - kiedy operator rzeczywiście widział zdarzenie.

Windows - zdarzenia grupowe według czasu:

Bombardowanie, skakanie/przesuwanie, sesja.
Znaki wodne - ocena, że „wydarzenia przed T już przybył”, co pozwala zamknąć okna i ograniczyć oczekiwanie na późne dane.
Opóźnienie - wydarzenia z „event _ time” mniejszym niż obecny znak wodny; często stosuje się zasady wykończenia.
Stan - tabele lokalne/stan klucza dla agregatów, przyłączy, deduplikacji.
Ciśnienie wsteczne - ciśnienie po przekroczeniu przepustowości niższego szczebla; jest kontrolowany przez protokół i bufory.

Podstawy architektoniczne

1. Źródło: broker wydarzeń (Kafka/NATS/Pulsar), CDC z DB, kolejki, pliki/kolektory dzienników.
2. Silnik strumieniowy: oblicza okna, agregaty, joyns, wzory (CEP), zarządza stanem i punktami kontrolnymi.
3. Zlewozmywak: baza danych OLTP/OLAP, wyszukiwarka, pamięć podręczna, tematy, magazyny do prezentacji/raportów.
4. Rejestr schematu: kontrolowanie ewolucji i kompatybilności ładunku.
5. Obserwowalność: mierniki, śledzenie, dzienniki, deski rozdzielcze opóźnień i znaków wodnych.

Semantyka czasu i porządek

Zawsze wolą czas zdarzeń: jest to jedyna niezmienna dla opóźnień i przerw.
Wydarzenia mogą wyjść z porządku; zamówienie jest gwarantowane tylko w ramach klucza strony.

Znaki wodne pozwalają na:

zamknij okna i emituj wyniki;
ograniczyć „ile czekamy na” opóźnione zdarzenia ('allowed _ lateness').
W przypadku późnych zdarzeń należy użyć retrakcji/upserts: ponowne obliczenie agregatów i zdarzeń korygujących.

Stan i niezawodność

Stan kluczowy: dane agregatów (sumy, liczniki, struktury do deduplikacji) są zrzucane za pomocą klawiszy.
Punkt kontrolny/Savepoint - okresowe migawki stanu do odzyskiwania; savepoint - migawka zarządzana dla migracji w wersji kodowej.

Dokładnie po osiągnięciu efektu:

transakcyjne „read-processed-write” (sink commit + position read);
idempotentne zlewozmywaki (upsert/fuzja) + tabele deduplikacji;
przez wersioning agregatów (optymistyczne współistnienie).

Okna, agregacje, dołącz

Okna:

Tumbling: proste okresowe raporty (minuta, godzina).
Chodzenie/przesuwanie: „przesuwne” mierniki (w 5 minut w 1-minutowych przyrostach).
Sesja: naturalna dla sesji niestandardowych i zwalczania nadużyć finansowych.
Agregacje: suma/liczba/avg/ok-odrębne (HyperLogLog), percentyle (TDigest/CKMS).
Stream-Stream join: wymaga buforowania obu stron przez klucz i czas, respect 'allowed _ skew'.
Stream-Table join (KTable) -Attaches a directory or current state (na przykład, „active user limits”).

Praca z opóźnionymi i duplikatowymi danymi

Deduplikacja: przez 'event _ id' lub' (producer_id, sekwencja) '; Przechowywać klucze „widziane” za pomocą TTL ≥ okna redo.
Późne zdarzenia: Zezwalaj na przetwarzanie po oknie dla 'X' po zamknięciu (wycofanie/upserts).
Fałszywe duplikaty: ustawić kruszywa i naprawić „ALREADY_APPLIED” w dziennikach.

Skala i wydajność

Kluczowe odcienie: zapewnia paralelizm; Uważaj na gorące klucze.
Backpressure: ograniczyć paralelizm, używać partii i kompresji podczas publikacji.
Znaki wodne: Nie bądź zbyt agresywny - twarde znaki wodne zmniejszają przewidywania, ale zwiększają odsetek późnych aktualizacji.
Status: wybierz format (RocksDB/state store/in memory) biorąc pod uwagę rozmiar i wzory dostępu; oczyścić TTL.
Autoskalowanie: przez lag, procesor, rozmiar stanu, czas GC.

Niezawodność i uruchamia się ponownie

Zlewozmywak idempotentny lub zlecenie transakcji z utrwaleniem offsetu jest podstawą poprawności.
Ponowne przetwarzanie po ponownym uruchomieniu jest dozwolone; efekt musi pozostać „dokładnie raz”.
DLQ/parking: wyślij zapisy problemów do oddzielnego wątku z powodów; zapewnić ponowne przetwarzanie.

Obserwowalność (co zmierzyć)

Lag według źródła (według czasu i wiadomości).
Znak wodny/aktualny czas zdarzenia i odsetek późnych wydarzeń.
Operatorzy przepustowości/opóźnienia, p95/p99 end-to-end.
Wielkość stanu/rocksdb I/O, wskaźnik/czas trwania punktu kontrolnego.
Wskaźnik DLQ, procent deduplikacji/retray.
CPU/GC/hałd, czas przerwania.

Bezpieczeństwo i zgodność

Klasyfikacja danych: znak PII/PCI na wykresach, przechowywanie minimum, stan szyfrowania i migawki.
Kontrola dostępu: oddzielne ACL dla stołów tematycznych/stanowych i zlewozmywaków.
Zatrzymania: zgodne z wymogami prawnymi (RODO/prawo do bycia zapomnianym).
Audyt: log 'event _ id',' trace _ id', wynik: 'APPLIED/ALREADY _ APPLIED/RETRIEVED'.

Wzory implementacji

1. CDC → normalizacja → wydarzenia domeny: nie nadawać surowe zmiany bazy danych, mapa do zrozumiałych faktów biznesowych.
2. Outbox dla producentów: fakt transakcji + wydarzenie - w jednej transakcji bazodanowej.
3. Rdzeń vs Wzbogacony: minimalny ładunek w przepływie krytycznym, wzbogacenie - asynchroniczny.
4. Przyjazność dla powtórzeń: projekcje/prezentacje muszą zostać przeniesione z dziennika.
5. Idempotencja według projektu: klucz operacyjny/eventowy, schematy upsert, wersje agregatów.

Badania

Jednostka/nieruchomości: niezmienne agregaty i przekształcenia.
Testy strumieniowe: stały strumień zdarzeń z pozasądowymi i duplikatami → kontrola okien i deduplikacji.
Złote okna: okna referencyjne/agregaty i dopuszczalne późne korekty.
Zastrzyk błędu: spadek pomiędzy „zarejestrowanym efektem” a „popełnionym offsetem”.
Powtórne testy: ponowne zaprezentowanie od początku dziennika = stan bieżący.

Koszt i optymalizacja

Okna i znak wodny wpływają na opóźnienie/zasoby: im dłuższe okno i im większe „allowed _ lateness”, tym większy stan.
Kodeki i kompresja: równowaga procesora/sieci.
Wyjście wsadowe: mniejsza liczba połączeń sieciowych i transakcji.
Filtrowanie wcześnie („pushdown”): wyrzucić nadmiar tak blisko źródła, jak to możliwe.

Antypattery

Powiązanie z czasem przetwarzania, w którym potrzebny jest czas zdarzenia → nieprawidłowa analiza.
Brak idempotencji w zlewie → podwójne efekty przy ponownym uruchomieniu.
Globalne „mega-klucze”: jedna gorąca partycja łamie paralelizm.
Surowe płyty CDC jako wydarzenia publiczne: wyciek schematów DB, kruchość w ewolucji.
Brak DLQ: „trujące” wiadomości blokują cały rurociąg.
Naprawiono twarde opóźnienie zamiast znaku wodnego: wieczne oczekiwanie lub utrata danych.

Przykłady domen

Płatności/Finanse

Płatność strumieniowa. ", windows for anti-fraud (session + CEP), dziadek przez 'operation _ id'.
Dokładnie raz efekt po opublikowaniu do księgi księgowej (upsert + wersja).

Marketing/Reklama

Okna przesuwne CTR/konwersji, Przyłącz kliknięcia i wrażenia z tolerancją '± Α t', agregacja do licytacji.

iGaming/usługi online

Saldo/limity w czasie rzeczywistym, misje/osiągnięcia (okna sesji), wzorce przeciwdziałania oszustwom i wpisy.

Mini szablony (kod pseudo)

Okno ze znakami wodnymi i późnymi aktualizacjami

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

Zlewozmywak transakcyjny z zamocowaniem offsetowym

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

Lista kontrolna produkcji

Określona strategia dotycząca czasu zdarzeń i znaków wodnych; wybrano okna i 'allowed _ lateness'.
Idempotent sink lub transakcja popełnić z offsetem.
Rejestry schematów i tryby kompatybilności są włączone; ewolucja addytywna.
Wskaźniki: lag, znak wodny, p95/p99, DLQ, rozmiar stanu, czas trwania punktu kontrolnego.
Testy: out-of-order, duplikaty, restarty, powtórka.
Polityka PII/retencji dla państw i migawek.
Plan skalowania i strategie wsparcia.
Dokumentacja umów okiennych i korekt (późne aktualizacje).

NAJCZĘŚCIEJ ZADAWANE PYTANIA

Potrzebny czas zdarzenia?
Jeśli poprawność mierników i konsystencja są ważne, tak. Czas przetwarzania nadaje się do obliczeń technicznych/monitorowania, ale zniekształca analitykę.

Czy jest potrzebny dokładnie raz?
Punkt: dla skutków krytycznych. Częściej wystarczy przynajmniej raz + idempotent sink.

Jak wybrać okna?
Budowanie na SLA biznesowych: „ostatnie 5 minut →” skakanie „, sesje użytkownika →” sesja „, raporty minutowe →” tumbling.

Co zrobić z późnymi danymi?
Zezwalaj na ograniczone 'allowed _ lateness' i korekty emisji (upsert/retract). Prezentacja klienta musi być w stanie zaktualizować.

Razem

Jak również niskie opóźnienia, streaming jest dyscypliną czasu, stanu i umów. Właściwy wybór czasu zdarzeń, okien i znaków wodnych, a także efekty idempotentne, obserwowalność i testy sprawiają, że rurociąg jest niezawodny, powtarzalny i ekonomiczny - i daje przedsiębiorstwom tutaj i teraz rozwiązania, nie co drugą noc.