اعتبار سنجی داده ها

1) چرا پلتفرم iGaming به آن نیاز دارد ؟

اعتماد به گزارش ها و KPI ها: GGR/NET، تبدیل، نگهداری، سیگنال های RG.
ML/قابلیت اطمینان به ثمر رساند: ویژگی های صحیح برای ضد تقلب/توصیه/RG.
عملیات در زمان واقعی: هشدارها در رانش/از دست دادن حوادث قبل از پرداخت/UX تحت تاثیر قرار می گیرند.

انطباق: هیچ PII/اسرار جایی که نباید باشند ؛ قابلیت ردیابی قابل اثبات

2) از کجا اعتبار: سطح کنترل

1. تزریق (دسته ای/جریان): طرح، انواع، زمینه های مورد نیاز، idemotency/dedup.
2. پردازش جریان: پنجره ها/علامت های سفید، سفارش، حذفیات/تاخیر، دقیقا یک بار.
3. ETL/ELT و تحولات: لینک/شادی، aggregates، تعادل کسب و کار.
4. DWH/storefronts (طلا): سازگاری بین جداول، طراوت، منحصر به فرد از کلید.
5. ویژگی فروشگاه/آنلاین: محدوده ویژگی، سازگاری offlayn↔onlayn.
6. BI/API: شمارش و فیلتر، SLA در تاخیر/طراوت، k-ناشناس بودن.

3) انواع چک (کاتالوگ)

شماتیک: نوع/nullable/enum/regex/JSON شکل ؛ تغییرات ناسازگار برای متوقف کردن

دامنه: مقادیر ≥0، ارز ∈ {EUR، USD، TRY، BRL}، نرخ محدود ≤، strana∈litsenzii.
هویت/کلید: کلید اصلی منحصر به فرد است، کلید خارجی «حلق آویز» نیست.
کیفیت فیلد: کامل بودن، طول، فرمت (IBAN، BIN، نشانه ایمیل).
آمار/خطوط پایه: فرکانس، توزیع، راهروهای چندک.
ناهنجاری ها: سنبله حجم/کسری، صفر/تکراری، رانش طرح.
تازگی: حداکثر (ts) قدیمی تر از X نیست ؛ تاخیر مصرف → طلا ≤ T.
سازگاری: مجموع قطعات = خلاصه ؛ چند جدول آشتی.
حریم خصوصی/امنیت: صفر PII در خارج از مناطق مجاز ؛ نشانه گذاری/ماسک.
زمینه های RG/AML موجود و قابل قبول هستند.

4) قراردادهای داده

این قرارداد طرح + قوانین کیفیت + SLO بین منبع و مصرف کنندگان را رفع می کند.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

تغییرات قرارداد - از طریق semver و مهاجرت: «MAJOR» خراب می شود، «MINOR» یک فیلد اضافه می کند، «PATCH» توضیحات را تصحیح می کند.

5) انتظارات و سیاست ها

انتظارات - چک های اعلانی انجام شده در خطوط لوله (دسته/جریان).

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• 'error → قرنطینه حزب/دسته ای، هشدار + بلیط ؛ بلوک پایین دست
• "گذشته → عبور می کند، اما یک کار تجزیه ایجاد می کند ؛ مارک کیفیت.
• 'info' → فقط نظارت

6) جریان: مشخصات چک

علامت های سفید/داده های دیررس: بیایید اواخر ≤ 120، در غیر این صورت - قرنطینه ؛ با پنجره های محدود جبران کنید.
Idempotency: کلید رویداد + بار هش → بن بست در کارگزار/موضوع.
دقیقا یک بار: sing transactional (+ غرق idempotent) برای جریان های بحرانی (پرداخت/دور).

شمارنده حجم صدا: «انتظار می رود» در مقابل «دریافت» در هر پنجره ؛ اختلاف → هشدار

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL: ثابت و آشتی

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

تطبیق پنجره: روزانه «جزئیات → خلاصه» آشتی، گزارش اختلاف، بلیط اتوماتیک.

8) حریم خصوصی و امنیت

نسخه پیش فرض PII: ماسک های ورودی/نشانه ها ؛ ما ایمیل/کارت/تلفن «خام» را در سیاهههای مربوط ممنوع می کنیم.
سیاست مجوز: جداول با PII - لایه/دایرکتوری جداگانه، دسترسی به نقش ها (RBAC/ABAC).
K-ناشناس بودن گزارش ها: حداقل N ردیف در برش.
آشکارسازهای نشت: چک های منظم برای الگوهای PII، «اسرار» (کلید/نشانه).
حوزه های قضایی: geo/tenant-isolation (کشور/نام تجاری/مجوز)، کلید های جداگانه.

9) معیارهای کیفیت و SLO

• طراوت - حداکثر تاخیر (ts).
• کامل بودن - نسبت سوابق غیر خالی/مورد انتظار.
• منحصر به فرد - کلید های تکراری.
• سازگاری - ثابت و تعادل (بین جدول).
• دقت - اعتبار سنجی با منبع دامنه/قوانین خارجی.
• اعتبار - تطبیق/enum/انواع regex.

