Event-Streaming და რეალური მონაცემები

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Event-Streaming არის მოვლენების დამუშავება და მიწოდება მათი გამოჩენის დროს. IGaming- ისთვის ეს ნიშნავს მყისიერ რეაქციას ფსონებზე, დეპოზიტებზე, ანტიფროგრამის სიგნალებზე, საპასუხისმგებლო თამაშის შეზღუდვებზე, პოზიციებზე და პერსონალურ ოფისებზე. ძირითადი აგური: მოვლენების ავტობუსი (Kafka/Pulsar), ნაკადის ძრავა (Flink/ksqlDB/Spark სტრუქტურული ნაკადი), CDC გარიგების BD (Debezium), Feature Store ონლაინ ML და რეალურ დროში ანალიტიკოსი (მატერიალიზებული წარმოდგენები, OLAP).

სად არის ეს კრიტიკულად iGaming

ანტიფროდიული და რისკი: გარიგების ესკალაცია <100-300 ms, ქცევითი შაბლონების კორელაცია, ბლოკირება და ესკალაცია.
საპასუხისმგებლო თამაში: ლიმიტების კონტროლი, ზარალის სიჩქარე, არანორმალური ქცევა - ალერტები და მანქანების შეზღუდვები რეალურ დროში.
გადახდები: სტატუსის სარქველები, webhooks PSP, smart-retry, ბალანსის პროექცია, SLA „დრო-ვალეტი“.
თამაშის დამნაშავეები: ტურნირების ლიდერების გაანგარიშება (sliding windows), ცოცხალი თამაშების რაუნდი, ნამდვილი ფირის დრო CRM/მარკეტინგისთვის.
პერსონალიზაცია: ონლაინ ფიჩები (RFM, propensity) - ტრიგერის კამპანიები, push/email წამში.
ოპერატიული ანალიტიკა: p95/p99 ლატვია, ძაბვის ნაბიჯების კონვერტაცია, პლატფორმის ჯანმრთელობის სიგნალები.

არქიტექტურული მოდელები

Lambda vs Kappa

Lambda: batch (DWH/ETL) + ნაკადი (ჭუჭყიანი). პლუს - მოქნილობა და „იაფი“ bach; მინუსი ორმაგი ლოგიკაა.
კაპა: ყველაფერი - როგორც ნაკადი ჟურნალიდან (კაფკა). პლუს - ერთი კოდი, მოვლენების რეიგერი; მინუსი - მკაცრი მოთხოვნები ინფრასტრუქტურისთვის.

პრაქტიკა: კრიტიკული რეალურ დროში კონტურებისთვის - კაპა; ანგარიშგებისთვის/ML ტრენინგი - დამატებითი batch კონტური.

ღონისძიების კონვეიერი (რეფერენდუმი)

