Stream vs Batch ანალიზი

1) მოკლე არსი

Stream - მოვლენების უწყვეტი დამუშავება წამში: ანტიფროდი/AML, RG გამომწვევი, SLA ალერტები, ოპერაციული პანელები.
Batch არის პერიოდული გადაანგარიშება სრული რეპროდუქციით: მარეგულირებელი ანგარიშგებები (GGR/NGR), ფინანსური სერვერები, ML Datasets.

სახელმძღვანელოები: Stream p95 e2e 0. 5-5 გვ, Batch D + 1 06:00 საათამდე (ლოკი.) .

2) არჩევანის მატრიცა (TL; DR)

კრიტერიუმი	Stream	Batch
SLA რეაქცია	წამები/წუთი	საათი/დღე
სისრულე	მაღალი, მაგრამ შესაძლო შესწორებები	ძალიან მაღალი, კონტროლირებადი D + 1
„as-of“ - ის რეპროდუქცია	უფრო რთული (replay)	უფრო მარტივი (time-travel/snapshots)
ერთეულის ღირებულება	უფრო ძვირია, ვიდრე ონლაინ გზა	იაფი მოცულობა
ტიპიური დავალებები	AML/RG ალერტები, SRE, რეალური ტიპის ფანჯრები	მოხსენებები, კრიპტები, ML off-line
ისტორიალიზაცია (SCD)	შეზღუდულია	სავსეა
მარეგულირებელი/WORM	ოქროს გადანერგვის საშუალებით	National (Gold/D + 1)

წესი 80/20: ყველაფერი, რაც არ საჭიროებს რეაქციას <5 წუთი - Batch- ში; დანარჩენი არის Stream- ში, Batch- ის ღამისთევა.

3) არქიტექტურა

3. 1 Lambda

Stream ონლაინ + Batch კონსოლიდაციისთვის. პლუს: მოქნილობა. მინუს: ორი ლოგიკა.

3. 2 Kappa

ყველაფერი ნაკადებს ჰგავს; Batch = „rapley“ ლოგის საშუალებით. პლუს: ერთი კოდი. მინუს: რეაგირების სირთულე/ღირებულება.

3. 3 Lakehouse-Hybrid (რეკომენდებულია)

Stream - ოპერატიული OLAP მარტი (წუთი) და Bronze/Silver; Batch ანაზღაურებს გოლდს (D + 1) და აქვეყნებს მოხსენებებს.

4) მონაცემები და დრო

Stream

ფანჯრები: tumbling/hopping/სესია.
Watermarks: 2-5 წუთი; დაბალანსებული მონაცემები აღინიშნება და დაემატება.
Stateful: CEP, დედაპლატი, TTL.

Batch

ნიშნები/CDC: განახლებული _ at ', ლოგიკური რეპლიკაცია.
SCD I/II/III: ატრიბუტების ისტორია.
Snaphots: დღის/თვის ფენები „as-of“.

5) iGaming- ში გამოყენების ნიმუშები

AML/ანტიფროდი: Stream (velocity/სტრუქტურა) + Batch Cryps და შემთხვევები.
Responsible Gaming: Stream აკონტროლებს limites/თვითკონტროლი; Batch საანგარიშო რეესტრები.
ოპერაციები/SRE: Stream alerty SLA; Batch პოსტ - ანალიზი ინციდენტებისა და ტენდენციების შესახებ.
პროდუქტი/მარკეტინგი: Stream პერსონალიზაცია/მისიები; Batch კოჰორტები/LTV.
ფინანსები/მოხსენებები: Batch (Gold D + 1, WORM პაკეტები), Stream - ოპერაციული პანელები.

6) DQ, რეპროდუქცია, რეფლექსები

Stream DQ: სქემების შესაბამისობა, deadup '(event _ id, წყარო)', completeness ფანჯარა, late-ratio, dup-rate; კრიტიკული DLQ.
Batch DQ: უნიკალურობა/FK/range/temporal, კრიკეტები OLTP/პროვაიდერებით; კრიტიკული ანგარიში fail job + ანგარიში.

რეპროდუქცია:

Stream: ტოპიკური რეპლიკები + deterministic ტრანსფორმაციის დიაპაზონში.
Batch: time-travel/ლოგიკის ვერსიები ('logic _ version') + Gold snaphots.

7) კონფიდენციალურობა და რეზიდენცია

ნაკადი: ფსევდონიზაცია, ონლაინ შენიღბვა, რეგიონალური კონვეიერები (EEA/UK/BR), ტაიმაუტები გარე PII-lookups- ზე.
Batch: PII mappings იზოლაცია, RLS/CLS, DSAR/RTBF, Legal Hold, WORM არქივები.

8) Cost ინჟინერია

Stream: თავიდან აიცილოთ „ცხელი“ გასაღებები, შეზღუდეთ async lookups, TTL მდგომარეობა, წინასწარ დანერგვა.
Batch: ნაწილობრივი/კლასტერიზაცია, მცირე ზომის ფილმების კომპაქტური, სტაბილური ერთეულების მატერიალიზაცია, კვოტები/გაშვების ფანჯრები.

9) მაგალითები

9. 1 Stream - Flink SQL (10 - წუთიანი დეპოზიტების დეპოზიტები)

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

