בקרת איכות נתונים

1) מטרה ועקרונות

דו "חות אמינים (GGR/Miss), נוגדי הונאה ומודלים של RG, העלאות ציות, מוצרים ואישיות.

• Schema-First & Contracts: כל המקורות נדרשים לפרסם נתוני חוזה.
• חוקים במאגר, גרסאות, בדיקות וביקורות.
• תצפית על ידי ברירת מחדל: metrics/logging/lineage.
• פרטיות לפי עיצוב: מינימום PII, מיסוך ו-RLS/CLS.
• מודעות עלות: עדיפות של כללים קריטיים, דגימות חכמות.

2) טקסונומיה של מידות איכות

שלמות - אחוז של שדות/שורות דרושים.
סוגי התאמות תוקף/טווחים/ספרי עיון.
ייחודיות: לא לשכפל מפתחות/אירועים.

עקביות: יושר התייחסותי, בעלי עסקים

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

איכות וביקורתיות של KPIs (קריטי/מייג 'ור/מינור) מוגדרות עבור כל תחום.

3) חוזים ותכניות (מקור האמת) ‏

חוזי נתונים: JSON Schema/Avro/OpenAPI/ASyncAPI.
יציבות: שינויים התואמים לאחור - מוסיפים נאול; שובר - גרסה חדשה + כניסה כפולה.
עקבות: באירועים - ”event _ id',” trace _ id', ”schema _ version”, ”source”.

4) DQ-as-קוד: מבנה חפץ

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

כללים: הצהרתי YAML/SQL;

חומרה: מיפוי תעלות אזהרה/רמות הסלמה;

מודיע: ספינים מעגליים, בדיקות תאימות, הפעלה יבשה/סימולטור.

5) כללי דוגמה (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) בדיקות SQL (דוגמאות)

ייחודיות של מפתחות

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

השלמות שדה נדרשת

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

הפניות/עקביות

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) הזרמת DQ (בזמן אמת)

אימות-בלע: אימות סכימה, גבולות גודל, טיפוסים ואינום.
בדיקות בזרם: dedup '(event_id, מקור)', איחור מותר, תוקף מטבע/כמות.
גבולות: שגיאות קריטיות * DLQ + התראה; תג לא קריטי, אבל לדלג (עם דגל dq _ flag).
מטריות: שלמות/lag/dup-קצב על ידי צד.

8) טיפול בטעויות ובחריגות

DLQ/הסגר: רשומות חולים מוחזקות, זמינות לתיקון.
רשומות חריגות: הוצאת כרטיס (בעלים, תאריך, סיבה, אזור).
נסיגה אוטומטית: השתמש בתמונה הנכונה האחרונה של תיק התצוגה.
סגירת SLA: שעות 24-48 חשובות; ימיהם של 5 עובדים.

9) תיאום עם פרטיות וציות

מזעור PII: לא לבדוק ”גולמי” PII בשכבות אנליטיות; השתמש בשמות בדויים.
בדיקות RLS/CLS מבוצעות על סמך מיסוך שדה.
Regionalization: כללים לוקחים בחשבון ”תחום שיפוט” (EEA/UK/BR).
אין כתיבה מחדש של ארכיונים כחלק מההמתנה.

10) יכולת תצפית, SLI/SLO והתראות

• רעננות p95 (כסף): 15 דקות
• שלמות (סוגים קריטיים): 99. 5%.
• תוקף (סכימה): (99). 9%.
• קצב שכפול: סימון 0. 1%.
• תקרית DQ MTR: 24-48 פדידה.

התראות: ביפר עבור קריטי, אנטי-זהות, חלונות תחזוקה.

11) לוחות מחוונים (סט מינימלי)

מפת חום טריות/שלמות לפי תחום ושוק.
טבלאות טופ N לפי שיעור אירוע ועל ידי עלות תיקונים.
משפך DQ: בלע * כסף * זהב (הפסד/תיקון).
מפת לינדג 'לדיווחים קריטיים (רגולטור/GGR/RG/AML).
מפה של סכימות ”מורשת” ולקוחות (גרסאות SDK/schema).

