Streaming-Verarbeitung

Was ist Streaming-Verarbeitung

Streaming-Verarbeitung ist eine kontinuierliche Reaktion auf endlose Abfolgen von Ereignissen (Transaktionsprotokolle, Klicks, Zahlungen, Telemetrie), mit minimaler Verzögerung und Garantie für korrekte Zustände. Im Gegensatz zum Batch, bei dem „wir alles nehmen, was in einem Zeitraum angesammelt wurde“, verarbeitet der Stream die Daten, wenn sie ankommen, hält den Zustand aufrecht und berücksichtigt die Zeit des Ereignisses.

Schlüsselbegriffe

Ein Ereignis (Event) ist eine unveränderliche Tatsache mit 'event _ time' und dem eindeutigen 'event _ id'.
Zeit des Ereignisses (Ereigniszeit) vs Zeit der Verarbeitung (Verarbeitungszeit) - die erste kommt von der Quelle, die zweite - wenn der Operator das Ereignis tatsächlich gesehen hat.

Fenster (Windows) - Gruppieren von Ereignissen nach Zeit:

Tumbling (nicht überlappend), Hopping/Sliding (überlappend), Session (Unterbrechungen durch Inaktivität).
Wasserzeichen - eine Einschätzung, dass „Ereignisse vor dem Zeitpunkt T bereits eingetroffen sind“, die es ermöglicht, Fenster zu schließen und das Warten auf verspätete Daten zu begrenzen.
Verzögerte Daten (lateness) - Ereignisse mit 'event _ time' sind kleiner als die aktuelle Wassermarke; Oft gelten die Regeln der Nachbearbeitung.
Status - Lokale Operatortabellen/Speicher (Keyed State) für Aggregate, Join's, Deduplizierung.
Backpressure - Druck, wenn der Downstream-Durchsatz überschritten wird; wird durch Protokoll und Puffer gesteuert.

Architektonische Grundlagen

1. Quelle (Quelle): Ereignis-Broker (Kafka/NATS/Pulsar), CDC aus DB, Warteschlangen, Dateien/Log-Collectors.
2. Streaming Engine: berechnet Fenster, Aggregate, Joins, Patterns (CEP), steuert den Status und Checkpoint.
3. Empfänger (sink): OLTP/OLAP DB, Suchmaschine, Cache, Topics, Speicher für Vitrinen/Berichte.
4. Scheme Registry: Kontrolle der Payload-Entwicklung und Kompatibilität.
5. Beobachtbarkeit: Metriken, Tracing, Logs, Lag- und Wasserzeichen-Dashboards.

Die Semantik von Zeit und Ordnung

Bevorzugen Sie immer die Ereigniszeit: Dies ist die einzige Invariante bei Verzögerungen und Unterbrechungen.
Ereignisse können außerhalb der Reihenfolge kommen; Ordnung wird nur innerhalb des Parteischlüssels garantiert.

Watermarks ermöglichen:

Fenster schließen und Ergebnisse ausgeben;
Begrenzung von „wie lange wir warten“ auf verspätete Ereignisse ('allowed _ lateness').
Für verspätete Ereignisse verwenden Sie retractions/upserts: Neuberechnung von Aggregaten und korrigierende Ereignisse.

Status und Zuverlässigkeit

Schlüsselzustand: Die Daten der Aggregate (Summen, Zähler, Strukturen für Deduple) werden durch Sharding über Schlüssel verteilt.
Checkpoint/Savepoint: periodische Momentaufnahmen des Status zur Wiederherstellung; savepoint ist ein verwalteter Snapshot für Code-Versionsmigrationen.

Exactly-once wird erreicht durch:

transaktional „gelesen-verarbeitet-aufgezeichnet“ (commit sink + Leseposition);
idempotente sinks (upsert/merge) + Deduplex-Tabellen;
durch Versionierung von Aggregaten (optimistic concurrency).

Fenster, Aggregationen, Joins

Fenster:

