რეალურ დროში ინსაითები

1) რა არის რეალურ დროში ინსაითი

რეალურ დროში ინსაითი არის დადასტურებული განცხადება პროცესის/მომხმარებლის/სისტემის ამჟამინდელი მდგომარეობის შესახებ, რომელიც ჩნდება მიზნობრივი შეფერხების (ლატენტობის) ფარგლებში, რომელიც საკმარისია გადაწყვეტილების მისაღებად (წამი-წუთი).
მიკროსქემის ფორმულა: მოვლენა - გამდიდრება/აგრეგაცია/გამოსავალი/რეკომენდაცია: მოქმედება: გამოხმაურება.

მაგალითები: გარიგების ანტიფროზი (500 ms ევრო), SLO სერვისის ალერტი (60 წმ), პირადი რეკომენდაცია გვერდზე (200 ms ევრო), დინამიური პრაიმერი (5 წმ), კამპანიის მონიტორინგი (1 წუთი).

2) პალმის არქიტექტურა

1. Ingest: მოვლენების ბროკერი (Kafka/Pulsar/NATS/MQTT), სქემების კონტრაქტები (Avro/Protobuf), idempotence გასაღებები.
2. ნაკადის დამუშავება (CEP/Stream): Flink/Spark სტრუქტურული Streaming/ksqlDB; ფანჯრები, watermarks, stateful ოპერატორები.
3. ონლაინ ფიჩები და მდგომარეობა: Feature Store (ონლაინ) + ქეში/TSDB (RocksDB/Redis) სწრაფი join/lookup.
4. ონლაინ სკორინგი/წესები: მოდელები (ONX/TF-Lite/XGB), rule ძრავა, კონტექსტი.
5. ინსაითების სერვინგი: დაბალი დონის API, ვებჰუკი, ბრძანების საბურავები (მოქმედება ბუსი), ადაპტირებული დაშბორდები.
6. NTAR/ნამდვილი დროის ფანჯრები: სავარაუდო მატერიალიზაცია (ClickHouse/Pinot/Druid/Delta + CDC).
7. დაკვირვება და SLO: ლატენტობის/ლაგონების/შეცდომების მეტრიკა, კვალი, ალერტები.
8. მენეჯმენტი და უსაფრთხოება: OTA/fich დროშები, RLS/CLS, შენიღბვა, აუდიტი.

3) დროებითი მოდელი: ფანჯრები, watermarks, დაგვიანებული

ფანჯრები: tumbling/sliding/session; ვიტრინისთვის - ჰიბრიდი (1c - 5c - 60s roll-ups).
Watermark: საზღვარი, რის შემდეგაც ფანჯარა „იხურება“; ბალანსი სიახლესა და სისრულეს შორის.
გვიან მონაცემები: დამატებითი პოლიტიკის 'S _ late "(მაგ. 2 წუთი), კომპენსაციის გამოანგარიშება.
Out-of-order: ჩვენ გავაერთიანებთ 'event _ time', რომელიც დაცულია 'ingested _ at' - სთვის.

4) Exactly-once მნიშვნელობით და idempotence

• გლობალური 'ღონისძიება _ id', idempotency keys ცხრილები;
• upsert/merge-sinks;
• state snapshots + გარიგების კომუნები (2-ფაზა/გადასინჯვის ჟურნალი);
• დეტერმინისტული ტრანსფორმაციები და ატომური swap ვიტრინების გამოქვეყნებისას.

5) მდგომარეობა და გამდიდრება

Stateful ოპერატორები: key-by (user/device/merchant), აგრეგატები, ტოპ-K, distinct.
ონლაინ join: სწრაფი lookup ცხრილი (მაგალითად, კლიენტის პროფილი, რისკის შეზღუდვები).
ქეშირება: LRU/TTL, თბილი ფიჩები, საცნობარო წიგნების ვერსია.
Online/offline fich კოორდინაცია: ერთიანი სპეციფიკაცია Feature Store- ში.

6) ინსაითი - უბრალოდ მეტრიკა

