مراقبة جودة البيانات

1) الغرض والمبادئ

لماذا: تقارير موثوقة (GGR/الضرائب)، نماذج مكافحة الاحتيال و RG، تحميلات الامتثال، المنتجات والتخصيص.

• Schema-first & Contracts: جميع المصادر مطالبة بنشر بيانات العقد.
• DQ-as-code: القواعد الواردة في المستودع والنسخ والاختبارات والاستعراضات.
• الملاحظة الافتراضية: المقاييس/قطع الأشجار/النسب.
• الخصوصية حسب التصميم: الحد الأدنى من PII، والإخفاء و RLS/CLS.
• إدراك التكلفة: تحديد أولويات القواعد الحرجة والعينات الذكية.

2) تصنيف قياسات الجودة

الكمال - النسبة المئوية للحقول/الصفوف المطلوبة.
أنواع/نطاقات/كتب مرجعية.
التفرد: لا توجد مفاتيح/أحداث مكررة.

الاتساق: النزاهة المرجعية، الثوابت التجارية

الدقة - النهج المصدر «الحقيقي» (التسويات الموجزة).
الجدول الزمني/النضارة - التأخير المادي.
نزاهة النسب: الحفاظ على أصل/نسخ التحولات.

يتم تحديد مؤشرات الأداء الرئيسية للجودة والحرجية (الحرجة/الرئيسية/الثانوية) لكل مجال.

3) العقود والمخططات (مصدر الحقيقة)

عقود البيانات: JSON Schema/Avro/OpenAPI/AsyncAPI، التي يستضيفها Registry.
الاستقرار: تغييرات متوافقة مع الخلف - إضافة غير قابلة للإلغاء ؛ كسر - إصدار جديد + إدخال مزدوج.
إمكانية التتبع: في الأحداث - 'event _ id'، 'trace _ id'، 'schema _ version'، 'source'.

4) DQ-as-code: بنية القطع الأثرية

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

القواعد: إعلانات YAML/SQL ؛

الشدة: رسم خرائط → قنوات الإنذار/مستويات التصعيد ؛

CI: بطانات الدائرة، اختبارات التوافق، التشغيل الجاف/المحاكاة.

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 (في الوقت الفعلي)

التحقق من الصحة: التحقق من صحة المخطط، حدود الحجم، الأنواع و enum' s.
الشيكات في البث: التخلص '(event_id، المصدر)'، يسمح بالتأخير، وصحة العملة/المبلغ.
الحدود: أخطاء فادحة → تنبيه DLQ + ؛ ليس بالعلامة → الحرجة، ولكن تخطي (بعلم «dq _ flag»).
المقاييس: الاكتمال/التأخر/معدل الارتفاع حسب الطرف.

8) معالجة الأخطاء والاستثناءات

DLQ/الحجر الصحي: السجلات المرضية محتفظ بها ومتاحة للتصحيح.
سجلات الاستثناء: بطاقة الاستبعاد (المالك، التاريخ، السبب، المنطقة).
الاحتياطي التلقائي: استخدم آخر لقطة صحيحة لعلبة العرض.
إغلاق جيش تحرير السودان: ≤ حرجة - 24-48 ساعة ؛ - ≤ 5 أيام عمل.

9) التنسيق مع الخصوصية والامتثال

التقليل من PII: لا تتحقق من PII «الخام» في طبقات تحليلية ؛ استخدم الأسماء المستعارة.
يتم إجراء RLS/CLS-Checks على أساس القناع الميداني.
Regionalisation: Rules takes 'jurisdiction' (EEA/UK/BR).
عقد قانوني: لا إعادة كتابة المحفوظات كجزء من الانتظار.

10) إمكانية الرصد، SLI/SLO والتنبيهات

• النضارة p95 (الفضة): ≤ 15 دقيقة
• الاكتمال (الأنواع الحرجة): ≥ 99. 5%.
• الصلاحية (المخطط): ≥ 99. 9%.
• معدل مكرر: ≤ 0. 1%.
• حادثة DQ MTTR: ≤ 24-48 ч.

التنبيهات: جهاز استدعاء لنوافذ الصيانة الحرجة المضادة للاستعارة.

11) لوحات القيادة (المجموعة الدنيا)

النضارة/خريطة الحرارة الكاملة حسب المجال والسوق.
أعلى جداول N حسب معدل الحوادث وتكلفة التصحيحات.
قمع DQ: تناول الفضة → → الذهب (خسارة/تصحيح).
خريطة قائمة بالتقارير الهامة (المنظم/GGR/RG/AML).
خريطة مخططات «الإرث» والعملاء (إصدارات SDK/schema).

12) العمليات و RACI

