GH GambleHub

Streaming i streaming analytics

1) Cel i wartość

Obwód strumieniowy zapewnia podejmowanie decyzji podczas lotu:
  • Antifraud/AML: identyfikacja struktury depozytów, ataków prędkości, anomalii dostawców.
  • Responsible Gaming (RG): przekroczenie limitów, wzorce ryzyka, samodzielne wykluczenie.
  • Operacje/SRE: degradacja SLA, wybuchy błędów, wczesne sygnały incydentów.
  • Produkt/marketing: wydarzenia personalizacyjne, misje/zadania, segmentacja w czasie rzeczywistym.
  • Raportowanie w czasie zbliżonym do rzeczywistego: prezentacje GGR/NGR, panele operacyjne.

Charakterystyka docelowa: p95 end-to-end 0. 5-5 s, kompletność ≥ 99. 5%, wartość zarządzana.


2) Architektura odniesienia

1. Połknięcie/krawędź

'/events/batch '(HTTP/2/3), gRPC, OTel Collector.
Walidacja schematów, antydublikatów, geo-routingu.

2. Autobus imprezowy

Kafka/Redpanda (podzielona przez 'user _ id/najemca/market').
Zatrzymanie 3-7 dni, kompresja, DLQ/” kwarantanna„ dla ”złamanych„ wiadomości.

3. Przesyłanie strumieniowe

Kołnierz/iskra ustrukturyzowane strumieniowanie/wiązka.
Stanowcze oświadczenia, CEP, znak wodny, dozwolone opóźnienia, deduplication.
Wzbogacenie (Redis/Scylla/ClickHouse-Searup), asynchroniczne I/O z terminami.

4. Serwowanie/wyświetlacze operacyjne

ClickHouse/Pinot/Druid na minutę/sekundę agregacji i deski rozdzielcze.
Funkcja Sklep (online) dla modeli punktacji.
Tematy alarmowe → SOAR/biletów/haków internetowych.

5. Składowanie długoterminowe (Lakehouse)

Brąz (surowy), srebro (czysty), złoto (służyć) - parkiet + delta/góra lodowa/hudi.
Powtórka/backtests, podróż w czasie.

6. Obserwowalność

Mierniki rurociągów, śledzenie (OTel), kłody, linie.


3) Systemy i umowy

Schema-first: Rejestr JSON/Avro/Protobuf +, 'schema _ version' w każdym zdarzeniu.
Ewolucja: kompatybilne z powrotem - nowe nieważne pola; breaking - '/v2 '+ podwójna publikacja.
Wymagane pola to 'event _ time' (UTC), 'event _ id',' trace _ id', 'user. pseudo_id', „rynek”, „źródło”.


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

Okna:
  • Tumbling, Hopping, Session.
  • Znak wodny: próg „wiedzy” w czasie zdarzeń; np. 2-5 minut.
  • Późne dane: korekty wstępne, „late = true”, DLQ z mocnym opóźnieniem.
Przykład Flink SQL (10-min prędkości depozytu):
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) Agregacje statyczne i CEP

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

Kod pseudo CEP:
python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

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

Autobus: przynajmniej raz + klucze partycji zapewniają lokalne zamówienie.
Idempotencja: 'event _ id' + dedup state (TTL 24-72 h).
Zlew: commits transakcyjne (2-fazowe) lub upsert/merge-idempotence.
Skrzynka odbiorcza/skrzynka odbiorcza: gwarantowana publikacja wydarzeń domeny z OLTP.


7) Wzbogacanie w czasie rzeczywistym

Wyszukiwanie: Redis/Scylla (limity RG, status KYC, BIN → MCC, IP → Geo/ASN).
Połączenia asynchroniczne: sankcje/APP API z terminami i awaryjnymi („nieznane”).
FX/timezon: normalizacja kwot i czasu lokalnego rynku („fx _ source”, „tz”).


8) Serwowanie i sklepy w czasie rzeczywistym

ClickHouse/Pinot/Druid: agregacje według minut/sekund, zmaterializowane widoki.
Strumień złota: tabele operacyjne GGR/RG/AML, SLA dla ≤ opóźnienia 1-5 min.
API/GraphQL: niskie opóźnienia dla desek rozdzielczych i integracji zewnętrznych.

Przykład ClickHouse (GGR minutę po minucie):
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) Obserwowalność i SLO

SLI/SLO (punkty orientacyjne):
  • pingest 95 → alert ≤ 2 s (krytyczny), ≤ 5 s (bilans).
  • Kompletność okna T ≥ 99. 5%.
  • Błędy schematu ≤ 0. 1%; Odsetek zdarzeń o 'trace _ id' ≥ 98%.
  • Dostępność usługi strumieniowej ≥ 99. 9%.
Deski rozdzielcze:
  • Lags party/topic, ruchliwy czas operatorów, rozmiar stanu.
  • Lejek „sobytiye → pravilo → klucze”, mapa „gorących” klawiszy, późny stosunek.
  • Koszt: koszt/GB, koszt/zapytanie, koszt punktów kontrolnych/powtórzeń.