• 'تازگی payments_gold ≤ 5 мин' (p95).
• "کامل بودن game_rounds ≥ 99 7 درصد در روز "
• 'Duplicate _ rate ≤ 0. 1‰`.
• 'PII _ leak = 0'.

10) هشدارها، بلیط ها و runbook

مسیریابی: Slack/PagerDuty → صاحب دامنه ؛ به طور خودکار نمونه ها و تفاوت اعمال می شود.
گروه بندی: یک حادثه در هر مجموعه «برچسب: مجموعه داده = پرداخت، نام تجاری = TR».

1. ورودی ورودی و صف کارگزار را بررسی کنید.

2. مقایسه «انتظار می رود در مقابل دریافت» توسط PSP.

3. فعال کردن مسیر PSP Retrai/سوئیچ.

4. علت حاشیه نویسی ؛ بازگشت به عقب ؛ پس از مرگ

11) نسخه، آزمون و فرایند چشم پوشی

Semver از قوانین کیفیت: "کیفیت @ MAJOR. جزئی است. پچ.
تست واحد از تحولات (SQL/DBT/پایتون) و تست قرارداد برای منابع.
مجموعه های طلایی: موارد شناخته شده اختلاف/نشت در رگرسیون اجباری است.
چشم پوشی: اجازه کوتاه مدت برای نقض قانون (شرح، مالک، مدت، اقدامات جبرانی).

12) کاتالوگ/مصنوعات (قالب های آماده)

12. 1 گذرنامه داده

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 سیاست قرنطینه

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 انتظار для فروشگاه ویژگی

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) ویژگی های iGaming: موارد آماده

پرداخت/PSP: آشتی سپرده/برداشت به گزارش PSP; وضعیت از دست رفته → قرنطینه butch ؛ هشدار برای رشد 'کاهش _ نرخ'.
ارائه دهندگان بازی: رها کردن «rounds _ per _ min» در مقابل baseline + schema رانش از ارائه دهنده → بلوک تحول ارائه دهنده A، بنر وضعیت.
RG/AML: فیلدهای اجباری (محدودیت، خود حذفی، وضعیت KYC) ؛ KYC → پرچم در بلوک پرداخت، بلیط در انطباق.

بازاریابی/CRM: اعتبار پارامترهای کمپین، UTM، رویداد dedup ؛ ناشناس بودن کی در ویترین مغازه ها

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

0-30 روز (MVP)

1. شامل قراردادها برای مجموعه های کلیدی: پرداخت، game_rounds، کاربران، ویژگی ها.
2. کاتالوگ انتظارات (10-15 پایه) + قرنطینه + هشدارها.

3. تازگی داشبورد/کامل بودن/منحصر به فرد بودن ؛ گزارش حادثه

4. Runbook'и для 'Freshness', 'Duplicates', 'Schema drift'.

30-90 روز

1. آشتی و تعادل متقابل ؛ فرآیند چشم پوشی و قوانین semver.

2. اعتبار سنجی جریان (داده های دیرهنگام، بن بست، علامت های سفید) ؛ آشکارسازهای PII

3. ادغام با CI/CD: تست قرارداد منابع و تحولات

4. SLO های کیفیت در OKR های فرمان دامنه.

3-6 ماه

1. نکات آستانه AIOps ؛ محلی سازی خودکار علل.
2. سیاست کیفیت متقابل برند/ژئو و گزارش های انطباق.
3. حوادث پس از مرگ P1 → دوباره پر کردن مجموعه طلایی و قوانین.
4. ارتباط با هشدار جریان و تجزیه و تحلیل ناهنجاری (تک حلقه).

15) RACI

حاکمیت داده (A/R): استانداردها، قراردادها، حسابرسی قانون

صاحبان دامنه (R): انتظارات دامنه و ناوردا.
بستر داده (R): چارچوب انتظارات، قرنطینه، هشدارها، نظارت.
امنیت/DPO (A/R): حریم خصوصی/PII/K-ناشناس بودن، انزوای جغرافیایی/مستاجر.
SRE/مشاهده پذیری (C): مسیریابی حادثه، SLO/SLI.
محصول/امور مالی (C): تعادل کسب و کار، اولویت های حادثه.

16) ضد الگوهای

اعتبار سنجی «فقط در DWH» - دیر، گران، دردناک است.
بدون قرنطینه - «خاک» به طلا/ML می رود و اعتماد را از بین می برد.
آستانه های سخت بدون فصلی/ساعت/بازار → طوفان هشدار.
فقدان قوانین مالک و semver → هرج و مرج استثنا.
سیاهههای مربوط با PII و «تصاویر به کانال مشترک».
یک بار «روزهای بهداشتی» به جای یک مدار دائمی.

17) بخش های مرتبط

DataOps Practices، Data Auditing and Versioning، Data Origin and Path، Data Stream Alerts، Anomaly and Correlation Analysis، Access Control، Data Security and Encryption، Data Retention Policies، MLOps: Model Exploitation.

مجموع

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