תוכניות נתונים והאבולוציה שלהם

1) מדוע זוהי פלטפורמת iGaming

אמינות - שינויים בנתונים אינם שוברים דוחות, API או מודלים.
מהירות תכונה: הוספת שדות בבטחה (KYC/RG/PSP) ללא עצירת זרמים.
רגולציה: איתור ויכולת רבייה (ביקורת ביקורת/שושלות, DSAR, Ligal Hold).
עלות: למזער ”עודף” והשבתה של מילוי גב.

2) סוגי מזימות והיכן הן חיות

אירועים (זרמים): "תשלומים. deposit_accepted', המשחק. round_finished'.
OLTP/DDL: שולחנות מנורמלים (KYC, חשבונות, גבולות).
DWH/Storfronts (זהב): אגרגטים מושחתים תחת BI/ML.
חנות תכונה: תכונה מקוונת/לא מקוונת קובעת עם ערבויות עקביות.
חוזי שותפים חיצוניים: PSP, ספקי משחקים, מקורות שיווק.

סימונים: Avro/Protobuf (זרמים), JSON Schema (אינטגרציות), SQL DDL (DWH), schema Parquet (אגם).

3) תאימות (ליבת האבולוציה)

התאמה לאחור: יצרנים חדשים * צרכנים ישנים (נוספה ברירת מחדל C/nullable).
צרכנים חדשים (קורא חדש מתעלם מיותר).
התאמה מלאה: שניהם (מטרה רצויה לאירועים).
שינוי שם/מחיקת שדה, שינוי סוג/סמנטיקה, שינוי מקש/מחיצה.

כלל 1: אירועים מתפתחים באמצעות חיבור, לא באמצעות שינוי.
חוק 2: למחוק - רק בגרסת המייג 'ור של התרשים לאחר תקופת הפחת.

4) גרסאות ומדיניות סמנטיות

מייג 'ור. מינורי. PATCH 'עבור כל מערך תצוגה/תכונה.

מייג 'ור - אי-התאמה (נושא/שולחן/מאפיין חדש ערוך, דו-ריצה).
מינור - תואם (שדות חדשים/ברירת מחדל, ערכי אנום חדשים).
תיקון - עריכת תיאורים/גבולות/הערות.

מחזור חיים שדה: ”experiental _ active = producted ac הוסר” (עם תאריכים ובעלים).

5) רישום מזימות וחוזי נתונים

סכימה רישום: מאגר גרסאות, תאימות, אבולוציה ובעלים.
חוזה נתונים: מתקן את התכונה + SLO איכות + פרטיות (ראה סעיף ”אימות נתונים”).

json
{
"type":"record","name":"deposit_accepted","namespace":"payments",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"user_id","type":"string"},
{"name":"brand","type":"string"},
{"name":"country","type":"string"},
{"name":"psp","type":"string"},
{"name":"method","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":{"type":"enum","name":"Currency","symbols":["EUR","USD","TRY","BRL"]}},
{"name":"risk_score","type":["null","int"],"default":null},       // MINOR+
{"name":"kyc_level","type":["null",{"type":"enum","name":"Kyc","symbols":["L0","L1","L2","L3"]}],"default":null}
],
"compatibility":"FULL","owner":"team-payments"
}

6) דפוסי נדידה

6. 1 אירועים (זרמים)

תוסף בלבד: הוסף שדות עם ברירת מחדל/nullable; צרכנים ישנים לא נשברים.
תווים חדשים נחשבים ל-MINOR, הצרכנים נדרשים להחזיק בסניף ”אחר/לא ידוע”.
הגירה גדולה: התשלומים של הנושא החדש. deposit_accepted. v2 ', דו-כתיבה, קריאת צללים, ואז החלפת צרכנים.

6. 2 DWH/storfronts

שולחנות כחולים-ירוקים: "זהב. revenue_v2' ליד 'v1'; להתממש, לאמת, לעבור BI.
הילוך אחורי: שידור חוזר של תמונות + מיזוג אידמפוטנטים (על ידי מפתחות/גרסאות).
SCD: סוג 2 לשינוי תכונות באיטיות (גבולות, KYC, VIP statuses).

6. 3 חנות מאפיינים

הגשה כפולה: הסט הישן מוגש במקביל לחדש; הדגם מופעל באמצעות נתב.
עקביות נקודתית: האבולוציה לא צריכה לשבור את השמחות של PITA (חותמת זמן/גרנולריות לא משתנות בMINOR).