9. 2 Stream - CEP (ფსევდო კოდი AML)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9. 3 Batch - MERGE (ვერცხლის ინციდენტი)

sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

9. 4 Batch — Gold GGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

10) მეტრიკა და SLO

Stream (სახელმძღვანელო)

p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99. 5%

schema-errors ≤ 0. 1%

late-ratio ≤ 1%

ხელმისაწვდომობა 99. 9%

Batch (სახელმძღვანელო)

Gold. daily მზად არის 06:00 საათამდე.

completeness ≥ 99. 5%

validity ≥ 99. 9%

MTTR DQ ინციდენტი 24-48 სთ

11) ტესტირება და გამოშვებები

კონტრაქტები/სქემები: consumer-driven tests; back-compat CI.
ნაკადი: კანარის წესები, მუქი გაშვება, რეპლეი სიმულატორი.
Batch: dry-run ნიმუშებზე, მეტრიკის შედარება, კონტროლის შეჯამება (ჩანაწერების შეჯამება).

12) ანტი შაბლონები

ლოგიკის დუბლირება: სხვადასხვა Stream და Batch გამოთვლები ფორმულების განლაგების გარეშე.
სინქრონული გარე API Stream- ის ცხელ გზაზე ქეში/ტაიმაუტის გარეშე.
Full reload „მხოლოდ შემთხვევაში“ ჩანაწერების ნაცვლად.
Watermarks/late პოლიტიკის არარსებობა.
PII ანალიტიკურ ფენებში; CLS/RLS- ის ნაკლებობა.
ოქროს ფანჯრები, რომლებიც რეტროაქტიულად „მუტაციას“ ახდენენ.

13) რეკომენდებული ჰიბრიდი (ფლეიბუკი)

1. Stream წრე: ingest - საბურავი Flink/Beam (watermarks, dedup, CEP)

OLAP (ClickHouse/Pinot) 1-5 წუთიანი პანელებისთვის + Bronze/Silver (append).
2. Batch წრე: ჩანართები/CDC - Silver ნორმალიზაცია/SCD - Gold ყოველდღიური ვიტრინები/მოხსენებები (WORM).
3. კოორდინაცია: მეტრიკის ერთი სემანტიკური ფენა; Nightly crypts Stream - Batch; შეუსაბამობები> ბარიერი და თიკეტები.

14) RACI

R (Responsible): Streaming Platform (Stream-infra), Data Engineering (Batch მოდელები), Domain Analytics (წესები), MLOps (fice/fich/Feat Sore Sore SiEiTiGord SanGied Sied SiTed SanGiTiTiTiTiTiTite- ი).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (ინფორმირებული): BI/პროდუქტი/მარკეტინგი/ოპერაციები.

15) გზის რუკა

MVP (2-4 კვირა):

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

2. Flink Joba: watermark + dedup + 1 CEP წესი (AML ან RG).

3. OLAP ვიტრინა 1-5 წთ + დაშბორდები lag/late/dup.

4. Lakehouse Silver (ACID), პირველი Gold. ggr _ daily (D + 1 06:00 საათამდე).

ეტაპი 2 (4-8 კვირა):

ნიშნები/CDC დომენებზე, SCD II, მეტრული სემანტიკური ფენა.
ნაკადი DQ და nightly crucks Stream - Batch.
რეგიონალიზაცია (EEA/UK/BR), DSAR/RTBF, Legal Hold.

ეტაპი 3 (8-12 კვირა):

Replay simulator, canary/A-B წესები/მეტრიკა.
Cost Dashbords და კვოტები; tiered storage; DR სწავლებები.
დოკუმენტაციის ავტომატური წარმოება არის ფანჯარა/მეტრიკა და ხაზები.

16) განხორციელების შემოწმების სია

სქემები/კონტრაქტები რეგისტერში; საკონტროლო ტესტები მწვანეა.
Stream: watermarks/allowed-lateness, дедуп, DLQ; გაყიდვაში OLAP პანელი.
Batch: ინციდენტები/CDC, SCD II, GolD + 1 WORM ექსპორტით.
მეტრიკის ერთიანი სემანტიკური ფენა; Nightly Stream - Batch- ის კრიკეტები.
DQ დაშბორდები Freshness/Completeness/Validity; ალერტები lag/late/dup.
RBAC/ABAC, დაშიფვრა, რეზიდენცია; DSAR/RTBF/Legal Hold.
ღირებულება კონტროლდება (cost/GB, cost/query, state size, სიტყვების კვოტირება).

17) შედეგი

Stream და Batch არ არიან კონკურენტები, არამედ ერთი წამყვანი ორი გადაცემათა კოლოფი. Stream იძლევა რეაქციას „აქ და ახლა“, Batch არის შემოწმებული ჭეშმარიტება „დილით“. Lakehouse მიდგომის ჰიბრიდი, მეტრიკის ერთი ფენა და DQ/lineage დისციპლინა საშუალებას გაძლევთ შექმნათ სწრაფი, რეპროდუქციული და კომპოზიციური ანალიტიკური კონტურები, რომლებიც ოპტიმალურია SLA და ღირებულებით.

Stream vs Batch ანალიზი

Batch

Batch (სახელმძღვანელო)

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით