تجزیه و تحلیل جریان و جریان

1) هدف و ارزش

• Antifraud/AML: شناسایی ساختار سپرده ها، حملات سرعت، ناهنجاری های ارائه دهندگان.
• بازی مسئول (RG): بیش از محدودیت، الگوهای خطر، خود حذفی.
• عملیات/SRE: تخریب SLA، انفجار خطا، سیگنال های حادثه اولیه.
• محصول/بازاریابی: رویدادهای شخصی سازی، مأموریت/مأموریت، تقسیم بندی در زمان واقعی.
• گزارش نزدیک به زمان واقعی: ویترین GGR/NGR، پانل های عملیاتی.

ویژگی های هدف: p95 پایان به پایان 0. 5-5 ثانیه، تکمیل ≥ 99. 5٪، ارزش مدیریت شده.

2) معماری مرجع

1. مصرف/لبه

'/events/batch '(HTTP/2/3), gRPC, OTel collector.
اعتبار سنجی طرح ها، ضد تکراری، مسیریابی جغرافیایی.

2. اتوبوس رویداد

Kafka/Redpanda (تقسیم بر 'user _ id/tenant/market').
نگهداری 3-7 روز، فشرده سازی، DLQ/» قرنطینه« برای پیام های »شکسته«.

3. جریان جریان

Flink/Spark Structured Streaming/Beam.
اظهارات stateful، CEP، علامت، تاخیر مجاز، deduplication.
غنی سازی (Redis/Scylla/ClickHouse-Lookup)، I/O ناهمزمان با وقفه.

4. نمایش خدمت/عملیاتی

ClickHouse/Pinot/Druid برای تجمع دقیقه/ثانیه و داشبورد.
فروشگاه ویژگی (آنلاین) برای مدل های به ثمر رساند.
موضوعات هشدار → SOAR/ticketing/webhooks.

5. ذخیره سازی طولانی مدت (دریاچه)

برنز (خام)، نقره (تمیز)، طلا (خدمت) - پارکت + دلتا/کوه یخ/هودی.
پخش/backtests، سفر در زمان.

6. قابل مشاهده بودن

معیارهای خط لوله، ردیابی (OTel)، سیاهههای مربوط، اصل و نسب.

3) طرحها و قراردادها

Schema-first: JSON/Avro/Protobuf + Registry، «schema _ version» در هر رویداد.
تکامل: سازگار با عقب - زمینه های جدید nullable ؛ شکستن - '/v2 '+ انتشار دوگانه.
فیلدهای مورد نیاز عبارتند از 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id'، «بازار»، «منبع».

4) ویندوز، علامت های سفید و داده های دیررس

• غلت زدن، پرش، جلسه.
• علامت گذاری به عنوان: آستانه «دانش» رویداد زمان ؛ به عنوان مثال 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'، 'پرداخت. account_id' است.
وضعیت: مبالغ کشویی/شمارنده، جلسات، فیلتر شکوفه برای deduplication.
الگوهای CEP: ساختار (<آستانه، ≥N بار، در هر پنجره T)، سوئیچ دستگاه، خستگی RG.

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) دقیقا یک بار، سفارش و idemotence

Bus: کلیدهای پارتیشن حداقل یک بار + سفارش محلی را ارائه می دهند.
Idempotence: 'event _ id' + حالت dedup (TTL 24-72 ساعت).
غرق شدن: تعهدات معاملاتی (2 فاز) یا upsert/merge-idempotency.
Outbox/Inbox: تضمین انتشار رویدادهای دامنه از OLTP.

7) غنی سازی در زمان واقعی

مراجعه: Redis/Scylla (محدودیت RG، وضعیت KYC، BIN → MCC، IP → Geo/ASN).
Asynchronous calls: sanctions/APP API with timeouts and fallback («ناشناخته»).
FX/منطقه زمانی: عادی سازی مقادیر و زمان بازار محلی ('fx _ source'، 'tz').

8) خدمت و فروشگاه های زمان واقعی

ClickHouse/Pinot/Druid: aggregations by minutes/seconds، نمایش های تحقق یافته.
جریان طلا: جداول عملیاتی 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 → هشدار ≤ 2 s (بحرانی)، ≤ 5 s (تعادل).
• کامل بودن پنجره T ≥ 99 5%.
• خطای طرح ≤ 0. 1%; درصد حوادث با «trace _ id» 98٪ ≥.
• دسترسی به خدمات جریان ≥ 99. 9%.

• حزب/موضوع عقب می افتد، اپراتورهای زمان مشغول، اندازه دولت.
• Funnel «sobytiye → pravilo → keys», نقشه «hot» keys, late-ratio.
• هزینه: هزینه/GB، هزینه/پرس و جو، هزینه بازرسی/تکرار.

10) حفظ حریم خصوصی و انطباق