7) טקסונומיה של שינויים (רשימה)

• הוספת שדה/ברירת מחדל;
• סיומת אנום (עם סניף ”לא ידוע” אצל הצרכן);
• הוספת אינדקס/תגובה/תיאור שאינו מפתח.

• שינוי קנה מידה/יחידה (לדוגמה, סכום של סנט = מטבע בסיס) - מז "ן בלבד
• העברה/התייחסות - דרך שכבת המצגת.

• שינוי שם/מחיקת שדה
• שינוי סוג/פורמט/מפתח/מחיצה
• שינוי הסמנטיקה (לדוגמה, 'בונוס _ כמות' מ ”הצטבר” = ”נכתבה”).

8) מקשרי מעגל ומבחני תאימות

סכימה מוך: סגנון שם (”snake _ case”), תוויות דרושות (”בעלים”, ”doc”, ”pii”), תבנית תאריך/מטבע.
בדיקות קומבט: בדיקת הגרסה החדשה כנגד הרישום (אחורה/קדימה/מלא).
בדיקות חוזה-צרכן: כל שירות מספק ”מטען דגימה” וציפייה; לרוץ על מודיע בעת שינוי המזימה.
Golden-datasets: קבוצה של דוגמאות אמיתיות ו ”רעות” (enum חדש, שדות ריקים/מאוחרים, ערכי גבול של סכומים).

9) ספריות, חוקן ולוקליזציה

Reference-Data (מדינות/מטבעות/PSP/ספקים): גרסאות בודדות ועדכוני SLA; לא לתפור לתוך קוד האירוע.
אזורי Locale/time: לאחסן UTC באירועים + מיקום מפורש להצגה.
כללי שיפוט: דגלי גיל, הגבלות פרומו - בצורה של ספריות עם תאריכי פעולה.

10) Multi-Brand/Multi-שיפוט ו-PII

בידוד דייר: ”מותג”, ”מדינה”, ”רישיון” - שדות חובה עם enum; ניתוב עליהם.
מדיניות PII ברמת סכימה: לסמן את השדות ”pii = אמת”, ליישם מסכות/טוקניזציה; באירועים, רק אסימונים.
DSAR: נוכחות של 'source _ id/trace _ id' or מחיקה/החזרה; אחיזה משפטית בנדידת מייג 'ור.

11) DDL ו ־ Lake Versioning

נדידת DDL: הגירה הצהרתית (Liquibase/Flyway/dbt), אחסון ב-VCS, סקירה על ידי בעל התחום.
פורמטים באגם: Avro/Parquet - רשמו את התפתחות השדות; בסרן - שולחן חדש/שביל ”.../v2/”.
מחיצה: החלפת חלקים (לדוגמה, ”תאריך” ”תאריך, מותג”) - רק דרך מייג 'ור וכניסה כפולה.

12) דוגמאות של iGaming

12. 1 PSP שיטות מורחבות