Tumbling: einfache periodische Berichte (Minute, Stunde).
Hopping/Sliding: „gleitende“ Metriken (in 5 min in 1 min Schritten).
Session: natürlich für Benutzersitzungen und Anti-Fraud.
Aggregations: sum/count/avg/approx-distinct (HyperLogLog), percentiles (TDigest/CKMS).
Stream-Stream-Verbindung: erfordert die Pufferung beider Seiten nach Schlüssel und Zeit, respektieren Sie' allowed _ skew'.
Stream-Table join (KTable): Anhängen eines Verzeichnisses oder des aktuellen Status (z.B. „aktive Benutzerlimits“).

Arbeiten mit verzögerten und doppelten Daten

Deduplizierung: durch „event _ id“ oder „(producer_id, sequence)“; Speichern Sie „sichtbare“ Schlüssel mit TTL ≥ Wiederholungsfenster.
Späte Ereignisse: Lassen Sie das Fenster innerhalb von „X“ nach dem Schließen nachbearbeiten (Retraktionen/Upserts).
Falsche Duplikate: Passen Sie die Aggregate idempotent an und fixieren Sie die „ALREADY_APPLIED“ in den Protokollen.

Skalierung und Leistung

Schlüsselschardisierung: bietet Parallelität; Achten Sie auf „heiße“ Schlüssel.
Backpressure: Begrenzen Sie die Parallelität, verwenden Sie Batches und Kompression, wenn Sie veröffentlichen.
Wasserzeichen: Setzen Sie nicht zu aggressiv - harte Wasserzeichen verkürzen die Wartezeit, erhöhen aber den Anteil der Late-Updates.
Status: Wählen Sie das Format (RocksDB/state store/in memory) unter Berücksichtigung der Größe und der Zugriffsmuster; TTL reinigen.
Auto-Skalierung: nach Verzögerung, CPU, State-Größe, GC-Zeit.

Zuverlässigkeit und Neustarts

Ein idempotenter Sink oder Transaktionskommit mit Offset-Fixierung ist die Grundlage für Korrektheit.
Die Wiederaufbereitung nach dem Neustart ist zulässig; der Effekt soll „genau einmal“ bleiben.
DLQ/Parkplatz Los: Senden Sie problematische Datensätze in einem separaten Thread mit Ursachen; Sorgen Sie für eine Neubearbeitung.

Beobachtbarkeit (was zu messen ist)

Lag nach Quellen (nach Zeit und nach Mitteilung).
Wasserzeichen/aktuelle Ereigniszeit und Anteil der Late-Events.
Throughput/latency operators, p95/p99 end-to-end.
State size/rocksdb I/O, Checkpoint Frequenz/Dauer.
DLQ-Rate, Prozentsatz der Deduplizierungen/Retrays.
CPU/GC/Heap, Pausen.

Sicherheit und Compliance

Datenklassifizierung: PII/PCI in Schemata markieren, Minimum speichern, Status und Snapshots verschlüsseln.
Zugriffskontrolle: Separate ACLs auf Topics/State-Tabellen und auf Sinks.
Rückstellungen: im Einklang mit den gesetzlichen Anforderungen (DSGVO/Recht auf Vergessenwerden).
Audit: 'event _ id', 'trace _ id' protokollieren, Ergebnis: 'APPLIED/ALREADY _ APPLIED/RETRIED'.

Implementierungsmuster

1. CDC → Normalisierung des Domain- →-Ereignisses: Übertragen Sie keine rohen DB-Änderungen, sondern greifen Sie auf verständliche geschäftliche Fakten zurück.
2. Outbox bei Produzenten: Tatsache der Transaktion + Ereignis - in einer einzigen DB-Transaktion.
3. Core vs Enriched: Minimale Payload im kritischen Fluss, Anreicherung - asynchron.
4. Replay-Freundlichkeit: Projektionen/Schaufenster müssen aus dem Protokoll neu zusammengesetzt werden.
5. Idempotency durch Design: Betriebs-/Ereignisschlüssel, Upsert-Diagramme, Aggregatversionen.

Prüfung