12) תהליכים ו ־ RACI

R (אחראי): הנדסת נתונים (כללים על טבלאות), בעלי דומיין (סמנטיקה).
א '(אחראי): ראש הנתונים/CDO.
C (ייעוץ): ציות/משפטי/DPO, ארכיטקטורה, SRE.
I (מיודע): BI/Third Diamond/Diamond Design/Diamond Design.

Rule Lifecycle: exply Review = "Dark Run' = lincly Lifecture Life: surv

13) פיוס ודיוק

Checksums/transfactions: כספת עם ספקים/OLTP (PSP/KYC).
השוואות שתי לולאות: צינור עצמאי לאימות סלקטיבי.
סובלנות היא אחוז סף על ידי מדדים (לדוגמה: שוני GGR על 0. 2%).
פעולות יומיות: דו "חות פיוס ביקורת.

14) עלות ותעדוף

הפעל חוקים ביקורתיים לעתים קרובות יותר (זרימה/שעה), מדי יום ביומו.
השתמש בהוצאות ובצ 'קים ממשיים לשולחנות כבדים.
עקוב אחר עלות/שאילתה ועלות/GB, הפעל התקבצות/אינדקס.
הקצאת תקציב ל-DQ בהקשר של קבוצות (chargback).

15) תבניות למחסני זהב (דוגמה יומית של GGR) ‏

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) אירועים איכותיים: ניהול ותקשורת

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

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

1. קטלוג טבלאות קריטיות (תשלומים, משחק, GGR, ציות).

2. כללי YAML לבדיקות מפתח 10-15 + אימות CI.

3. רעננות/לוח מחוונים מושלם והתראות עבור קריטי.

4. תיקוני DLQ/הסגר + runbook.

• סיומת חוק (FK/דיוק), סימולטור הפעלה יבש, הכללות A/B.
• שילוב שושלות, סידורי חריגים ותאונות.
• הזרמת DQ על בלע למקורות ”רועשים”.

• אוטוגנרציה של תיעוד על ידי כללים, מדדי עלות.
• ”קווי שליטה” (פיוס עצמאי), רטרוספקטיבה שבועית.
• פלטפורמת Rule-as-Code SDKs, רישום של בדיקות דומיין סטנדרטיות.

18) רשימת בדיקות לפני המכירה

[ חוזים ותוכניות ] ברישום, מבחני התאמה עוברים.

[ ] חוקי YAML הוקפאו, חומרה/הסלמה הוקצו.

[ ] לוחות המחוונים וההתראות פעילים; סל "ד מוגדרים ומוסכמים.

[ ] DLQ/הסגר זמין, ספרים מתועדים.

[ ] Exception/Poisilation Processions Suffice with Legal/

[ ] מדידה של עלות הבדיקות והגבלת הבקשות הכבדות.

19) טעויות תכופות וכיצד להימנע מהן

מידע גולמי ללא חוזים: הכנס תרשים-ראשון ומבחני צרכן.
בדיקות ”ידניות”: לתרגם ל-DQ-as-קוד ו-CI.
אין עדיפות: נפרדים בערוצים קריטיים/מרכזיים/מינוריים ומתריעים.
אין DLQ: אין מה לעבוד עם טעויות - להוסיף הסגר.
התעלם מהעלות: שאילתות פרופיל, השתמש במימוש.
אין בדיקות שלאחר המוות: טעויות חוזרות ונשנות - הזן CAPA ובקרת רגרסיה.

20) השורה התחתונה

מערכת בקרת איכות המידע אינה מערכת של המחאות מפוזרות, אלא תוכנית מנוהלת: חוזים ותוכניות, DQ-as-code, תצפית ו-SLO, תקרית ומשמעת פיוס. אם תעקוב אחר מאמר זה, תזכה למידע בר רבייה, ניתן לאימות ויעיל מספיק לדיווח רגולטורי, לפתרונות מוצר ולגלאי סיכונים בזמן אמת.