Szkolenie: Apache Spark – Structured Streaming

Model mikrobatchowy – tabela wejściowa, tabela wynikowa, ujście

Tryby wyniku: complete, append, update – semantyka i ograniczenia każdego trybu

Pierwsze zapytanie strumieniowe – źródło gniazda sieciowego (TCP)

Spark Connect – konfiguracja i uruchomienie serwera

Structured Streaming API – źródła: gniazdo TCP, pliki, rate source, Kafka, Delta Lake

Structured Streaming API – schematy wejściowych DataFrames dla każdego typu źródła

Delta Lake jako źródło strumieniowe – opcje ignoreDeletes, ignoreChanges, startingVersion

Structured Streaming API – transformacje obsługiwane i nieobsługiwane (AnalysisException)

Structured Streaming API – typy ujść i ich własności (file, Kafka, foreach, foreachBatch, console, memory, Delta Lake)

KafkaSourceProvider – odczyt danych z tematu Kafki i parsowanie JSON ze zdefiniowanym schematem

Wsadowy prototyp jako punkt wyjścia dla wersji strumieniowej

Ujście JDBC – ograniczenia natywnego wsparcia w Structured Streaming

Ujście foreachBatch – zapis wyników do bazy danych MySQL

Struktura kompletnego skryptu produkcyjnego – parametry, kontekst, transformacje, awaitTermination

Wdrożenie aplikacji na produkcję – spark-submit z ustawieniem SPARK_REMOTE i Spark Connect

Czas zdarzenia (event-time) a czas przetwarzania (processing-time) – różnice i zastosowania

Etykieta czasowa jako element strukturalny zdarzenia – konwersja z to_timestamp

Typy okien: tumbling, sliding/hopping, session, globalne – przykłady kodu i porównanie

Wynik grupowania po oknie – struct window (start, end) i jego obsługa w DataFrame

Wpływ definicji okna na rozmiar utrzymywanego stanu

Operatory stanowe a tryby obsługi wyniku – kiedy append, kiedy update

Ujście foreachBatch w trybie append – zmiana logiki obsługi wyniku względem trybu complete

Monitorowanie zapytań strumieniowych – query.lastProgress, query.status, StreamingQueryListener

Metody obiektu StreamingQuery i SparkSession (id, runId, stop, awaitTermination, recentProgress)

Monitorowanie stanu za pomocą interfejsu sieciowego Apache Spark

Przyczyny nieuporządkowania zdarzeń w strumieniu – opóźnienia sieciowe, wiele partycji Kafki, clock skew, buforowanie producenta

Konsekwencje braku obsługi nieuporządkowania – utrata ponad 50% danych na przykładzie warsztatu

Metryka Aggregated Number Of Late Rows Dropped By Watermark – diagnoza problemu

Mechanizm watermark – metoda withWatermark, wzór wm = max(ets) − wInt

Warunek usuwania stanu okna: end_w_ts < wm

Gwarancje watermarku – charakter jednokierunkowy; zdarzenia opóźnione mogą zostać uwzględnione

Watermark obliczany raz na granicach mikro-wsadów: watermark(batch N) = max_event_time(batch N-1) − delay

Filtrowanie zdarzeń jako "too late" – okna vs. inne operatory stanowe

Szczegóły techniczne: EventTimeWatermarkExec w planie fizycznym

Detekcja poziomu nieuporządkowania danych źródłowych – analiza per partycja z użyciem metadanych Kafki (partition, offset)

Pomiar max_observed_skew za pomocą funkcji okienkowej Window.partitionBy

Dobór wartości watermark: watermark = max_observed_skew + margines bezpieczeństwa

Konsekwencje rozmiaru watermark dla utrzymywanego stanu

Dwa operatory stanowe (preagregacja i agregacja) a rzeczywista wielkość stanu

Dwie semantyki czasu w jednym zapytaniu: semantyka zapytania (definicja okna) vs. szczegóły przetwarzania (watermark, trigger)

Monitorowanie watermark: numRowsDroppedByWatermark, Global Watermark Gap, Total State Rows w interfejsie sieciowym

