داده مش: مدل داده فدرال
(بخش: تکنولوژی و زیرساخت)
خلاصه ای کوتاه
Data Mesh یک مدل سازمانی و فنی است که در آن داده ها به عنوان محصولات تیم های دامنه مورد استفاده قرار می گیرند و نقش مرکزی این پلت فرم ارائه خدمات خود، استانداردها و انطباق است. برای iGaming، این بدان معنی است: تیم پرداخت صاحب «سپرده رویدادها» و «خالص سپرده مارت»، تیم خطر صاحب «سیگنال تقلب»، بازی صاحب «شرط رویدادها» و «مدیران»، و پلت فرم مرکزی می دهد یک کاتالوگ، طرح قرارداد، دسترسی، نظارت بر کیفیت، finops و ابزار جریان/ELT.
1) اصول داده مش
1. مسئولیت دامنه: هر دامنه (پرداخت، ریسک، بازی، KYC/Compliance، CRM، Affiliate) مجموعه داده ها و چرخه زندگی خود را دارد.
2. داده به عنوان یک محصول: هر مجموعه دارای مالک، توضیحات، SLO، دسترسی SLA، اسناد، نسخه، بازخورد و نقشه راه است.
3. پلت فرم خود خدمت: خطوط لوله استاندارد مصرف/تبدیل/خدمت، قالب ها، امنیت پیش فرض، دایرکتوری و مشاهده.
4. مدیریت فدرال: استانداردهای مشترک طرح ها، معیارها، PII/محلی سازی و کیفیت - در مرکز ؛ پیاده سازی و تکامل - در حوزه ها.
2) مدل عملیاتی و نقش
Domain Data Product Owner (DPO): اولویت بندی، SLO، بهبود محصول داده ها.
مهندس داده دامنه/مهندس تجزیه و تحلیل: شماتیک، خطوط لوله، تست DQ، نسخه.
کارگزار دامنه: معناشناسی زمینه، مطابقت با فرهنگ لغت متریک و طبقه بندی PII.
تیم پلت فرم: کاتالوگ، IAM/RBAC، سیاست به عنوان کد، فرمت های جدول (Delta/Iceberg/Hudi)، ارکستراسیون، قابلیت مشاهده، finops.
هیئت مدیره فدرال: استانداردها (طرح ها، معیارها، امنیت) را تصویب می کند، اختلافات متقابل را حل می کند.
3) «محصول داده» - گذرنامه و مصنوعات
حداقل ترکیب محصول داده ها:- قرارداد (طرح، انواع، تکامل، سازگاری).
- دسترسی به API (SQL/جدول، موضوع/جریان، فایل/اشتراک).
- SLA/SLO (طراوت، در دسترس بودن، کیفیت).
- تست های DQ (منحصر به فرد، محدوده، یکپارچگی ارجاعی).
- مستندات (شرح زمینه ها، نمونه هایی از درخواست ها، مالک، تماس).
- Versioning (طرح های نسخه بندی معنایی، سیاست منسوخ).
- سیاست ها (PII، محلی سازی، حفظ/TTL، حقوق).
قالب گذرنامه (به عنوان مثال YAML)
yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"4) قابلیت همکاری و استانداردها
طرح ها/قراردادها: Avro/Protobuf/JSON-Schema + رجیستری طرح ؛ سیاست بازگشت به کامپکت، بدون تغییر شکستن بدون نسخه اصلی جدید.
لایه معنایی: تعاریف یکپارچه از GGR، NGR، سپرده خالص، LTV، کوهورت - به عنوان کد (معیارهای DBT/لایه معنایی).
شناسه ها: جهانی 'player _ id'، 'tenant _ id'، 'bet _ id'، دایرکتوری های متحد کشور/ارز/ارائه دهنده.
ابرداده: ستونهای مورد نیاز «ingest _ ts»، «schema _ version»، «trace _ id»، «source»، «region».
دسترسی: SQL (دریاچه/OLAP)، جریان (کافکا/پولسار)، به اشتراک گذاری جدول/عکس فوری ؛ فرمت تبادل پارکت/دلتا/کوه یخ است.
5) استاندارد مرجع فرآیند (آگنوستیک به فروشندگان)
مصرف: Outbox/CDC из OLTP → کافکا → دریاچه (برنز).
تبدیل: ELT/DBT в نقره/طلا ؛ «MERGE» افزایشی، SCD، موارد نمایش مواد.
خدمت: OLAP (ClickHouse/BigQuery/Snowflake)، RT- движки (Pinot/Druid) для تقریبا زمان واقعی.
کاتالوگ/خط: یک کاتالوگ واحد، مستندات خودکار، نمودار وابستگی.
قابلیت مشاهده: معیارهای تازگی/SLO، DQ-assert، جریان تاخیر، هزینه.
سیاست ها: IAM/RBAC/ABAC، رمزگذاری، محلی سازی (مسیریابی داده های منطقه).
6) SLO/SLA برای محصولات داده
نمونه هایی از SLO های هدف:- تازگی: شرط رویدادها (p95) ≤ 5 мин; سیگنال های تقلب ≤ 30 ثانیه ؛ خالص سپرده مارت ≤ 15 دقیقه.
- دسترسی: ≥ 99 9٪ برای رابط های خواندن.
- کیفیت: تکراری ≤ 0. 01٪، سهم فیلدهای خالی مورد نیاز 0 ≤. 1٪، ثبات ارز 100٪.
- SLO هزینه: هزینه اسکن پنجره ≤ N $/روز، نسبت فایل های کوچک <10٪.
7) ایمنی، PII و محلی سازی
طبقه بندی: PII/حساس مالی/عملیاتی.
اقدامات فنی: رمزگذاری در حالت استراحت/در حمل و نقل ؛ نشانه گذاری PII ؛ ستون های ماسک ؛ فیلترهای سطح ردیف با «tenant _ id».
بومی سازی: محصولات دامنه در مناطق مجاز (EU/TR/LATAM) منتشر می شوند. اشتراک گذاری مرزی - فقط واحدهای بدون PII.
حسابرسی: چه کسی منتشر کرد/خواند ؛ درخواست تشدید حقوق نسخه طرح - از طریق تصویب.
8) FinOps و مدیریت ارزش
بودجه های دامنه: محاسبه محدودیت ها، هشدارها بیش از حد هزینه.
ذخیره سازی: کلاس های ذخیره سازی + TTL (برنز کوتاه، نقره متوسط، طلا طولانی/aggregates).
بهینه سازی پرس و جو: پارتیشن/خوشه بندی، نمایش های تحقق یافته، حافظه پنهان نتایج BI.
فایل های کوچک: سیاست های تراکم/OPTIMIZE ؛ حجم فایل هدف 128-1024 مگابایت است.
9) چرخه زندگی و تکامل
نسخه بندی: "دامنه. محصول. v {سرگرد}; زمینه های جزئی - back-compat.
تخفیف: اطلاع رسانی مصرف کننده، دوره «دو راه آهن»، هشدار خودکار به نسخه های قدیمی تر.
تغییرات طرح: Pull Request to Contract Repository; تست سازگاری CI ؛ AutoPublish به کاتالوگ.
بازخورد: کانال محصول (ردیاب مسئله)، NPS مصرف کننده، زمان پاسخ حادثه.
10) Concretization برای iGaming - دامنه و نقشه محصول
پرداخت ها
پرداخت ها پی اس پی وب سایت ها v1 '(جریان)
'mot _ net _ deposits _ daily. v1 '(SQL) - طراوت SLO ≤ 15 دقیقه ؛ PII رایگان
بازی ها
شرط بندی. اتفاقات. v1 '(جریان/SQL) - p95 ≤ 5 دقیقه
اسمارت جی گر روزانه. v1 '(SQL/MV) - مجموع بر اساس کشور/بازی
خطر/ضد تقلب
خطر <> سیگنال ها v1 '(جریان) - p95 ≤ 30 ثانیه
ریسک میکنم. case_mgmt است. v1 '(SQL) - تاریخچه تحقیقات SCD2
CRM/شخصی سازی
CRM. راه اندازها. v1 '(جریان) - بخش باعث می شود
درست است. ویژگی های. آنلاين. v1 '(KV/SQL) - ویژگی های آنلاین (TTL)
KYC/انطباق
'kyc. وضعیت. v1 '(SQL) - PII محافظت شده، سیاست های سطح ردیف
'پاسخگو _ بازی. اتفاقات. v1 '(جریان) - محدودیت/سیگنال
11) فرآیندهای پلت فرم و مصنوعات
دایرکتوری: جستجو بر اساس برچسب دامنه/زمینه/PII، پیش نمایش نمودارها و نمونه ها.
ژنراتور قالب: cookiecutter برای یک محصول جدید (گذرنامه، CI، آزمون DQ، داشبورد SLO).
سیاست به عنوان کد: قوانین صادرات، PII، به اشتراک گذاری بین مناطق.
قابلیت مشاهده: داشبورد آماده: طراوت، خطاهای DQ، هزینه، خط، تاخیر جریان.
Runbooks: حوادث طراوت/DQ/طرح، استهلاک اضطراری، عقبگرد از نسخه های.
12) مهاجرت به شبکه داده (نقشه راه)
1. موجودی مجموعه داده های فعلی → گروه بندی بر اساس دامنه.
2. خلبان 2-3 دامنه (پرداخت، بازی، خطر) - موضوع را به عنوان محصولات با گذرنامه.
3. کاتالوگ و استانداردها: شماتیک، متریک، PII/محلی سازی، DQ.
4. خود خدمت: قالب خط لوله، CI/CD، نظارت SLO.
5. برش ویترین یکپارچه به کوره انفجار ؛ پشتیبانی از «دو ریل» برای رابط های قدیمی.
6. شورای فدرال - جلسات منظم، بررسی تغییرات قرارداد.
7. مقیاس به CRM/Affiliates/Marketing، سپس شریک شریک.
13) چک لیست پیاده سازی
دامنه های تعریف شده ؛ صاحبان و کانال های ارتباطی اختصاص داده شده است.
فهرست راهنما آغاز شد ؛ گذرنامه هر محصول منتشر شده است.
طرحوارهها - در مخزن قرارداد ؛ CI تست سازگاری/DQ.
SLO/SLA اعلام کرد ؛ داشبورد تازگی/DQ/هزینه در دسترس هستند.
PII/سیاست های محلی سازی - کد ؛ حسابرسی فعال شد
FinOps: بودجه، هشدارها، هزینه گزارش دامنه.
فرآیند نسخه/سپرده - مستند و خودکار.
Runbooks از حوادث - در دسترس و آموزش دیده (روز بازی).
14) ضد گلوله
«تغییر نام داده مش، اما از طریق دستور داده مرکزی» - گردن باریک حذف نمی شود.
فقدان یک فرهنگ لغت واحد از معیارها → GGR/NGR بین دامنه ها متفاوت است.
طرح های بدون قرارداد و تست سازگاری → نسخه های «شکستن».
No Self-serve → هر جدول به صورت دستی ایجاد می شود، زمان بالا به داده ها.
نادیده گرفتن PII/محلی سازی در اشتراک گذاری بین منطقه ای.
محصولات میکرو بدون صاحبان/SLO - داده های «رها شده».
15) KPI موفقیت شبکه داده
زمان به داده: از ایده تا محصول داده موجود (↓ متوسط).
استفاده مجدد: تعداد دامنه های مصرف کننده در هر محصول.
کیفیت: سهم چک DQ موفق، نقص در هر میلیون رویداد.
قابلیت اطمینان: انطباق SLO با طراوت/در دسترس بودن.
هزینه: $/درخواست/کاربر، به اشتراک گذاری فایل های کوچک، دفع محاسبه.
نرخ تغییر: نسخه های مدار/فروشگاه در هر هفته.
خلاصه
Data Mesh نه تنها یک تکنولوژی است، بلکه یک فدراسیون دامنه مدیریت شده است که در آن داده ها محصولات با صاحبان آن، SLO، قراردادها و معیارهای کیفیت است. در iGaming، این رویکرد گردن باریک را حذف می کند، سرعت ادغام (ضد تقلب، پرداخت، CRM)، شفافیت معیارها (GGR/NGR/LTV) را بهبود می بخشد و هزینه را کنترل می کند. ساخت یک پلت فرم خود خدمت قوی، معرفی استانداردهای فدرال و یک فرهنگ داده به عنوان یک محصول، و مقیاس اکوسیستم تجزیه و تحلیل خود را با کسب و کار - بدون از دست دادن کیفیت، سرعت، و یا انطباق.