ნაკადის და ნაკადის ანალიტიკა

1) დანიშნულება და ღირებულება

• ანტიფროდი/AML: დეპოზიტების სტრუქტურის იდენტიფიცირება, velocity შეტევები, პროვაიდერების ანომალიები.
• Responsible Gaming (RG): ლიმიტების ჭარბი რაოდენობა, რისკის შაბლონები, თვითკმაყოფილება.
• ოპერაციები/SRE: SLA დეგრადაცია, შეცდომების ვარდნა, ინციდენტების ადრეული სიგნალები.
• პროდუქტი/მარკეტინგი: პერსონალიზაციის მოვლენები, მისიები/სტუმარი, რეალური დროის სეგმენტი.
• ანგარიშები რეალურ დროში: GGR/NGR ფანჯრები, ოპერაციული პანელები.

მიზნობრივი მახასიათებლები: p95 end-to-end 0. 5-5 ს, სისრულე 99. 5%, მართვადი ღირებულება.

2) სტანდარტული არქიტექტურა

1. Ingest/Edge

`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
სქემების შესაბამისობა, ანტი-დუბლიკატები, გეო-მარშრუტიზაცია.

2. მოვლენების საბურავი

Kafka/Redpanda (განაწილება 'user _ id/tenant/barket').
Retention 3-7 დღე, კომპრესია, DLQ/„ კარანტინი “„ გატეხილი “შეტყობინებებისთვის.

3. ნაკადის დამუშავება

Flink / Spark Structured Streaming / Beam.
Stateful ოპერატორები, CEP, watermark, allowed lateness, deduplication.
გამდიდრება (Redis/Scylla/ClickHouse-Lookup), ასინქრონული I/O ტაიმაუტებით.

4. სერვინგი/ოპერატიული ფანჯრები

ClickHouse/Pinot/Druid წუთიერი/წამიანი აგრეგაციისთვის და დაშბორდებისთვის.
Feature Store (ონლაინ) მოდელების სკრინინგისთვის.
ალერტის ტოპები - SOAR/ticketing/webhuks.

5. გრძელვადიანი შენახვა (Lakehouse)

Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Replay/bectests, time-travel.

6. დაკვირვება

Payplines, tracing (OTel), logs, lineage.

3) სქემები და კონტრაქტები

Schema-first: JSON/Avro/Protobuf + Registry, 'schema _ version' თითოეულ ღონისძიებაში.
ევოლუცია: უკუკავშირი - ახალი არალეგალური ველები; breaking - '/v2 '+ ორმაგი გამოცემა.
სავალდებულო ველები: 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id`, `market`, `source`.

4) Windows, watermarks და დაგვიანებული მონაცემები

• Tumbling (ფიქსირებული), Hopping (გადახურვით), Session (არააქტიურობისთვის).
• Watermark: „ცოდნის“ ბარიერი ღონისძიების დროში; მაგალითად, 2-5 წუთი.
• მოკლე მონაცემები: კორექტირების დამატებითი გამოცემა, „late = true“, DLQ ძლიერი ჩამორჩენის დროს.

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) Stateful აგრეგაცია და CEP

საკვანძო: 'user _ id', 'device _ id', 'payment. account_id`.
მდგომარეობა: მოცურების თანხები/მრიცხველები, სესიები, bloom ფილტრები ბაბუისთვის.
CEP ნიმუშები: სტრუქტურა (<ბარიერი, N ჯერ, T ფანჯრის უკან), მოწყობილობები-switch, RG-fatigue.

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) Exactly-Once, წესრიგი და იდემპოტენტობა

საბურავი: at-least-once + გარიგების გასაღებები უზრუნველყოფს ადგილობრივ წესრიგს.
Idempotence: 'event _ id' + dedup state (TTL 24-72 საათი).
Sink: გარიგების კომუნები (2-ფაზა) ან upsert/merge-idempotence.
Outbox/Inbox: გარანტირებული დომენის პუბლიკაცია OLTP- დან.

