Mesh נתונים: מודל נתונים פדרלי
(סעיף: טכנולוגיה ותשתיות)
תקציר
Data Mesh הוא מודל ארגוני וטכני שבו נתונים מטופלים כמוצרים של צוותי דומיין, והתפקיד המרכזי של הפלטפורמה הוא לספק שירות עצמי, סטנדרטים וציות. עבור iGaming, משמעות הדבר היא: קבוצת התשלומים מחזיקה ב-Deposits Events וב-Net Deposits Mart, קבוצת Risk מחזיקה ב ”אותות הונאה”, Games מחזיקה ב-Bet Events וב-Leaderboard, והפלטפורמה המרכזית נותנת קטלוג, תוכניות חוזה, גישה, ניטור איכות, הזרמת כלים וכלים.
1) עקרונות רשת נתונים
1. אחריות Domain: כל תחום (תשלומים, סיכון, משחקים, KYC/Complication, CRM, Associate) הוא הבעלים של מערך הנתונים שלו ומחזור החיים שלו.
2. נתונים כמוצר: לכל סט יש בעלים, תיאור, SLO, גישה ל SLA, תיעוד, גרסה, משוב ומפת דרכים.
3. פלטפורמת שירות עצמי: צינורות סטנדרטיים בלע/טרנספורמציה/הגשה, תבניות, ביטחון ברירת מחדל, תיקייה ויכולת תצפית.
4. ניהול פדרלי: סטנדרטים משותפים של תוכניות, מדדים, פיל/לוקליזציה ואיכות במרכז; יישום ואבולוציה בתחום.
2) מודל הפעלה ותפקידים
Domain Data Product בעלים (DPO): עדיפות, SLO, גיבוי של שיפורים במוצר הנתונים.
מהנדס נתונים/אנליטיקה: שרטוטים, צינורות, מבחני DQ, ורסיונינג.
Domain Steward: סמנטיקה בשטח, התכתבות למילון Metrics וסיווג PII.
צוות הפלטפורמה: קטלוג, IAM/RBAC, מדיניות-as-Code, פורמטי שולחן (דלתא/קרחון/האדי), תזמור, תצפית, פינופים.
מועצת הפיקוח הפדרלית (Federated Government Board): מאשר סטנדרטים (תוכניות, מדדים, אבטחה), פותר סכסוכים בין תחומים.
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 + Schema Registry; מדיניות גיבוי, אין שבירת שינויים ללא גרסה מרכזית חדשה.
שכבה סמנטית: הגדרות מאוחדות של GGR, NGR, Net Deposits, LTV, Cohorts - כקוד (dbt metrics/semantic layer).
זיהוי: "player _ id'," terant _ id', "bet _ id', ספריות מדינה/מטבע/ספקים מאוחדים.
Metadata: העמודות הנדרשות ”inbleget _ ts',” schema _ version ”,” trace _ id', ”source”, ”region”.
גישה: SQL (Lakehouse/OLAP), זרם (Kafka/Pulsar), שיתוף שולחן/תצלום; פורמט ההחלפה הוא פרקט/דלתא/קרחון.
5) תקן התייחסות לתהליך (אגנוסטיקן לספקים)
Innight: Outbox/CDC LOLTP # Kafka # Lakehouse (ברונזה).
שינוי צורה: ELT/dbt Silver/Gold; ”התמזגות”, SCD, תיקי תצוגה חומריים.
שירות: OLAP (ClickHouse/BigQuery/Snowflake), RT-II-Associate (Pinot/Druid).
קטלוג/לינאז ': קטלוג יחיד, תיעוד אוטומטי, גרף תלות.
תצפית: רעננות/מדטי SLO, DQ-assert, lags זרם, עלות.
מדיניות: IAM/RBAC/ABAC, הצפנה, לוקליזציה (ניתוב מידע אזורי).
6) SLO/SLA למוצרי נתונים
דוגמאות ל-SLOS מטרה:- רעננות: הימורים על אירועים (p95) 5 קרקעות. אותות הונאה מנועים 30 שניות; רשת הפיקדונות מארט על 15 דקות.
- זמינות: 99. 9% עבור ממשקי קריאה.
- איכות: כפילויות על בסיס 0. 01%, חלק מהשדות הריקים הדרושים 0. 1%, עקביות מטבע 100%.
- עלות SLO: עלות סריקות החלון על פני N $/Day, יחס קבצים קטנים <10%.
7) בטיחות, מח "ש ומיקום
סיווג: PII/רגיש פיננסי/תפעולי.
אמצעים טכניים: הצפנה במנוחה/במעבר; tokenization PII; מסווה עמודות; פילטרים ברמה של "דייר _ id'.
לוקליזציה: מוצרי דומיין מתפרסמים באזורים מורשים (EU/TR/LATAM); רק יחידות ללא מח "ש.
ביקורת: מי פרסם/קרא; סכימה גרסה זכויות הסלמה בקשות - באמצעות אישור.
8) פינוסים וניהול ערך
תקציבים לפי תחום: גבולות חישוב, התראות יתר.
אחסון: שיעורי אחסון + TTL (ברונזה קצרה, כסף בינוני, זהב ארוך/אגרגטים).
אופטימיזציה שאילתה: מחיצות/קיבוצים, תצוגות ממומשות, מטמון תוצאות BI.
קבצים קטנים: מדיניות compaction/OPTIMIZE; גודל קובץ המטרה הוא 128-1024 MB.
9) מחזור חיים ואבולוציה
ורסיונינג: "תחום. מוצר. V 'major'; שדות מינוריים - בחזרה-compat.
פחת: הודעה לצרכן, תקופת ”שתי מסילות”, התראות אוטומטיות לגרסאות ישנות יותר.
סכימה משתנה: Pull Request to cose repository; מבחני תאימות מז "פ; AutoPublish לקטלוג.
משוב: ערוץ מוצר (גשש), NPS צרכני, זמן תגובת אירוע.
10) קונקרטיזציה עבור iGaming - תחום ומפת מוצר
תשלומים
'תשלומים. psp. קורות אינטרנט. v1 '(זרם)
'mart _ net _ deposits _ daily. רעננות SLO 15 דקות; ללא PII
משחקים
'הימורים. אירועים. V1 '(זרם/SQL) - p95 יור 5 דקות
'Mert _ gr _ יומי. V1 (SQL/MV) - צבירה על ידי מדינה/משחק
סיכון/אנטי-הונאה
'סיכון. אותות. v1 '(זרם) - p95 עוד 30 שניות
"להסתכן. case_mgmt. V1 (SQL) - SCD2 תולדות החקירה
CRM/personalization
crm. מעורר. v1 '(זרם) - הפעלות קטע
"פרופיל. תכונות. באינטרנט. V1 (KV/SQL) - תכונות מקוונות (TTL)
KYC/Complication
'kyc. סטטוס. PII מוגן, מדיניות רמה שורה
'gaming אחריות _. אירועים. v1 '(זרם) - גבולות/אותות
11) תהליכי פלטפורמה וחפצים
ספרייה: חיפוש לפי תחום/שדות/תוויות PII, תצוגה מקדימה של דיאגרמות ודוגמאות.
גנרטורים של תבנית: חרטום עוגיות למוצר חדש (דרכון, בדיקות CI, DQ, לוח מחוונים SLO).
מדיניות: כללי ייצוא, מח "ש, שיתוף בין אזורים.
לוח מחוונים מוכן: רעננות, שגיאות DQ, עלות, לינאז ', זרם לג.
רנטגן: תקריות של רעננות/DQ/מזימות, פחת חירום, rollback של גרסאות.
12) הגירה למאגר נתונים (מפת דרכים)
1. מלאי של נתונים עדכניים * התקבצות לפי תחום.
2. פיילוט 2-3 תחומים (תשלומים, משחקים, סיכון) - הנפקה כמוצרים עם דרכונים.
3. קטלוג וסטנדרטים: שרטוטים, מדדים, PII/localization, DQ.
4. הגשה עצמית: תבניות צינור, סי-איי-די, מעקב SLO.
5. חיתוך תצוגות מונוליטיות לכבשן פיצוץ; ”שני רכבות” תמיכה לממשקים ישנים.
6. מועצה פדרלית, פגישות קבועות, שינויים בחוזה.
7. קנה מידה ל-CRM/Associates/שיווק, ואז שיתוף שותף.
13) רשימת מימושים
Domains מוגדר; בעלים וערוצי תקשורת מוקצים.
הספרייה החלה; הדרכון של כל מוצר מתפרסם.
תוכניות - במאגר החוזה; בודק תאימות/DQ.
SLO/SLA הכריז; רעננות/לוחות מחוונים זמינים.
מדיניות PII/לוקליזציה - קוד; ביקורת חשבונות הופעלה.
פינוקס: תקציבים, התראות, עלות לפי דו "ח תחום.
תהליך ורסינינג/הפקדה - מתועד ואוטומטי.
רנטגן של תקריות - זמין ומאומן (משחק-יום).
14) תרופות אנטי ־ פטריות
”שונה שם דאטה Mesh, אבל כל דרך פיקוד הנתונים המרכזי” - הצוואר הצר לא בוטל.
היעדר מילון יחיד של metrics = GGR/NGR שונה בין התחומים.
מזימות ללא חוזים ומבחני התאמה = ”שבירה” משחרר.
אין הגשה עצמית = כל טבלה נוצרת ידנית, בזמן גבוה למידע.
התעלמות מח "ש/לוקליזציה בשיתוף חוצה אזורי.
מוצרים זעירים ללא בעלים/SLO - נתונים ”נטושים”.
15) Data Mesh Success KPI
זמן למידע: מרעיון למוצר נתונים זמין (median data).
שימוש חוזר: מספר תחומי צריכה למוצר.
איכות: נתח של בדיקות DQ מוצלחות, פגמים למיליון אירועים.
אמינות: ציות SLO עם רעננות/זמינות.
עלות: $/בקשה/משתמש, שיתוף קבצים קטנים, סילוק חישובי.
קצב השינוי: מעגל/חנות משחרר בשבוע.
תקציר
Data Mesh היא לא רק טכנולוגיה, אלא גם פדרציית דומיין מנוהלת, שבה נתונים הם מוצרים עם בעליה, SLO, חוזים ומדדים איכותיים. ב-iGaming, גישה זו מסירה צוואר צר, מאיצה את האינטגרציה (אנטי-הונאה, תשלומים, CRM), משפרת את שקיפות המדדים (GGR/NGR/LTV) ואת עלות השליטה. לבנות פלטפורמה חזקה לשירות עצמי, להציג סטנדרטים פדרליים ותרבות נתונים כתוצר, ומערכת אקולוגית האנליטיקה שלך מאזנת עם עסקים - מבלי לאבד איכות, מהירות, או ציות.