Streaming

Ce este Streaming

Streaming-ul este o reacție continuă la secvențe nesfârșite de evenimente (jurnal de tranzacții, clicuri, plăți, telemetrie), cu întârzieri minime și o garanție că stările sunt corecte. Spre deosebire de lot, în cazul în care „luăm toate acumulate pe parcursul perioadei”, fluxul procesează datele pe măsură ce sosește, menține starea și ia în considerare timpul evenimentului.

Concepte cheie

Evenimentul este un fapt imuabil cu 'event _ time' și unic 'event _ id'.
Timpul evenimentului vs timpul de procesare - primul vine de la sursă, al doilea - când operatorul a văzut efectiv evenimentul.

Windows - evenimente de grup de timp:

Tumbling, țopăit/alunecare, sesiune.
Filigrane - o evaluare care „evenimente înainte de T au sosit deja”, permițându-vă să închideți ferestrele și să limitați așteptarea datelor întârziate.
Lateness - evenimente cu 'event _ time' mai puțin decât filigranul actual; regulile de finisare sunt adesea aplicate.
Stat - tabele locale/stat cheie pentru agregate, se alătură, deduplicare.
Backpressure - presiune atunci când debitul în aval este depășit; este controlat de protocol și tampoane.

Baza arhitecturală

1. Sursa: event broker (Kafka/NATS/Pulsar), CDC de la DB, cozi, fișiere/colectoare de jurnal.
2. Motor de streaming: calculează ferestre, agregate, joyns, modele (CEP), gestionează puncte de stat și de control.
3. Chiuveta: baza de date OLTP/OLAP, motor de căutare, memorie cache, subiecte, depozite pentru vitrine/rapoarte.
4. Registrul schemei: controlul evoluției și compatibilității sarcinii utile.
5. Observabilitate: valori, trasare, busteni, tablouri de bord de lag și filigrane.

Semantica și ordinea timpului

Preferați întotdeauna timpul evenimentului: acesta este singurul invariant pentru întârzieri și întreruperi.
Evenimentele pot ieși din ordine; comanda este garantată numai în cheia de partid.

Filigranele permit:

închideți ferestrele și emiteți rezultate;
limitați „cât de mult așteptăm” evenimente întârziate („allowed _ lateness”).
Pentru evenimente tardive, utilizați retracții/upserts: recalcularea agregatelor și evenimente corective.

Stare și fiabilitate

Starea cheie: datele agregatelor (sume, contoare, structuri pentru eliminarea duplicatelor) sunt amestecate de chei.
Checkpoint/Savepoint - instantanee periodice de stare pentru recuperare; savepoint - gestionat instantaneu pentru migrarea versiunii de cod.

Exact-o dată în vigoare se realizează:

tranzactional „read-processed-write” (comite chiuveta + read position);
chiuvete idempotente (upsert/fuziune) + tabele de eliminare a duplicatelor;
prin versionarea agregatelor (concurenta optimista).

Ferestre, agregări, se alăture

Ferestre:

Tumbling: rapoarte periodice simple (minut, oră).
Hopping/Alunecare: măsurători „glisante” (în 5 minute în trepte de 1 minut).
Sesiune: natural pentru sesiuni personalizate și anti-fraudă.
Agregări: sumă/număr/medie/aprox-distinct (HyperLogLog), percentile (TDistest/CKMS).
Stream-Stream se alăture: necesită tamponarea ambelor părți de cheie și de timp, respect 'allowed _ skew'.
Stream-Table se alăture (KTable) -Atașează un director sau starea curentă (de exemplu, „limite de utilizator activ”).

Lucrul cu date lagged și duplicate

Deduplicare: prin "event _ id' sau" (producer_id, secvență) "; Stocați cheile „văzute” cu TTL ≥ fereastra refăcută.
Evenimente târzii: Permiteți post-procesarea ferestrei pentru „X” după închidere (retracții/upserts).
Duplicate false: reglați agregatele idempotent și fixați „ALREADY_APPLIED” în jurnalele.

Scară și performanță

Key sharding: oferă paralelism; Uita-te pentru chei fierbinte.
Backpressure: limitați paralelismul, utilizați loturi și compresie la publicare.
Filigrane: Nu fi prea agresiv - filigranele tari reduc anticiparea, dar cresc proporția actualizărilor târzii.
Stare: selectați formatul (RocksDB/stat store/în memorie) luând în considerare dimensiunea și modelele de acces; curat TTL.
Autoscaling: prin lag, CPU, dimensiunea de stat, timp GC.

Fiabilitate și repornește

Chiuveta Idempotent sau tranzacția se angajează cu fixarea offset este baza corectitudinii.
Reprocesarea după repornire este permisă; efectul trebuie să rămână „exact o dată”.
DLQ/parcare: trimiteți înregistrări de probleme la un fir separat cu motive; asigură reprocesarea.

Observabilitate (ce se măsoară)

Lag de sursă (de timp și de mesaj).
Filigran/ora curentă a evenimentului și proporția evenimentelor târzii.
Operatori de debit/latență, p95/p99 end-to-end.
Dimensiunea de stat/rocksdb I/O, rata de checkpoint/durata.
Rata DLQ, procentul de eliminare/retractare.
CPU/GC/heap, pauză de timp.

Siguranță și conformitate

Clasificarea datelor: marcați PII/PCI în diagrame, stocați starea minimă, criptați și instantanee.
Controlul accesului: ACL-uri separate pentru tabelele de subiect/stat și pentru chiuvete.
Retenții: în conformitate cu cerințele legale (GDPR/dreptul de a fi uitat).
Audit: log 'event _ id',' trace _ id', rezultat: 'APLICAT/DEJA _ APLICAT/ACCESAT'.

Modele de implementare

1. CDC → normalizarea evenimentelor → domeniu: nu difuzați modificări de baze de date brute, hartă la fapte de afaceri ușor de înțeles.
2. Outbox pentru producători: tranzacție + eveniment - într-o singură tranzacție de baze de date.
3. Core vs Îmbogățit: sarcină utilă minimă în fluxul critic, îmbogățire - asincron.
4. Reluarea: proiecțiile/vitrinele trebuie reasamblate din jurnal.
5. Idempotency by design: operation/event key, upsert schemes, versiuni de agregate.

Testare

Unitate/Proprietate pe bază de: invarianți de agregate și transformări.
Teste în flux: flux de evenimente fix cu controale out-of-order și duplicate → fereastră și eliminare a duplicatelor.
Ferestre aurii: ferestre/agregate de referință și ajustări tardive admisibile.
Injecție defectuoasă: cădere între „efect înregistrat” și „compensare comisă”.
Teste replay: reasamblarea vitrinei de la începutul jurnalului = starea curentă.

Cost și optimizare

Ferestrele și filigranul afectează latența/resursele: cu cât este mai lungă fereastra și cu atât este mai mare 'allowed _ lateness', cu atât este mai mare starea.
Codecuri și compresie: echilibrați procesorul/rețeaua.
Batching de ieșire: mai puține apeluri de rețea și tranzacții.
Filtrarea timpurie ("pushdown'): aruncați excesul cât mai aproape de sursă.

Antipatterns

Legați la timpul de procesare în cazul în care este nevoie de timp eveniment → analize incorecte.
Lipsa idempotenței în chiuvetă → efecte duble la repornire.
Global „mega-chei”: o partiție fierbinte rupe paralelismul.
CDC-uri brute ca evenimente publice: scurgeri de scheme DB, fragilitate în evoluție.
Nu DLQ: mesajele „otrăvitoare” blochează întreaga conductă.
Întârziere fixă în loc de filigran: fie așteptare eternă sau pierdere de date.

Exemple de domenii

Plăți/Finanțe

Plata Stream ". ', ferestre pentru antifraudă (sesiune + CEP), bunicul prin' operation _ id'.
Efect exact o dată atunci când este postat în registrul contabil (upsert + versiune).

Marketing/Publicitate

Ferestre glisante de CTR/conversii, Alăturați-vă clicuri și impresii cu toleranță „± Δ t”, agregare pentru licitare.

iGaming/servicii online

Bilanț/limite în timp real, misiuni/realizări (ferestre de sesiune), modele antifraudă și alerte.

Mini șabloane (pseudo cod)

Fereastră cu filigrane și actualizări târzii

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)

Chiuveta tranzactionala cu fixare offset

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

Lista de verificare a producției

Timpul evenimentului și strategia filigranului definite; ferestre și 'allowed _ lateness' sunt selectate.
Chiuveta Idempotent sau tranzacție comite cu offset.
Schema de registru și moduri de compatibilitate sunt activate; evoluție aditivă.
Metrics: lag, filigran, p95/p99, DLQ, dimensiunea statului, durata punctului de control.
Teste: out-of-order, duplicate, repornește, reluare.
PII/politici de retenție pentru stat și instantanee.
Planul de scalare și strategii de backpressure.
Documentarea contractelor de ferestre și ajustări (actualizări târzii).

ÎNTREBĂRI FRECVENTE

Timpul necesar evenimentului?
Dacă corectitudinea măsurătorilor și consistența sunt importante, da. Timpul de procesare este potrivit pentru calcule tehnice/monitorizare, dar distorsionează analiza.

Este nevoie de exact-o dată?
Punct: pentru efecte critice. Mai des, cel puțin o dată + chiuveta idempotentă este suficientă.

Cum de a alege ferestre?
Bazați-vă pe SLA-uri de afaceri: "ultimele 5 minute" → hopping ", sesiuni de utilizatori →" sesiune ", rapoarte de minute →" rostogolire ".

Ce să faci cu datele târzii?
Permite ajustări limitate 'allowed _ lateness' și emiterea (upsert/retract). Caseta de prezentare a clientului trebuie să poată fi actualizată.

Total

Precum și latență scăzută, streaming este o disciplină de timp, condiție și contracte. Alegerea corectă a timpului evenimentului, a ferestrelor și a filigranelor, plus efectele idempotente, observabilitatea și testele fac conducta fiabilă, reproductibilă și economică - și oferă întreprinderilor soluții aici și acum, nu în fiecare noapte.