کنترل کیفیت داده ها

1) اهداف و اصول

چرا: گزارش های قابل اعتماد (GGR/مالیات)، مدل های ضد تقلب و RG، آپلود انطباق، محصولات و شخصی سازی.

• Schema-first & Contracts: تمام منابع برای انتشار داده های قرارداد مورد نیاز است.
• DQ-as-code: قوانین در مخزن، نسخه ها، تست ها و بررسی ها.
• مشاهده به صورت پیش فرض: metrics/logging/lineage.
• حریم خصوصی توسط طراحی: PII حداقل، ماسک و RLS/CLS.
• هزینه آگاه: اولویت بندی قوانین مهم، نمونه های هوشمند.

2) طبقه بندی اندازه گیری های کیفیت

کامل بودن - درصد فیلدها/ردیف های مورد نیاز.
اعتبار-مسابقات انواع/محدوده/کتاب های مرجع.
منحصر به فرد: هیچ کلید/رویدادهای تکراری وجود ندارد.

سازگاری: یکپارچگی ارجاعی، تغییرناپذیر کسب و کار

دقت نزدیک «درست» منبع (خلاصه آشتی).
جدول زمانی/طراوت - تاخیر مواد.
یکپارچگی خط: حفظ مبدأ/نسخه های تحولات.

KPI های کیفیت و بحرانی (بحرانی/عمده/جزئی) برای هر دامنه تعریف شده است.

3) قراردادها و طرح ها (منبع حقیقت)

قراردادهای داده: JSON Schema/Avro/OpenAPI/AsyncAPI، میزبانی شده توسط رجیستری.
پایداری: تغییرات سازگار با عقب - اضافه کردن nullable ؛ شکستن - نسخه جدید + ورود دو.
قابلیت ردیابی: در رویدادها - «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 (زمان واقعی)

Ingest-validation: schema validation, size-limits, types and enum's را وارد کنید.
چک در جریان: dedup '(event_id، منبع)'، تاخیر مجاز، اعتبار ارز/مقدار.
مرزها: خطاهای بحرانی → DLQ + هشدار ؛ برچسب → بحرانی نیست، اما جست و خیز (با پرچم «dq _ flag»).
معیارها: کامل بودن/تاخیر/نرخ dup توسط حزب.

8) مدیریت خطاها و استثنائات

DLQ/قرنطینه: سوابق بیمار نگهداری می شود، برای اصلاح در دسترس است.
سوابق استثنا: کارت محرومیت (مالک، تاریخ، دلیل، منطقه).
بازگشت خودکار: از آخرین عکس فوری صحیح از مورد صفحه نمایش استفاده کنید.
بسته شدن SLA: بحرانی - ≤ 24-48 ساعت ؛ عمده - ≤ 5 روز کارکنان.

9) هماهنگی با حفظ حریم خصوصی و انطباق

کمینه سازی PII: PII «خام» را در لایه های تحلیلی بررسی نکنید. از اسم مستعار استفاده کن

بررسی های RLS/CLS بر اساس ماسک انجام می شود.
منطقه ای سازی: قوانین «صلاحیت» را در نظر می گیرند (EEA/UK/BR).
نگهداری قانونی: بدون بازنویسی آرشیو به عنوان بخشی از نگهداری.

10) قابلیت مشاهده، SLI/SLO و هشدارها

• تازگی p95 (نقره ای): ≤ 15 دقیقه
• کامل بودن (انواع بحرانی): ≥ 99. 5%.
• اعتبار (طرح): ≥ 99. 9%.
• نرخ تکراری: ≤ 0. 1%.
• حادثه DQ MTTR: ≤ 24-48 ч.

هشدارها: پیجر برای بحرانی، ضد aliasing، پنجره های تعمیر و نگهداری.

11) داشبورد (حداقل مجموعه)

تازگی/کامل بودن نقشه گرما بر اساس دامنه و بازار.
جدول بالا N با نرخ حادثه و با هزینه اصلاحات.
قیف DQ: مصرف → نقره → طلا (از دست دادن/اصلاح).
نقشه خطی برای گزارش های بحرانی (تنظیم کننده/GGR/RG/AML).
نقشه طرح ها و مشتری های «میراث» (نسخه های SDK/schema).

12) فرآیندها و RACI