7) რეალურ დროში გამდიდრება

Lookup: Redis/Scylla (RG ლიმიტები, KYC სტატუსი, BIN, MCC, IP, Geo/ASN).
ასინქრონული გამოწვევები: სანქციები/REP API ტაიმაუტებით და fallback („unknown“).
FX/timeson: თანხების ნორმალიზაცია და ადგილობრივი ბაზრის დრო ('fx _ source', 'tz').

8) Serving და რეალურ დროში ვიტრინები

ClickHouse/Pinot/Druid: აგრეგაციები წუთში/წამში, materialized views.
Gold-stream: ოპერაციული ცხრილები GGR/RG/AML, SLA დაგვიანებით 1-5 წთ.
API/GraphQL: დაბალი ლატენტობა დაშბორდებისა და გარე ინტეგრაციებისთვის.

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) დაკვირვება და SLO

• p95 ingest alert 2 c (კრიტიკულად), 5 c (დანარჩენი).
• Completeness ფანჯარა T-99. 5%.
• სქემების შეცდომები 0. 1%; 'trace _ id' მოვლენების წილი 98% -ს შეადგენს.
• Stream სერვისის ხელმისაწვდომობა 99. 9%.

• წვეულებები/ტოპიკა, busy time ოპერატორები, სახელმწიფოს ზომა.
• ძაბრი „მოვლენა - წესი - შემთხვევა“, „ცხელი“ გასაღებების ბარათი, ლათ-რატიო.
• ღირებულება: cost/GB, cost/query, chekpoints/reples ღირებულება.

10) კონფიდენციალურობა და შესაბამისობა

PII მინიმიზაცია: ID ფსევდონიზაცია, ველების შენიღბვა, PAN/IBAN ტოქსიკაცია.
მონაცემების რეზიდენცია: რეგიონალური კონვეიერები (EEA/UK/BR), დაშიფვრის ცალკეული გასაღებები.
იურიდიული ოპერაციები: DSAR/RTBF downstream ფანჯრებზე, იურიდიული ჰოლდი საქმეების/მოხსენებების შესახებ.
აუდიტი: წვდომის ლოგოები, გადაწყვეტილებების უცვლელი არქივები.

11) ეკონომიკა და პროდუქტიულობა

გასაღებები და შარდინგი: თავიდან აიცილეთ „ცხელი“ გასაღებები.
მდგომარეობა: გონივრული TTL, Snaphots, tuning RocksDB/backend state.
წინამორბედი: up-front reduce ხმაურიანი ნაკადებისთვის.
Sampling: მაგალითად, არაკრიტიკულ მეტრიკებზე (არა გარიგებებზე/შესაბამისობაში).
Chargeback: ბიუჯეტები თემებზე/ჯობებზე, კვოტებზე და ალოკაცია გუნდებზე.

12) ნაკადი DQ (ხარისხი)

Ingest schema (shema, enums, size), dedup '(event _ id, წყარო) ".
ნაკადზე: completeness/dup-rate/late-ratio, ფანჯრების კონტროლი (არ არსებობს ორმაგი აღრიცხვა).
რეაქციის პოლიტიკოსები: კრიტიკული, DLQ + ალერტი; major/minor - ჭდეები და შემდგომი გაწმენდა.

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) წვდომის უსაფრთხოება და კონტროლი

RBAC/ABAC: ნაკადების კითხვის ცალკეული როლები, წესების/მოდელების შეცვლა.
ორმაგი კონტროლი: წესების და მოდელების ამოღება „2 გასაღების“ საშუალებით.
Canary/A/B: წესებისა და მოდელების მუქი გაშვება, precision/recall- ის კონტროლი.
საიდუმლოებები: KMS/CMK, რეგულარული როტაცია, ლოგებში საიდუმლოების აკრძალვა.

14) პროცესები და RACI