ჩვენ დავამატებთ გამოსავალი ბარათს ინსაითისთვის: ჰიპოთეზა/კონტექსტი - ალტერნატივა და რეკომენდებული მოქმედება. რისკის ეფექტი/guardrails - მფლობელი/მიწოდების არხი.
Zero-click ინსაითი: მოკლე ტექსტი + მზა ღილაკები (აპლოდისმენტები ავტომატურად, თუ დაბალი დონის).

7) ანომალიები, გამომწვევი მიზეზები და ექსპერიმენტები

დეტექტივი: robust z-score/ESD, seasonal-decompose, change-point (CUSUM/BOCPD), ესკიზები (TDigest/HLL) დიდი ნაკადებისთვის.
მიზეზი: თავიდან ავიცილოთ „ხმაურის რეაქცია“ - ჩვენ ვადასტურებთ ეფექტს კვაზი ექსპერიმენტების/საკონტროლო სეგმენტების საშუალებით.
ონლაინ ექსპერიმენტები: bandites/UCB/TS შეზღუდული დროის მოქმედების არჩევისთვის, guardrail მეტრიკა (SLA, საჩივრები, ზარალი).

8) SLO რეალურ დროში ინსაითებისთვის

Latency p95/p99 end-to-end (ingest - მოქმედება).
Freshness Witrin (maxi lag).
კომპლექტი ფანჯარაში (მოგვიანებით გათვალისწინებული წილი).
Action Rate/Success Rate (რამდენი ინსაითი მოქმედებად/ეფექტად გადაიქცა).
Cost-to-Insight (CPU/IO/GPU/$, 1 ინსაითი).

სამიზნე მატრიცის მაგალითი: ანტიფრომი p95-300 ms, completeness-99. 5%, cost/1k მოვლენები - $ H.

9) ინსაითების მიწოდება და პრიორიტეტიზაცია

სად: ვებჰუკი, მესიჯი bus "actions. ", API dashbords, push/chat ბოტები, CRM/CDP.
პრიორიტეტები: Gold/Silver/Bronze; ოქროს არის ცალკეული აუზები და არხები.
ვადები: თუ 'deadline' ამოიწურა - კლასის დაქვეითება ან გაუქმება.

10) ეკონომიკა და დეგრადაცია

Cost-aware სტრატეგია: გამარტივებული მოდელები, უფრო დიდი ფანჯრები, პიკის დრო.
Graceful degradation: fallback უხეში დანაყოფებისთვის/წესებისთვის, „თბილი“ სნაიპერები.

Backpressure & shed-load

11) უსაფრთხოება და კონფიდენციალურობა

RLS/CLS stream ფანჯრებზე; ტენანტის/რეგიონის დაყოფა.
PII გამოცემა ზღვარზე: ტოკენიზაცია ცენტრამდე.
საიდუმლოებები და წვდომა: mTLS, მოკლე ნიშნები, მოთხოვნის/ექსპორტის აუდიტი.
ექსპორტის პოლიტიკოსები: „ნედლეული“ რეალური PII აკრძალვის გარეშე.

12) რეალური დროის მიკროსქემის დაკვირვება

ღერძი/გასაღებები, queue depth, watermark skew.
p95/p99 თითოეულ ფენაზე, error rate, reprocess count.
Data-quality ინტერნეტით: დუბლიკატები, ნულოვანი განაწილების ანომალიები.
ტრეისი: ტრეიდერის გავლა მოვლენიდან მოქმედებამდე.

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

„ყველაფერი რეალური დროა“. ზედმეტი ხარჯები და ხმაური; ზოგიერთი პრობლემა უკეთესია, ვიდრე batch/near-real-time.
SELECT და „უფასო“ სქემები კონტრაქტების გარეშე.
ფანჯრები watermarks- ის გარეშე. ან მარადიული ფანჯრები, ან გვიანდელი ზარალი.
არ არსებობს იდემპოტენტობა. ორმაგი მოქმედება/სპამი.
Guardrails- ის გარეშე. რეაქცია „ცრუ პოზიტივზე“ ზიანს აყენებს.
OLTP ანალიტიკოსების ხანძრის ქვეშ. არ არსებობს იზოლაცია - პროდუქტების დეგრადაცია.

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