שיטה נוספת = ”MEFETE” ל-enum.
שחרור מינורי של v1 המקובל. 8. 0`; צרכנים שאינם מכירים את MEFETE שולחים סניף ל ”שיטה _ לא ידועה”.

12. 2 ספקי משחקים נוספו

וי 'גיים. round_finished' הוסיף 'jackpot _ id' (nullable).
זהב של תצוגה. game_rounds_v3' מקבל מינור; דוחות ישנים עובדים, חדשים סופרים זכיינים.

12. 3 תכונות RG

מעבר מ-Boolean 'self _ nulded' ל-status 'rg _ state _ non, הגבלה, התקררות, self_excluded}' - MAJOR, נושא חדש + dual-write + הגירה של תצוגות ומודלים.

13) תהליך אבולוציה (מרעיון להחלפה)

1. הצעה (ADR): מדוע שינוי, סוג של תאימות, הערכת סיכונים והשפעה על הצרכנים.
2. עיצוב וחוזה: תוכנית לרישום, סמבר, מדיניות תאימות.
3. בדיקות: לינטרים, קומבט, חוזים צרכניים, שידור חוזר על זהב-סט.
4. פריסה: כתיבה כפולה/כחול ירוק/קריאות צללים; התראות.
5. פיוס: Business מאזן/invariants (ראה אימות נתונים).
6. החלפה: לעבור צרכנים/BI/תכונות.
7. להקפיא סכמות ישנות, תקופת חסד, למחוק וארכיון.

14) Metrics ו ־ SLOs של אבולוציה

אחוזי הצלחה בנדידה, זמן ריצה כפול, שיתוף באירועי פורמט חדשים, נפח גיבוי, פיגור/רעננות.
תקריות תאימות (P1/P2), איכות החלון לאחר ההחלפה.
עלות: $/TB עודף, $/שעה דו-כתיבה, עומס אשכול.
ציות: 0 דליפות PII, SLA DSAR/Legal Hold נפגש.

15) כלים וחפצים

15. 1 מדיניות תאימות (רישום)

yaml schema: payments. deposit_accepted compatibility: FULL default_nulls: true enums:
currency: {allow_new_symbols: true, require_consumer_unknown_branch: true}
pii: false owners: ["team-payments"]
reviewers: ["data-governance","security-dpo"]

15. 2 דרכון נדידה (תבנית)

yaml change_id: MIG-2025-041 scope: game. round_finished -> v3 type: MAJOR plan:
dual_write: true shadow_reads: consumers: ["gold-rounds","rg-models"]
backfill: {from: "2025-01-01", mode: "idempotent-merge"}
validation:
invariants: ["sum_bets = sum_wins + margin + bonuses"]
freshness_delta_p95_max: "PT5M"
switch_criteria:
error_rate_max: 0. 1%
kpi_diff_pp_max: 0. 5 deprecate_after: "2025-12-31"

15. 3 לינטר של שמות וסוגים (כללים)

'sake _ case', UTC timestamps, עשרוני (18. 2) עבור סכומים, 'מדינה' עבור אלפא-2 ISO-3166-1, 'מטבע' עבור ISO-4217.
No 'free _ text' for enum fields; ספרי עיון - חיצוניים.

16) מימוש מפת דרכים

0-30 ימים (MVP)

1. אפשר סכימת מדיניות תאימות עבור אירועי מפתח (תשלומים, game_rounds, משתמש).
2. מבחני לינטרס/קומבט במצ "ח; ספריית בעלים וביקורות SLA.
3. תבניות ADR ודרכון הגירה; רשימת בדיקות גדולה.

30-90 ימים

1. Blue-Green for Gold Storfronts; כתיבה כפולה לנושאים ביקורתיים.
2. בדיקות צרכניות לשירותים בסיסיים; נתונים מוזהבים.
3. אוטומטי diff-פיוס והתראות בעת החלפה; דוחות עלות.

3-6 חודשים

1. תהליך הפחתה/הסרה יחיד עם תקופת החן; אחיזה ארכיונית ומשפטית.
2. תוכניות הצפנה ומפתחות ספציפיים לגיאו/דייר; וריאציות DP לשווקים רגישים.
3. מילון נתונים ותרשימי שושלת חיים.

17) ראסי

ממשל נתונים (A/R): סטנדרטים, רישום, ביקורת הגירה, דה-פרסום.
בעלי דומיין (R): משמעות של שדות, ספרי עיון, אינווריאנטים עסקיים.
פלטפורמת נתונים (R): כלי רישום, בדיקות קומבט, דו-ריצה/מילואים.
אבטחה/DPO (A/R): מדיניות PII, גיאו/דייר, DSAR/Legal Hold.
SRE/Observability (C): התראות, אבולוציה SLO, קיבולת.
מוצר/פיננסים (C): אימות של KPIs, החלפת חלונות.

18) אנטי דפוסים

”ערוך את השדה בזבוב” ללא גרסאות ודו-ריצה.
שינוי שם במקום להוסיף שדה חדש * התמוטטות מסיבית.
קשיחות ללא ענף ”לא יודע” טיפה בערכים חדשים.
ספרייה אחת ”בקוד” לכל תחומי השיפוט.
חזרה ללא אידמפוטנט מיזוג ולבדוק מאזנים.
יומנים עם PII וללא trace_id לחיפוש/DSAR.

19) חלקים קשורים

אימות נתונים, מקור נתונים ונתיב, פרקטיקות DataOps, Analytics ו-Metrics API, ביקורת, אבטחת נתונים והצפנה, בקרת גישה, MLOps: ניצול מודל.

סך הכל

התפתחות מזימות היא תהליך, לא נדידה חד פעמית: רישום, גרסאות ואינטרפרטציה; דו-ריצה וכחול-ירוק במקום ”מתגים בחצות”; מבחני תאימות ועסקים במקום מזל. אז הנתונים נשארים יציבים, המודלים צפויים, הדוחות נכונים, והרגולטורים רגועים.