R (Responsible): Streaming Platform (inframing/გამოშვებები), Domain Analytics (წესები/ფიჩები), MLOps (სკორინგი).
A (Accountable): მონაცემთა/Risk/დომენის კომპლექსი.
C (Consulted): DPO/Legal (PII/retention), SRE (SLO/ინციდენტები), არქიტექტურა.
I (Informed): პროდუქტი, მხარდაჭერა, მარკეტინგი, ფინანსები.

15) გზის განხორციელების რუკა

1. Kafka/Redpanda + ორი კრიტიკული ტოპიკა ('payments', 'auth').

2. Flink Joba ერთად watermark, dup და ერთი CEP წესი (AML ან RG).

3. ClickHouse/Pinot ვიტრინა 1-5 წთ, დაშბორდები lag/completeness.

4. ინციდენტის არხი (ვებჰუკი/ჯირა), ძირითადი SLO და ალერტები.

• ონლაინ გამდიდრება (Redis/Scylla), Feature Store, asinchron lookups.
• წესების მართვა, როგორც კოდი, კანარის გამოშვებები, A/B.
• ნაკადი DQ, კონვეიერის რეგიონალიზაცია, DSAR/RTBF პროცედურები.

• აქტიური აქტიური მულტფილმის რეგიონი, What-if რეპლიკის სიმულატორი, რეიდების მანქანის კალიბრი.
• სრულფასოვანი Gold-stream ფანჯრები (GGR/RG/AML), near-real-time ანგარიშები.
• ღირებული დაშბორდები, chargeback, DR სწავლებები.

16) მაგალითები (ფრაგმენტები)

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);
}

17) ჩეკის სია გაყიდვამდე

• სქემები და კონტრაქტები Registry, back compat ტესტები მწვანეა.
• ჩართულია watermark/allowed lateness, dedup და DLQ.
• SLO და ალერტები (lag/late/dup/state size).
• გამდიდრება ქეშებითა და ტაიმაუტებით, fallback „unknown“.
• RBAC/ორმაგი კონტროლი წესებზე/მოდელზე, ყველა ცვლილების გაუმჯობესება.
• დოკუმენტაცია წესების, ფანჯრის ფანჯრისა და runbook 'და replay/გამოტოვების შესახებ.

18) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ღონისძიების დროის უგულებელყოფა: watermarks- ის გარეშე, მეტრიკა „ბანაობს“.
არ არსებობს ბაბუა: ყალბი ალერტები და ორმაგი აღრიცხვა.
ცხელი გასაღებები: პარტიების გადალახვა - გადახრა/აღდგენა.
სინქრონული გარე API ცხელ გზაზე: მხოლოდ ასინკ + ქეში.
უკონტროლო ღირებულება: წინასწარი აგრეგაცია, TTL სახელმწიფოები, კვოტები, cost dashbords.
სიმულატორის არარსებობა: გაშვება „replay“ გარეშე იწვევს რეგრესიებს.

19) გლოსარიუმი (მოკლედ)

CEP - Complex Event Processing (მოვლენების ნიმუშები).
Watermark არის ფანჯრის მზადყოფნის საზღვარი ღონისძიების დროში.
Allowed Lateness - დაგვიანებული მოვლენების დაშვება.
Stateful Operator - შენარჩუნებული მდგომარეობის ოპერატორი.
Feature Store არის შეთანხმებული სიმბოლოების სერვინგი (ონლაინ/ოფლაინ).

20) შედეგი

ნაკადის და ნაკადის ანალიტიკა არის კონტროლირებადი სისტემა: კონტრაქტები, ფანჯრები და watermarks, სახელმწიფო ლოგიკა და CEP, გამდიდრება და რეალური დროის ფანჯრები, SLO და დაკვირვება, კონფიდენციალურობა და კონტროლი. აღწერილი პრაქტიკის შემდეგ, პლატფორმა იღებს საიმედო რისკის დეტექტორებს, ოპერატიულ პანელებს და პერსონალიზაციას პროგნოზირებადი ლატენტობით და ხარჯებით.