Analityka w czasie rzeczywistym

1) Cel i wartość biznesowa

• AML/Antifraud: strukturyzacja depozytów, ataki prędkości, transakcje ryzyka.
• Responsible Gaming (RG): przekroczenie limitów, wzorce ryzyka, samodzielne wykluczenie.
• SRE/Operacje: wczesne wykrywanie degradacji SLA, wybuchy błędów, przegrzanie klastra.
• Produkt i marketing: wyzwalacze personalizacji, misje/zadania, segmentacja w czasie rzeczywistym.
• Sprawozdawczość operacyjna: GGR/NGR w czasie zbliżonym do rzeczywistego, deski rozdzielcze hal/dostawców.

Cele: p95 end-to-end 0. 5-5 μ, kompletność ≥ 99. 5%, dostępność ≥ 99. 9%.

2) Architektura odniesienia

1. Ingest/Edge - '/events/batch '(HTTP/2/3), gRPC, OTel Collector; walidacja schematów, antydublikatów, tras geograficznych.
2. Autobus imprezowy - Kafka/Redpanda (udział 'user _ id/tenant/market', DLQ, retention 3-7 dni).
3. Przetwarzanie strumienia - Flink/Iskra Structured Streaming/Beam: stacjonarni operatorzy, CEP, znaki wodne, dozwolone opóźnienia, deadup.
4. Wzbogacanie online - Redis/Scylla/ClickHouse lookups (limity RG, KYC, BIN → MCC, IP → Geo/ASN), asynchroniczne połączenia z terminami i awaryjnym.
5. Obsługa - ClickHouse/Pinot/Druid (prezentacje operacyjne 1-5 minut), Sklep Funkcyjny (znaki online), haki/bilety/SOAR.
6. Lakehouse - brąz/srebro/złoto do długoterminowej konsolidacji, powtórzenia i pojednania.
7. Obserwowalność - mierniki rurociągów, śledzenie (OTel), kłody, linie i deski rozdzielcze.

3) Sygnały i taksonomia

Płatności: "płatność. wpłata/wypłata/obciążenie zwrotne ".
Gra: 'gra. bet/payout ', sesje.
Uwierzytelnianie i zachowanie: 'auth. login/failure', device-switch, speed.
Działanie: opóźnienie, szybkość błędów, ponowne uruchomienie paleniska, nasycenie.
Zgodność: kontrola sankcji, flagi RG, wydarzenia DSAR.

Każdy typ ma właściciela domeny, schemat, świeżość SLO i późną politykę danych.

4) Okna, znaki wodne i późne dane

Okna: tumbling (fixed), skakanie, sesja.
Znak wodny: granica „wiedza według czasu” (zwykle 2-5 min).
Opóźnione zdarzenia: dodatkowa kwestia korekt, flaga 'late = true', DLQ z dużym opóźnieniem.

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream.payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

5) CEP i agregacje statyczne

Klucz: 'user _ id',' device _ id', 'payment. account_id'.
Status: liczniki/sumy przesuwne, filtry bloom do deduplikacji, TTL.
Wzory CEP: strukturyzacja (<próg, ≥ N razy, na okno T), przełącznik urządzenia, zmęczenie RG.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6) Dokładnie raz, porządek i idempotencja

Dostawa co najmniej raz w autobusie + dedup przez 'event _ id' podczas przetwarzania (TTL 24-72 h).
Zamówienie: podział według klawiszy (lokalne zamówienie jest gwarantowane).
Zlew: commits transakcyjne (2-fazowe) lub idempotent upsert/merge.
Outbox/Inbox: transakcyjne publikowanie wydarzeń domeny z OLTP.

7) Sklep internetowy wzbogacania i funkcji

Wyszukiwanie: limity RG, statusy KYC, BIN → MCC, IP → Geo/ASN, rynki/podatki, FX w czasie imprezy.
asynchroniczne połączenia: sankcje/APP API z terminami; na błędzie - 'nieznany' + retray/cache.
Sklep funkcyjny: negocjacje online/offline; jedną bazę kodową transformacji.

8) Sklepy w czasie rzeczywistym i surfing

ClickHouse/Pinot/Druid: kruszywa druga/minuta, zmaterializowane widoki, SLA dla opóźnienia 1-5 min.
API/GraphQL: niskie opóźnienia dla desek rozdzielczych/widżetów.
Alerts: webhooks/Jira/SOAR z wzbogaconym kontekstem (trace_id, ostatnie wydarzenia).

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream.game_events
GROUP BY ts_min, market, provider_id;

9) Mierniki, SLI/SLO i deski rozdzielcze

• 95 pingest → alert ≤ 2 s (reguły krytyczne), ≤ 5 s (inne).
• Kompletność okna T ≥ 99. 5%; Okres ważności schematu ≥ 99. 9%; Zasięg śladowy ≥ 98%.
• Dostępność usługi strumieniowej ≥ 99. 9%; współczynnik opóźnienia ≤ 1%.