Cel punktów kontrolnych – cofnięcie się do ostatniego spójnego mikro-wsadu

Struktura katalogu checkpointLocation: metadata, sources, offsets, commits, state

Pliki delta i snapshot w katalogu state – różnica i parametr minDeltasForSnapshot

Algorytm mikro-wsadu – cztery fazy: wyznaczenie offsetów i zapis offsets/N; przetwarzanie z użyciem StateStore; zapis stanu (delta + snapshot); zapis do ujścia i zapis commits/N

Relacja offsets/commits: offsets określa zakres danych, commits oznacza wsady zakończone

Trwałe punkty kontrolne w rozproszonym systemie plików (MinIO / S3) – konfiguracja checkpointLocation

Symulacja awarii węzła klastra – docker stop i obserwacja zachowania aplikacji

Algorytm odtwarzania po awarii – pięć kroków: odczyt metadanych, ustalenie ostatniego commitu, wyznaczenie batcha startowego, odtworzenie StateStore, wznowienie odczytu

Odtworzenie stanu StateStore – start od ostatniego snapshotu ≤ lastCommit, zastosowanie plików delta

Semantyka at-most-once, at-least-once, exactly-once – definicje i warunki uzyskania

Gwarancje end-to-end – trzy warunki exactly-once: checkpointy, deterministyczne przetwarzanie, idempotentne lub transakcyjne ujście

Dlaczego foreachBatch nie daje exactly-once – scenariusz powtórzenia mikro-wsadu po awarii przed commitem

Gwarancje per warstwa: Kafka→Spark exactly-once, stan okien exactly-once, Spark→MySQL at-least-once

Idempotentna obsługa ujścia – operacja UPSERT w MySQL z ograniczeniem UNIQUE i INSERT ON DUPLICATE KEY

Porównanie mechanizmu checkpointów Spark Structured Streaming z barierowym mechanizmem Flink

Przegląd ujść i gwarancji dostarczania – zestawienie typów ujść, trybów wyniku i poziomu gwarancji

Pułapki ujścia niestandardowego – problem N połączeń z bazą (200 partycji = 200 połączeń na mikro-wsad), brak idempotentności, niska wydajność UDF

Ujście plikowe jako natywne exactly-once – atomowy zapis pliku do katalogu tymczasowego i przeniesienie po zatwierdzeniu mikro-wsadu

Delta Lake jako ujście strumieniowe – exactly-once dzięki transakcyjnemu dziennikowi

Porównanie czystego File Sink z Delta Lake (transakcyjność, równoległy dostęp, kontrola plików, wymuszanie schematu)

Dziennik transakcji Delta Lake – gwarancja spójności przy równoległym dostępie batch + strumień

Kontrola liczby plików Delta Lake – trzy mechanizmy: OPTIMIZE (ręcznie po fakcie), optimizeWrite (zapobiegawczo przy zapisie), autoCompact (automatycznie po zatwierdzeniu)

Shuffle – koszt operacji (dysk, sieć) i konsekwencje dla przetwarzania strumieniowego przy każdym mikro-wsadzie

spark.sql.shuffle.partitions – domyślna wartość 200 i jej konsekwencje (200 tasków, 200 plików, 200 połączeń na mikro-wsad)

State Store – fizyczna organizacja stanu i powiązanie liczby partycji z podziałem plików punktu kontrolnego

Dobór liczby partycji shuffle do środowiska

Problem zmiany liczby partycji w działającej aplikacji stanowej – brak mechanizmu przemapowania stanu; warianty obejścia (usunięcie punktu kontrolnego lub cofnięcie offsetów)

Wyzwalacze (triggers) – typy: domyślny, processingTime, availableNow, once, continuous

Koszt pustego mikro-wsadu – narzut planowania, aktualizacja punktu kontrolnego, wpisy w dzienniku transakcji

Projektowanie częstotliwości mikro-wsadów – korelacja z długością okien, trybem wyniku i wymaganiami latencji

Checklista optymalizacji – ujście, spójność, pliki, partycje, wyzwalacze