R (مسؤول): هندسة البيانات (قواعد على الجداول)، مالكو المجال (دلالات).
ألف (مسؤول): رئيس قسم البيانات/المدير التنفيذي.
جيم (استشاري): الامتثال/القانون/إدارة الشؤون السياسية، الهندسة المعمارية، SRE.
أنا (أبلغت): BI/Продукт/Маркетинг/Финансы/Операции.

دورة حياة القاعدة: عرض مراجعة → → «الركض المظلم» → الإدماج → والمراقبة → بأثر رجعي.

13) التسوية والدقة

الشيكات/المعاملات: قبو مع OLTP/مقدمي (PSP/KYC).
مقارنات ذات حلقتين: خط أنابيب مستقل للتحقق الانتقائي.
التحمل هو عتبات النسبة المئوية حسب المقاييس (على سبيل المثال الفرق GGR ≤ 0. 2%).
القوانين اليومية: تقارير تسوية مراجعة الحسابات.

14) التكلفة وتحديد الأولويات

قم بتشغيل القواعد الحرجة في كثير من الأحيان (البث/كل ساعة)، بسيط - يوميًا.
استخدم عمليات الجلب والفحوصات المجسدة للجداول الثقيلة.
تتبع التكلفة/الاستعلام والتكلفة/GB، وتطبيق التجميع/الفهرسة.
تخصيص ميزانية لـ DQ في سياق الفرق (رد التكاليف).

15) قوالب واجهات متاجر الذهب (مثال GGR Daily)

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) حوادث الجودة: الإدارة والاتصال

إصدار التذاكر: الإنشاء التلقائي للمهام مع الاختيارات والمقاييس المرفقة.
قوالب Comm: إخطار مالكي/المنظمين عند التأثر.
بعد الوفاة: السبب الجذري (انجراف المخطط، حشرة المنبع، الحمل)، إجراءات CAPA، التحكم في «عودة الانحدار».

17) خارطة طريق التنفيذ

1. فهرس الجداول الحرجة (المدفوعات، طريقة اللعب، GGR، الامتثال).

2. قواعد YAML لـ 10-15 فحصًا رئيسيًا + التحقق من صحة CI.

3. لوحة القيادة النضرة/الاكتمال والتنبيهات للحرجة.

4. إصلاح DLQ/الحجر الصحي + دفتر التشغيل.

• تمديد القاعدة (FK/الدقة)، ومحاكاة التشغيل الجاف، وإدراج A/B.
• تكامل النسب، وترتيبات الاستثناء واتفاقات الحد من الفقر.
• بث DQ على الابتلاع لمصادر «صاخبة».

• التوليد الذاتي للوثائق حسب القواعد، مقاييس التكلفة.
• «خطوط التحكم» (مصالحة مستقلة)، بأثر رجعي أسبوعي.
• منصة قواعد الرموز SDKs، سجل للتحقق من النطاقات القياسية.

18) قائمة مرجعية قبل البيع

• العقود والمخططات في قلم المحكمة، تنجح اختبارات التوافق.
• تم تجميد قواعد YAML، وتم تحديد الشدة/التصعيد.
• لوحات المعلومات والإنذارات نشطة ؛ وتحدد وتوافق هذه المنظمات.
• DLQ/الحجر الصحي متاح، وكتب التشغيل موثقة.
• إجراءات الاستثناء/التسوية المتفق عليها مع القانون/الامتثال.
• قياس تكلفة عمليات التفتيش والقيود المفروضة على الطلبات الثقيلة.

19) الأخطاء المتكررة وكيفية تجنبها

البيانات الأولية بدون عقود: إدخال المخطط أولاً واختبارات المستهلك.
الشيكات «اليدوية»: تُترجم إلى DQ-as-code و CI.
عدم تحديد الأولويات: قنوات منفصلة حاسمة/رئيسية/ثانوية وقنوات تنبيه.
لا يوجد DLQ: لا يوجد شيء للعمل مع الأخطاء - أضف الحجر الصحي.
تجاهل التكلفة: استفسارات الملف الشخصي، استخدام التجسيد.
لا تشريح: تتكرر الأخطاء - أدخل CAPA والتحكم في الانحدار.

20) خلاصة القول

نظام مراقبة جودة البيانات ليس مجموعة من الفحوصات المتفرقة، ولكنه برنامج مُدار: العقود والمخططات، DQ-as-code، إمكانية الملاحظة و SLO، انضباط الحوادث والمصالحة. من خلال اتباع هذه المقالة، ستتلقى بيانات قابلة للتكرار ويمكن التحقق منها وفعالة من حيث التكلفة كافية للإبلاغ التنظيمي وحلول المنتجات وأجهزة كشف المخاطر في الوقت الفعلي.