1. Discovery: მოვლენები, მიზნობრივი გადაწყვეტილებები, ვადები, რისკები; კლასიფიკაცია Gold/Silver/Bronze.
2. მონაცემთა კონტრაქტები: სქემები (Avro/Protobuf), გასაღებები, იდემპოტენტურობის პოლიტიკა.
3. MVP ნაკადი: ერთი კრიტიკული გამოსავალი, ფანჯარა/WM, მარტივი წესები + ონლაინ ფიჩები.
4. ფანჯრები და სერვინგი: სავარაუდო მატერიალიზაცია, დაბალი დონის API.
5. დაკვირვება: lage პანელები/latency/SLO, ალერტები; ტრეკი.
6. მოდელები და ექსპერიმენტები: ონლაინ მორიელი, ბანდიტები/guardrails.
7. Hardening: backpressure, დეგრადაცია, cost პროფილი; აუდიტი და კონფიდენციალურობა.
8. სკალი: მულტფილმის რეგიონი, edge ანალიტიკა, ნაკადების პრიორიტეტიზაცია.

15) ჩეკის სია გამოქვეყნებამდე

• განსაზღვრულია SLO (latence, freshness, completeness) და მფლობელი.
• სქემები ვერსირებულია; აკრძალულია „შერჩევა“; არსებობს idempotency-keys.
• გაფორმებულია ფანჯრები და watermarks, მონაცემების/გამოანგარიშების პოლიტიკა.
• Exactly-once მნიშვნელობით: upsert/merge-sinks, ატომური გამოცემა.
• ონლაინ ფიჩები შეთანხმებულია ოფლაინთან; ქეში TTL და ვერსიებით.
• Guardrails მოქმედებისთვის; არხები პრიორიტეტულია; ვადები მითითებულია.
• ლაგების/ლატენტობის მონიტორინგი/SLO; ტრეკინგი ჩართულია; ალერტები საფრთხეს უქმნის SLO.
• კონფიდენციალურობის პოლიტიკა (RLS/CLS/PII) და ექსპორტის აუდიტი შედის.
• Runbooks დეგრადაცია და ინციდენტები მზად არის (rollback/slow-path).

16) მინი შაბლონები (ფსევდო-YAML/SQL)

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

yaml windowing:
type: sliding size: 60s slide: 5s watermark:
lateness: 120s late_data:
accept_until: 90s recompute: true

Idempotent sink (SQL ესკიზი)

sql merge into rt_fact as t using incoming as s on t. event_id = s. event_id when not matched then insert (...)
when matched and t. hash <> s. hash then update set...

guardrails წესები მოქმედებისთვის

yaml action_policy:
name: promo_offer_rt constraints:
- metric: churn_risk_score; op: ">="; value: 0. 7
- metric: complaint_rate_24h; op: "<"; value: 0. 02 cooldown_s: 3600 owner: "growth-team"

Alerty SLO

yaml alerts:
- name: e2e_latency_p95 threshold_ms: 1500 for: 5m severity: high
- name: freshness_lag threshold_s: 60 severity: high

17) შედეგი

რეალურ დროში ინსაითები არ არის მხოლოდ „სწრაფი გრაფიკა“, არამედ გადაწყვეტილებების საინჟინრო წრე: მკაცრი ღონისძიებების კონტრაქტები, სწორი დროებითი ლოგიკა (ფანჯრები/watermarks), idempotent პუბლიკაციები, შეთანხმებული ონლაინ ფიჩები, პრიორიტეტული აქციები და დაკვირვება SLO- სთან. როდესაც ეს წრე მუშაობს, ორგანიზაცია რეაგირებს დროულად, უსაფრთხოდ და პროგნოზირებად, მოვლენების ნაკადის გაზომვის ბიზნესში გადაქცევას.