Unit/Property-based: Invarianten von Aggregaten und Transformationen.
Stream-Tests: Fester Ereignisfluss mit Out-of-Order und Duplikaten → Überprüfung von Fenstern und Deduplikaten.
Goldenes Fenster: Referenzfenster/-einheiten und zulässige Spätkorrekturen.
Fault-Injection: Der Fall zwischen „notierte den Effekt“ und „löste das Offset aus“.
Replay-Tests: Schaufensterumbau vom Anfang des Logs = aktueller Status.

Kosten und Optimierung

Fenster und Wasserzeichen wirken sich auf Latenz/Ressourcen aus: je länger das Fenster und je mehr 'allowed _ lateness', desto größer der Zustand.
Codecs und Kompression: Balance CPU/Netzwerk.
Batching out: Weniger Netzwerkanrufe und Transaktionen.
Frühes Filtern („Pushdown“): Überschüssiges möglichst nahe an der Quelle verwerfen.

Anti-Pattern

Die Verbindung zur Verarbeitungszeit ist dort, wo Ereigniszeit → falsche Analytik benötigt werden.
Das Fehlen von Idempotenz im Sink → Doppeleffekte bei Restarts.
Globale „Mega-Schlüssel“: Ein heißer Abschnitt bricht die Parallelität.
Rohe CDCs als öffentliche Ereignisse: durchgesickerte OBD-Schaltungen, Fragilität in der Evolution.
Kein DLQ: „giftige“ Nachrichten blockieren die gesamte Pipeline.
Feste harte Verzögerung statt Wasserzeichen: entweder ewiges Warten oder Datenverlust.

Beispiele für Domänen

Zahlungen/Finanzen

Thread 'payment.', Fenster für Anti-Fraud (Session + CEP), Dedup durch 'operation _ id'.
Exactly-once-Effekt beim Explodieren in der Buchhaltung ledger (upsert + Version).

Marketing/Werbung

Sliding Fenster CTR/Conversions, Join Klicks und Impressionen mit Toleranz' ± Δ t', Aggregation für Bidding.

iGaming/Online-Dienste

Real-Time Balance/Limits, Missionen/Chivki (Session-Fenster), Anti-Fraud-Muster und Warnungen.

Minivorlagen (Pseudocode)

Fenster mit Wasserzeichen und Late-Updates

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)

Transaktionssink mit Offset-Fixierung

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

Checkliste für die Produktion

Ereigniszeit und Wassermarkenstrategie sind definiert; Fenster ausgewählt und 'allowed _ lateness'.
Idempotent sink oder Transaktionskommit mit Offset.
Das Scheme-Register und die Kompatibilitätsregelungen sind enthalten. Die additive Evolution.
Metriken: lag, watermark, p95/p99, DLQ, state size, checkpoint duration.
Tests: Out-of-Order, Duplikate, Neustarts, Replay.
PII/Retention Policies für State und Snap Shots.
Skalierungsplan und Backpressure-Strategien.
Dokumentation von Fensterverträgen und Anpassungen (Late Updates).

FAQ

Ist die Eventzeit Pflicht?
Wenn die Richtigkeit der Metriken und die Konsistenz wichtig sind, ja. Die Verarbeitungszeit ist für die technische Abrechnung/Überwachung geeignet, verzerrt jedoch die Analyse.

Brauchen Sie exactly-once?
Punkt: für kritische Effekte. Häufiger reicht es bei-least-once + idempotent sink.

Wie wählt man Fenster aus?
Verlassen Sie sich auf Business SLA: „in den letzten 5 Minuten“ → Hopping, „Benutzersitzungen“ → Sitzung, „Minutenberichte“ → Tumbling.

Was tun mit den späten Daten?
Begrenzte' allowed _ lateness' zulassen und Anpassungen vornehmen (upsert/retract). Die Kundenvitrine muss erneuert werden können.

Summe

Bei der Streaming-Verarbeitung geht es nicht nur um eine geringe Latenz, sondern auch um die Disziplin von Zeit, Zustand und Verträgen. Die richtige Auswahl von Veranstaltungszeiten, Fenstern und Wasserzeichen sowie idempotente Effekte, Beobachtbarkeit und Tests machen die Pipeline zuverlässig, reproduzierbar und wirtschaftlich - und geben dem Unternehmen Lösungen „hier und jetzt“ statt „über Nacht“.