10) Prywatność i zgodność

Minimalizacja PII: pseudonimizacja ID, maskowanie pola, tokenizacja PAN/IBAN.
Pobyt danych: rurociągi regionalne (EOG/UK/BR), indywidualne klucze szyfrujące.
Operacje prawne: DSAR/RTBF w sklepach niższego szczebla, Legal Hold for cases/reports.
Audyt: dzienniki dostępu, niezmienne archiwa rozwiązań.


11) Ekonomia i wydajność

Klucze i shading: Unikaj „gorących” klawiszy (solenie/klucz kompozytowy).
Warunek: rozsądny TTL, migawki, dostrajanie RocksDB/stan oparcia.
Preagregacja: redukcja z przodu dla hałaśliwych strumieni.
Pobieranie próbek: ważne na miernikach innych niż krytyczne (nie na transakcjach/zgodności).
Obciążenie zwrotne: budżety na tematy/miejsca pracy, kwoty i przydział zespołu.


12) Streaming DQ (Jakość)

Najwłaściwsza walidacja (schemat, enumy, rozmiar), dedup '(event_id, źródło)'.
Na strumieniu: kompletność/dup-rate/late-ratio, kontrola okien (bez podwójnego liczenia).
Polityka reakcji: krytyczne → DLQ + alert; major/minor → tag, a następnie wyczyścić.

Zasady minimalne (YAML, przykład):
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

13) Kontrola bezpieczeństwa dostępu i uwalniania

RBAC/ABAC: oddzielne role do odczytu wątków, zmiany zasad/modeli.
Podwójna kontrola: rollouts reguł i modeli przez „2 klucze”.
Canary/A/B: ciemna reguła i działa modelu, kontrola precyzji/wycofania.
Sekrety: KMS/CMK, regularny obrót, zakaz tajemnic w dziennikach.


14) Procesy i RACI

R (Responsible): Streaming Platform (infra/releases), Domain Analytics (zasady/funkcje), MLOp (scoring).
A (Odpowiedzialność): Szef danych/ryzyka/zgodności według domeny.
C (Konsultacja): DPO/Legal (PII/retencja), SRE (SLO/Incydenty), Architektura.
I (Poinformowany): Produkt, Wsparcie, Marketing, Finanse.


15) Plan działania w zakresie wdrażania

MVP (2-4 tygodnie):

1. Kafka/Redpanda + dwa krytyczne tematy ('płatności', 'auth').

2. Zadanie flink ze znakiem wodnym, deduplication i jedną regułą CEP (AML lub RG).

3. ClickHouse/Pinot prezentuje 1-5 min, deski rozdzielcze lag/kompletność.

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

Faza 2 (4-8 tygodni):
  • Wzbogacanie online (Redis/Scylla), sklep z funkcjami, asynchroniczne wyszukiwania.
  • Zarządzanie regułami jako kod, wydania kanarkowe, A/B.
  • Streaming DQ, regionalizacja rurociągów, procedury DSAR/RTBF.
Faza 3 (8-12 tygodni):
  • Multi-region active-active, co-if replay simulator, automatyczna kalibracja progów.
  • Pełne prezentacje Gold-stream (GGR/RG/AML), raportowanie w czasie zbliżonym do rzeczywistego.
  • Deski rozdzielcze, obciążenie zwrotne, ćwiczenia DR.

16) Przykłady (fragmenty)

Flink CEP - przełącznik urządzenia:
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
Kafka Streams - idempotent filter:
java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

17) Lista kontrolna przedsprzedaży

  • Systemy i 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 z pamięci podręcznej i timeouts, fallback „nieznane”.
  • RBAC/dual-control to rules/models, wszystkie zmiany są rejestrowane.
  • Zasady, sklepy i dokumentacja runbook i powtórka/rollback.

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

Ignoruj czas zdarzeń: bez znaków wodnych, metryki „unoszą się”.
Brak deduplikacji: fałszywe wpisy i 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, deski rozdzielcze.
Brak symulatora: rollouts bez „powtórzyć” prowadzić do regresji.


19) Słownik (krótki)

CEP - Kompleksowe przetwarzanie zdarzeń.
Znak wodny - limit gotowości okna według czasu zdarzenia.
Dopuszczalna Lateness - tolerancja późnych wydarzeń.
Statious Operator - operator o zapisanym stanie.
Funkcja Sklep - skoordynowana funkcja surfingu (online/offline).


20) Sedno sprawy

Streaming i streaming analytics to zarządzany system: kontrakty, okna i znaki wodne, logika statyczne i CEP, wzbogacanie i w czasie rzeczywistym sklepów, SLO i obserwowalność, prywatność i wartość pod kontrolą. Stosując opisane praktyki, platforma otrzymuje niezawodne wykrywacze ryzyka, panele operacyjne oraz personalizację z przewidywalnym opóźnieniem i kosztami.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.