1. მწარმოებლები: განაკვეთების/გადახდის სერვისები აქვეყნებენ დომენის მოვლენებს (outbox - Kafka).
2. ავტობუსი: კაფკა, რომელსაც აქვს გასაღებები ('player _ id', 'bet _ id').
3. CDC: Debezium იღებს ცვლილებებს OLTP (ბალანსები, ლიმიტები) ნაკადამდე.
4. ნაკადის დამუშავება: Flink/ksqlDB/Spark - აგრეგატები, ფანჯრები, CEP, join's.
5. პროგნოზები: მატერიალიზებული ცხრილები (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. მომხმარებლები: ანტიფროდი, CRM, შეტყობინებები, დაშბორდები, ტრიგერის ვორკფლოუ.

მონაცემთა ხელშეკრულებები და სქემები

Avro/Protobuf + Schema Registry: მკაცრი კონტრაქტები, backward Compatible მიგრაცია.
ვერსია: 'domain. event. v{n}`; კრძალავს დარღვევის ცვლილებებს.
PII: ტოკენიზაცია/დაშიფვრა, შენიღბვა, purpose limitation (GDPR).

მიწოდების სემანტიკა და იდემპოტენტობა

At-least-once - დე ფაქტო სტანდარტი (დუბლიკატები შესაძლებელია) სავალდებულოა პირადობის ჩამორთმევა.
Exactly-once ნაკადში: Kafka + EOS გარიგების მწარმოებლები Flink/Streams- ში; უფრო ძვირი, გამოიყენეთ წერტილოვანი (ფული/ბალანსი).
Outbox + CDC: ჭეშმარიტების ერთი წყარო BD- დან, ორმაგი ჩაწერისგან დაცვა.
Dedup: გასაღები ('idempotency _ key'), დედაპლაციის ცხრილი TTL- სთან, upsert/merge.

დროებითი ფანჯრები და „გვიანდელი“ მონაცემები

• Tumbling - ფიქსირებული სლოტები (მაგალითად, ბრუნვის წუთი).
• Hopping - მოძრაობს ნაბიჯით (მაგალითად, ფანჯარა 5 წუთის განმავლობაში 1 წუთის განმავლობაში).
• სესია - არააქტიურობით (მოთამაშის სესია).
• Watermarks: ღონისძიების დროის დამუშავება, „გვიან“ დაშვება, DLQ/side-output- ში ევაკუაცია.
• CEP (კომპლექსის ღონისძიების განვითარება): ნიმუშები „A შემდეგ B 3 წუთში“, „N მოვლენები M წამში“, „გაუქმება/ანაზღაურება“.

მდგომარეობა და სკალირება

Stateful ოპერატორები: აგრეგაციები/ჯოინები ინარჩუნებენ მდგომარეობას.
Changelog topics: სახელმწიფო საიმედოობა და აღდგენა.
Backpressure: სიჩქარის რეგულირება, sink/სისტემის შეზღუდვები.
გასაღებების განაწილება: ცხელი გასაღებები (heavy hitters) - key-salting, skew mitigation.

მონიტორინგი და SLO

SLO Stream: p99 end-to-end latency (მაგალითად, 2 წმ), დასაშვები consumer lag, წვდომა 99 ევრო. 9%.
მეტრიკა: throughput, lag ნაწილებად, watermark delay, drop/latio ratio, backpressure, busy time ოპერატორები, GC/JVM.
ალერტები: DLQ- ის ზრდა, watermark- ის ჩამორჩენა, EOS ჩეკპოინების წარუმატებლობა, ონლაინ/ოფლაინ ფიჩების რაზმები.
ტრეისი: კორელაციის ID ('trace _ id', 'message _ id') მწარმოებლის ნაკადის კონსიუმერის საშუალებით.

უსაფრთხოება და შესაბამისობა

TLS/MTLS, ACL/RBAC ტოპიკებზე/ცხრილებზე, მგრძნობიარე დომენების სეგმენტაცია (გადახდები/KUS).
PII დაშიფვრა ტრანზიტში/დისკზე; საიდუმლოებები Vault/SOPS.
Data retention & Docality: შენახვა რეგიონების მიხედვით (ევროკავშირი, თურქეთი, LatAm), წაშლის პოლიტიკა.
აუდიტი: ვინ გამოაქვეყნა/წაიკითხა, სკრიპტების რეპროდუქცია.

მაღალი წვდომა და DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', ჯვარედინი რეგიონალური რეპლიკაცია (MM2) DR- სთვის.
Flink/Streams: პერიოდული checkpoint + savepoint კონტროლირებადი გამოშვებისთვის; HA-JobManager.
OLAP: სეგმენტების რეპლიკაცია, read replicas; failover ტესტები (თამაშის დღე).

შესრულება და tuning

მწარმოებლები: batching ('linger. ms`, `batch. size '), კომპრესია (lz4/zstd).
Consumers: სწორი 'max. poll. interval ', წვეულებების პაუზა ბექოფში.
განაწილება: პარტიების ანგარიში სამიზნე TPS- დან და პარალელიზმიდან.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
ქსელი: 10/25G, TCP tuning, შეკავება n + 1 sink შეკითხვა.

განხორციელება: ძირითადი ტექნოლოგიები

ავტობუსი: Apache Kafka (ალტერნატივა: Pulsar, Redpanda).
ნაკადის დამუშავება: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC: Debezium (MySQL/Postgres), Outbox კონექტორები.
პროექციის საცავი: ksqlDB tables, Kafka Streams state store, Redis დაბალი ლატენტობისთვის, ClickHouse/Druid/Pinot OLAP- ისთვის.
Ichestor: Feast ან საკუთარი - ონლაინ (Redis) + offline (Parquet/BigQuery), კონსისტენციის გარანტია.

დიზაინის ნიმუშები

Outbox - Kafka: თითოეული დომენის მოვლენა BD გარიგებიდან.
საგა: კომპენსაცია მოვლენების გზით; ორკესტრი - ნაკადი.
Fan-out: ერთი მოვლენა - ანტიფროდი, CRM, ანალიტიკა, ნოტიფიკაცია.
Materialized Views: ლიდერები, ბალანსი, ლიმიტები - ნაკადიდან განახლებული ცხრილების სახით.
რეპროდუქცია: ტოპების რეპროდუცირება დანაყოფების/რეტრო ანალიტიკოსების გადაანგარიშებისთვის.

მაგალითები (კონცეფციები)

ksqlDB: ტურნირის ლიდერები (მოცურების ფანჯარა)

sql
CREATE STREAM bets_src (
bet_id VARCHAR KEY,
player_id VARCHAR,
amount DOUBLE,
ts BIGINT
) WITH (KAFKA_TOPIC='bets. placed. v1', VALUE_FORMAT='AVRO', TIMESTAMP='ts');

CREATE TABLE leaderboard AS
SELECT player_id,
SUM(amount) AS total_stake,
WINDOWSTART AS win_start,
WINDOWEND  AS win_end
FROM bets_src
WINDOW HOPPING (SIZE 10 MINUTES, ADVANCE BY 1 MINUTE)
GROUP BY player_id
EMIT CHANGES;

ფლინკი (ფსევდოდინამიკა): ანტიფროგრამული მორიელი

java stream
.assignTimestampsAndWatermarks(WatermarkStrategy. forBoundedOutOfOrderness(Duration. ofSeconds(10)))
.keyBy(e -> e. playerId)
.window(SlidingEventTimeWindows. of(Time. minutes(5), Time. minutes(1)))
.aggregate(scoreFunction, processWindow)
.sideOutputLateData(lateTag)
.addSink(riskTopic);

ნაკადის ხარისხის ტესტირება

სქემებისა და ევოლუციის კონტაქტური ტესტები (Schema Registry).
დატვირთვა: სამიზნე TPS, p99, ქცევა sink- ის დეგრადაციის დროს.
Failure/chaos: ბროკერების/კვანძების ვარდნა, ქსელის შეფერხება, split-brain.
Deterministic replays: ტოპიკის განმეორებითი პროგონი იგივე შედეგებს იძლევა.
კანარის ნაკადები: შეფერხებისა და მთლიანობის გადამოწმების კონტური.

ჩეკის განხორციელების სია

1. განსაზღვრეთ SLO (p99 E2E - X c, lag - Y, წვდომა - Z).
2. სტანდარტიზებული სქემები და გასაღებები (player _ id/bet _ id).
3. აირჩიე არქიტექტურა (კაპა კრიტიკული კონტურებისთვის).
4. კონფიგურაცია outbox + CDC და იზოლირება PII.
5. მიუთითეთ ფანჯრები, watermark, late-policy და DLQ/side outputs.
6. ჩართეთ EOS/idempotent ფულადი გზებზე.
7. შეიყვანეთ მონიტორინგი და ალერტები lag, watermark, DLQ.
8. უზრუნველყოს HA/DR და რეპროცესირების რეგულაციები.
9. განათავსეთ Feature Store და ონლაინ/ოფლაინის სინქრონიზაცია.
10. თამაშის დღის გატარება: წარუმატებლობისა და გამოჯანმრთელების განვითარება.

ანტიპატერები

ღონისძიების დრო და პროფესიის დრო შერევა ცნობიერი პოლიტიკის გარეშე.
Schema Governance- ის არარსებობა არის „გატეხილი“ გამოშვებები.
მონაცემთა და ცხელი გასაღებების უგულებელყოფა.
Replay სტრატეგიის არარსებობა და ტოპიკური ვერსიების ვერსია.
განაკვეთები/გადახდები idempotence და EOS გარეშე.

შედეგები

რეალურ დროში ნაკადი არ არის „კიდევ ერთი ტრანსპორტი“, არამედ აზროვნების მეთოდი: აფეთქების ღუმელის მოვლენები, მკაფიო SLO, მონაცემთა კონტრაქტები, ფანჯრები და მდგომარეობა, უსაფრთხოება და დაკვირვება. IGaming- ისთვის სტაბილური ნაკრებია Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. ეს იძლევა მილიწამურ რეაქციებს, ონლაინ/ოფლაინ ანალიტიკოსების კოორდინაციას და კონტროლირებად სირთულეს დატვირთვის გაზრდის დროს.