R (مسئول): مهندسی داده (قوانین در جداول)، صاحبان دامنه (معناشناسی).
A (پاسخگو): رئیس داده/CDO.
C (مشورت): انطباق/قانونی/DPO، معماری، SRE.
من (مطلع): BI/Продукт/Маркетинг/Финансы/Операции.

Rule lifecycle: offer → review → «اجرای تاریک» → inclusion → monitoring → retrospective

13) آشتی و دقت

Checksums/transactions: vault with OLTP/providers (PSP/KYC).
مقایسه دو حلقه: خط لوله مستقل برای اعتبارسنجی انتخابی.
Tolerances آستانه درصد توسط معیارها (به عنوان مثال،. واریانس GGR ≤ 0. 2%).
اقدامات روزانه: گزارش های حسابرسی حسابرسی.

14) هزینه و اولویت بندی

اجرای قوانین بحرانی اغلب (جریان/ساعتی)، جزئی - روزانه.
از fetches و چک های تحقق یافته برای جداول سنگین استفاده کنید.
پیگیری هزینه/پرس و جو و هزینه/GB، اعمال خوشه بندی/نمایه سازی.
تخصیص بودجه برای DQ در زمینه تیم ها (بازپرداخت).

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) حوادث کیفیت: مدیریت و ارتباطات

Ticketing: ایجاد خودکار وظایف با انتخاب و معیارهای پیوست شده.
قالب کام: اطلاع صاحبان محصول/تنظیم کننده زمانی که تحت تاثیر قرار.
پس از مرگ: علت ریشه (رانش طرح، بالادست اشکال، بار)، اقدامات CAPA، کنترل «بازگشت رگرسیون».

17) نقشه راه پیاده سازی

1. کاتالوگ جداول بحرانی (پرداخت، گیم پلی، GGR، انطباق).

2. قوانین YAML برای 10-15 کلید چک + اعتبار CI.

3. داشبورد تازگی/کامل و هشدار برای بحرانی.

4. DLQ/قرنطینه + رفع runbook.

• گسترش قانون (FK/دقت)، شبیه ساز خشک اجرا، شامل A/B.
• ادغام خطوط، ترتیبات استثنا و SLA ها.
• جریان DQ در مصرف برای منابع «پر سر و صدا».

• تولید خودکار مستندات توسط قوانین، معیارهای هزینه.
• «خطوط کنترل» (آشتی مستقل)، هفتگی گذشته نگر.
• SDK های پلت فرم Rule-as-Code، رجیستری چک های دامنه استاندارد.

18) چک لیست پیش فروش

• قراردادها و طرح ها در رجیستری، آزمون سازگاری عبور می کند.
• قوانین YAML منجمد، شدت/تشدید اختصاص داده شده است.
• داشبورد و هشدار فعال هستند ؛ SLO ها تعریف شده و توافق شده اند.
• DLQ/قرنطینه در دسترس است، کتابهای اجرا مستند شده است.
• استثنا/روش های آشتی با قانونی/انطباق توافق.
• اندازه گیری هزینه بازرسی و محدودیت در درخواست های سنگین.

19) اشتباهات مکرر و چگونگی اجتناب از آنها

داده های خام بدون قرارداد: آزمون های اول طرح و مصرف کننده را وارد کنید.
«دستی» چک: ترجمه به DQ-به عنوان کد و CI.
بدون اولویت بندی: کانال های بحرانی/عمده/جزئی و هشدار جداگانه.
DLQ وجود ندارد: چیزی برای کار با خطاها وجود ندارد - قرنطینه را اضافه کنید.
نادیده گرفتن هزینه: نمایش داده شد مشخصات، استفاده از materialization.
بدون پس از مرگ: اشتباهات تکرار می شوند - وارد CAPA و کنترل رگرسیون.

20) خط پایین

سیستم کنترل کیفیت داده ها مجموعه ای از چک های پراکنده نیست، بلکه یک برنامه مدیریت شده است: قراردادها و طرح ها، DQ-as-code، قابلیت مشاهده و SLO، حادثه و نظم و انضباط آشتی. با پیروی از این مقاله، داده های قابل تجدید، قابل اثبات و مقرون به صرفه برای گزارش های نظارتی، راه حل های محصول و آشکارسازهای ریسک در زمان واقعی دریافت خواهید کرد.