Event-Streaming және real-time деректері
(Бөлім: Технологиялар және Инфрақұрылым)
Қысқаша түйіндеме
Event-Streaming - оқиғалар пайда болған кезде оларды өңдеу және жеткізу. iGaming үшін бұл мөлшерлемелерге, депозиттерге, антифрод-сигналдарға, жауапты ойынның лимиттеріне, турнирлік кестелерге және дербес офферлерге жедел реакцияны білдіреді. Базалық кірпіштер: оқиға шинасы (Kafka/Pulsar), ағынды өңдеу қозғалтқышы (Flink/ksqlDB/Spark Structured Streaming), транзакциялық ДБ-дан CDC (Debezium), онлайн-ML және real-time талдауы үшін Feature Store (материалданған көріністер, OLAP).
Бұл iGaming сыни жерде
Антифрод және тәуекел: <100-300 мс транзакциялардың скорингі, мінез-құлық үлгілерінің корреляциясы, бұғаттау және эскалация.
Жауапты ойын: лимиттерді бақылау, жоғалту жылдамдығы, аномальды мінез-құлық - нақты уақыттағы алерттар мен авто-шектеулер.
Төлемдер: мәртебе вентильдері, webhooks PSP, smart-retry, баланс проекциялары, SLA «time-to-wallet».
Ойын іс-шаралары: турнир көшбасшыларының есебі (sliding терезелер), live-ойындар раундтары, CRM/маркетинг үшін real-time лентасы.
Дербестендіру: онлайн-фичтер (RFM, propensity) → секундтық триггерлік науқан, push/email.
Жедел талдау: p95/p99 latency, құйғыштың қадамдарын конверсиялау, платформаның health-сигналдары.
Сәулет модельдері
Lambda vs Kappa
Lambda: batch (DWH/ETL) + streaming (оперативті). Плюс - икемділік және «арзан» бэч; минус - қосарланған логика.
Kappa: барлығы - журналдағы ағын сияқты (Kafka). Плюс - бірыңғай код, оқиғалар реиграсы; минус - инфрақұрылымға қойылатын талаптардан қатал.
Практика: күрделі real-time контурлары үшін - Kappa; есеп беру/ML-оқыту үшін - қосымша batch-контур.
Оқиғалар конвейері (референс)
1. Өндірушілер: ставкалар/төлемдер сервистері домендік оқиғаларды жариялайды (outbox → Kafka).
2. Шина: Кілттер бойынша партиялары бар Kafka ('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, хабарламалар, дашбордтар, триггерлік воркфлоу.
Деректер келісімшарттары мен схемалары
Euro/Protobuf + Schema Registry: қатаң келісімшарттар, backward-compatible көші-қон.
Нұсқалау: 'domain. event. v{n}`; бұзатын өзгерістерге тыйым салу.
PII: токенизация/шифрлау, бүркемелеу, purpose limitation (GDPR).
Жеткізу семантикасы және іспеттілігі
At-least-once - де-факто стандарт (көшірмелері болуы мүмкін) → міндетті idempotent-handling.
Exactly-once стримингте: Flink/Streams-те Kafka + EOS транзакциялық продюсерлері; қымбат, нүктелі қолданыңыз (ақша/баланс).
Outbox + CDC: сервистің ДБ-дан бірыңғай шындық көзі, қосарланған жазбадан қорғау.
Dedup: кілт ('idempotency _ key'), TTL бар дедупликация кестесі, upsert/merge.
Уақытша терезелер және «кеш» деректер
Терезелер:- Tumbling - тіркелген слоттар (мысалы, айналым минуты).
- Hopping - адыммен сырғанайтын (мысалы, 1 мин адыммен 5 мин терезе).
- Session - белсенділігі бойынша (ойыншының сессиясы).
- Watermarks: event-time бойынша өңдеу, «кеш ағаштарды» жіберу (lateness), DLQ/side-output көшіру.
- CEP (Complex Event Processing): «A содан кейін 3 минутта В», «M секунд ішінде оқиғаның N», «күшін жою/өтемақы» үлгілері.
Күйі және масштабтау
Stateful операторлары: агрегаттар/джойндар күйін сақтайды (RocksDB state backend).
Changelog topics: сенімділік және қалпына келтіру.
Backpressure: жылдамдықты автоматты реттеу, sink/ жүйесіне лимиттер.
Кілттерді бөлу: ыстық кілттер (heavy hitters) → key-salting, skew mitigation.
Мониторинг және SLO
SLO ағыны: p99 end-to-end latency (мысалы, ≤ 2 с), рұқсат етілген consumer lag, қол жетімділік ≥ 99. 9%.
Өлшемдер: throughput, партия бойынша lag, watermark delay, drop/late ratio, backpressure, busy time операторлары, GC/JVM.
Алерттар: DLQ өсуі, watermark артта қалуы, EOS чек пункттерінің сәтсіздігі, онлайн/оффлайн фичтері.
Трейсинг: кореляциялық ID ('trace _ id', 'message _ id') арқылы продьюсер-стрим-консьюмер.
Қауіпсіздік және комплаенс
TLS/MTLS, ACL/RBAC топиктерге/кестелерге, сезімтал домендерді сегменттеу (төлемдер/АКЖ).
Транзиттегі/дискідегі PII шифрлау; Vault/SOPS құпиялары.
Data retention & locality: аймақтар бойынша сақтау (ЕО, Түркия, ЛатАм), жою полисі.
Аудит: кім жариялаған/оқыған, сценарийлердің жаңғыртылуы.
Жоғары қолжетімділік және DR
Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', DR үшін кросс-аймақтық репликация (MM2).
Flink/Streams: бақыланатын релиздерге арналған мерзімді checkpoint + savepoint; HA-JobManager.
OLAP: сегменттерді репликалау, read replicas; failover (game day) тестілері.
Өнімділік және тюнинг
Продюсерлер: batching ('linger. ms`, `batch. size '), компрессия (lz4/zstd).
Консьюмерлер: дұрыс 'max. poll. interval ', бэкоф кезінде партияның үзілісі.
Партияландыру: мақсатты TPS және параллелизмнен тұратын партиялардың есебі.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Network: 10/25G, TCP-тюнинг, 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 үшін.
Фичестор: Feast немесе меншікті - онлайн (Redis) + офлайн (Parquet/BigQuery), консистенттілік кепілдігі.
Жобалау үлгілері
Outbox → Kafka: БД транзакциясынан әрбір домендік оқиға.
Сағалар: оқиғалар арқылы өтемақы; оркестрлеу - ағыммен.
Fan-out: бір оқиға → антифрод, CRM, талдау, нотификация.
Materialized Views: көшбасшы борттар, баланс, лимиттер - ағымнан жаңартылатын кестелер түрінде.
Reprocessing: агрегаттарды/ретро-талдауды қайта санау үшін топиктерді шығару.
Мысалдар (тұжырымдамалар)
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;Flink (жалған код): late-events-пен антифрод-скоринг
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);Ағындардың сапасын тестілеу
Схемалар мен эволюцияның Contract-тестілері (Schema Registry).
Жүктеме: мақсатты TPS, p99, sink деградациясы кезіндегі мінез-құлық.
Failure/chaos: брокерлердің/түйіндердің құлдырауы, желілік кідірістер, split-brain.
Deterministic replays: топиктерді қайталау → бірдей нәтижелер.
Canary ағындары: кідіріс пен тұтастықты тексеру контуры.
Енгізу чек-парағы
1. SLO (p99 E2E ≤ X c, lag ≤ Y, қол жетімділік ≥ Z) анықтау.
2. Схемалар мен кілттерді стандарттау (player_id/bet_id).
3. Архитектурасын таңдау (күрделі контурлар үшін Kappa).
4. outbox + CDC баптау және PII оқшаулау.
5. Терезелерді орнату, watermark, late-policy және DLQ/side outputs.
6. EOS/ақша жолдарындағы теңсіздікті қосу.
7. lag, watermark, DLQ-ға мониторинг пен алерталар енгізу.
8. HA/DR және reprocessing регламенттерін қамтамасыз ету.
9. Feature Store және онлайн/офлайн үндестіруді өрістету.
10. Game-day өткізу: істен шығу және қалпына келтіру.
Антипаттерндер
Түсінікті саясатсыз event-time және processing-time араластыру.
schema governance → «сындыратын» релиздердің болмауы.
late data және «ыстық кілттерді» елемеу.
Топиктердің replay-стратегиясы мен нұсқасының болмауы.
Idempotency және EOS-сыз ставкалар/төлемдер.
Real-time стриминг - бұл «тағы бір көлік» емес, ойлау тәсілі: домендік оқиғалар, нақты SLO, деректер келісімшарттары, терезелер мен жай-күй, қауіпсіздік және бақылау. iGaming үшін тұрақты жиынтық - Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Ол миллисекундтық реакцияларды, онлайн/офлайн талдаудың үйлесімділігін және жүктеменің өсуі кезінде бақыланатын қиындықты береді.