به حداقل رساندن PII: نام مستعار ID، پوشش زمینه، نشانه PAN/IBAN.
اقامت داده ها: خطوط لوله منطقه ای (EEA/UK/BR)، کلیدهای رمزگذاری فردی.
عملیات حقوقی: DSAR/RTBF در فروشگاه های پایین دست، نگهداری قانونی برای موارد/گزارش ها.
حسابرسی: دسترسی به سیاهههای مربوط، آرشیو راه حل بدون تغییر.

11) اقتصاد و بهره وری

کلید و شاردینگ: اجتناب از «داغ» کلید (نمک/کلید کامپوزیت).
وضعیت: TTL معقول، عکس های فوری، تنظیم حالت RocksDB/backend.
Preaggregation: کاهش جلو برای جریان های پر سر و صدا.
نمونه برداری: معتبر در معیارهای غیر بحرانی (نه در معاملات/انطباق).
بازپرداخت: بودجه برای موضوعات/مشاغل، سهمیه ها و تخصیص تیم.

12) جریان DQ (کیفیت)

Ingest-validation (schema, enums, size), dedup '(event_id, source)'.
در جریان: کامل بودن/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: قانون تاریک و مدل اجرا می شود، کنترل دقیق/فراخوانی.
اسرار: KMS/CMK، چرخش منظم، ممنوعیت اسرار در سیاهههای مربوط.

14) فرآیندها و RACI

R (مسئول): پلت فرم جریان (infra/releases)، تجزیه و تحلیل دامنه (قوانین/ویژگی ها)، MLOps (به ثمر رساند).
A (پاسخگو): رئیس داده/ریسک/انطباق توسط دامنه.
C (مشورت): DPO/حقوقی (PII/احتباس)، SRE (SLO/حوادث)، معماری.
I (مطلع): محصول، پشتیبانی، بازاریابی، مالی.

15) نقشه راه پیاده سازی

1. کافکا/ردپاندا + دو موضوع مهم («پرداخت»، «auth»).

2. کار flink با علامت، deduplication و یک قانون CEP (AML یا RG).

3. ویترین ClickHouse/Pinot 1-5 دقیقه، تاخیر/کامل بودن داشبورد.

4. کانال حادثه (webhooks/Jira)، SLO های اساسی و هشدارها.

• غنی سازی آنلاین (Redis/Scylla)، فروشگاه ویژگی، جستجوی ناهمزمان.
• مدیریت قانون به عنوان کد، انتشار قناری، A/B.
• جریان DQ، منطقه بندی خطوط لوله، روش DSAR/RTBF.

• چند منطقه فعال فعال، چه اگر شبیه ساز پخش، خودکار کالیبراسیون آستانه.
• ویترین کامل جریان طلا (GGR/RG/AML)، گزارش تقریبا در زمان واقعی.
• داشبورد ارزش، بازپرداخت، تمرینات 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) چک لیست پیش فروش

• طرح ها و قراردادها در رجیستری، آزمون های برگشتی سبز هستند.
• شامل علامت سفید/اجازه تاخیر، dedup و DLQ.
• پیکربندی SLO و هشدار (تاخیر/اواخر/dup/اندازه دولت).
• غنی سازی با انبارها و زمان، عقب نشینی «ناشناخته».
• RBAC/کنترل دوگانه به قوانین/مدل، تمام تغییرات ثبت شده است.
• قوانین، فروشگاه ها و مستندات runbook و پخش/برگشت.

18) اشتباهات مکرر و چگونگی اجتناب از آنها

نادیده گرفتن زمان رویداد: بدون علامت، معیارهای «شناور».
بدون deduplication: هشدار نادرست و شمارش دو برابر.
کلید های داغ: اعوجاج احزاب → شور/resarding.
API های جلویی همزمان در مسیر داغ: فقط async + cache.
هزینه های مدیریت نشده: پیش جمع آوری، TTL ایالات، سهمیه ها، داشبورد هزینه.
عدم شبیه ساز: rollouts بدون «پخش» منجر به رگرسیون.

19) واژه نامه (کوتاه)

CEP - پردازش رویداد پیچیده.
واترمارک - محدودیت آمادگی پنجره بر اساس زمان رویداد.
Lateness مجاز - تحمل وقایع اواخر.
اپراتور stateful - یک اپراتور با حالت ذخیره شده.
فروشگاه ویژگی - ویژگی گشت و گذار هماهنگ (آنلاین/آفلاین).

20) خط پایین

تجزیه و تحلیل جریان و جریان یک سیستم مدیریت شده است: قراردادها، پنجره ها و علامت های سفید، منطق stateful و CEP، غنی سازی و فروشگاه های زمان واقعی، SLO و قابلیت مشاهده، حریم خصوصی و ارزش تحت کنترل. با پیروی از شیوه های شرح داده شده، این پلت فرم آشکارسازهای ریسک قابل اعتماد، پانل های عملیاتی و شخصی سازی را با تاخیر و هزینه قابل پیش بینی دریافت می کند.