• Opóźnienie według stron/tematów; zajęty czas operatorów; wielkość stanu.
• Lejek „sobytiye → pravilo → klawisze”, precyzja/przypomnienie według domeny.
• Karta ciepła późno/kompletność; gorąca mapa kluczy.

10) Streaming DQ (jakość)

Najnowsze walidacje: schemat/enums/limit wielkości, anty-duplikaty.
Na strumieniu: kompletność/dup-rate/late-ratio, poprawność okna (bez podwójnego liczenia).
Polityka reakcji: krytyczne → DLQ + pager; major/minor → tagging + raport.

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

11) Prywatność, bezpieczeństwo i rezydencja

Minimalizacja PII: aliasing ID, maskowanie pola wrażliwego, tokenizacja PAN/IBAN.
Pobyt danych: rurociągi regionalne (EOG/UK/BR), poszczególne klucze KMS.
DSAR/RTBF: selektywna edycja na kolejnych sklepach; Legalne wstrzymanie spraw/sprawozdań.
Audyt: niezmienne dzienniki zmian dostępu/reguły, rejestrowanie zwolnień.

12) Ekonomia i wydajność

Shading/keys: unikać „gorących” klawiszy (solenie/kompozyt), równowaga stron.
Status: TTL, kompaktowe migawki, RocksDB/state backend tuning.
Wstępne agregacje: zmniejszenie na wczesnych etapach hałaśliwych tematów.
Pobieranie próbek: tylko dla mierników innych niż krytyczne (nie dla transakcji/zgodności).
Obciążenie zwrotne: Tematyka/budżet pracy, kwoty powielania i ciężkie wnioski.

13) Procesy i RACI

R: Streaming Platform (info/releases), Domain Analytics (zasady/funkcje), MLOps (scoring/Feature Store).
Odp.: Szef danych/ryzyka/zgodności według domeny.
C: DPO/Legal (PII/retencja), SRE (SLO/incydenty), Architektura.
I: Produkt, Wsparcie, Marketing, Finanse.

14) Plan działania w zakresie wdrażania

1. Tematy krytyczne Kafka/Redpanda + 2 (na przykład „płatności”, „auth”).

2. Zadanie kołnierza ze znakiem wodnym, deduplikacją i 1 regułą CEP (AML lub RG).

3. Prezentacja operacyjna w ClickHouse/Pinot (1-5 min), deski rozdzielcze lag/kompletności.

4. Kanał incydentów (webhaki/Jira), podstawowe SLO i wpisy.

• Wzbogacanie online (Redis/Scylla), sklep z funkcjami, asynchroniczne wyszukiwania.
• Zasady zarządzania jako kod, kanarka/A-B, streaming DQ.
• Regionalizacja przenośników, procedury DSAR/RTBF, blokada prawna dla spraw.

• Multi-region active-active, replay & what-if simulator, automatyczna kalibracja progowa.
• Sklepy ze złotym strumieniem (GGR/RG/AML), raportowanie w czasie zbliżonym do rzeczywistego.
• Deski rozdzielcze, obciążenie zwrotne, ćwiczenia DR.

15) Przykłady (fragmenty)

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT()      AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

16) Lista kontrolna przedsprzedaży

• Systemy/umowy w rejestrze, testy back-compat są zielone.
• W zestawie znak wodny/dozwolone opóźnienia, dedup, i DLQ.
• Skonfigurowane SLO i wpisy (lag/late/dup/state size).
• Wzbogacenie buforami i terminami; Fallback „nieznany”.
• RBAC/podwójna kontrola zasad/modeli; Aktywny dziennik zmian.
• Dokumentacja zasad/okna sklepowe; runbook'i replay/rollback.

17) Częste błędy i jak ich uniknąć

Ignoruj czas zdarzeń: bez znaków wodnych, metryki „unoszą się”.
Brak deduplikacji: fałszywe wpisy, podwójne liczenie.
Gorące klucze: zniekształcenie stron → solenie/odtworzenie.
Synchroniczne API z przodu w gorącej ścieżce: tylko async + cache.
Koszty niezagospodarowane: preagregacje, stany TTL, kwoty, monitorowanie kosztów.
Brak symulatora: rollouts bez powtórki → regresja.

18) Najważniejsze

Analityka w czasie rzeczywistym nie jest „szybka BI”, ale zarządzany obwód z kontraktami, logika statyczna, CEP, znaki wodne, wzbogacenie online i surowe SLO. Stosując te praktyki, platforma otrzymuje dokładne sygnały i decyzje w ciągu kilku sekund, zachowując zgodność, scenariusze produktów i odporność operacyjną po kontrolowanych kosztach.