GH GambleHub

Məlumatların keyfiyyətinə nəzarət

1) Təyinat və prinsiplər

Niyə: etibarlı hesabatlar (GGR/vergilər), antifrod və RG modelləri, komplayens boşaltma, məhsullar və personallaşdırma.

Prinsiplər:
  • Schema-first & Contracts: bütün mənbələr müqavilə məlumatlarını dərc etməlidir.
  • DQ-kimi kod: anbarda qaydalar, versiyalar, testlər və review.
  • Observability-by-default: metrika/loging/linedge.
  • Privacy-by-design: minimum PII, maskalama və RLS/CLS.
  • Cost-aware: kritik qaydaların prioritetləşdirilməsi, ağıllı nümunələr.

2) Keyfiyyət ölçmələrinin taksonomiyası

Completeness (Dolğunluq): Məcburi sahələrin/sətirlərin payı.
Validity (Tolerantlıq): tip/diapazon/referans uyğunluğu.
Uniqueness (Uniqueness): açarların/hadisələrin təkrarlanmaması.
Consistency (Uyğunluq): istinad bütövlüyü, biznes invariantları.
Accuracy (Dəqiqlik): «əsl» mənbəyə yaxınlaşma (birləşdirilmiş yoxlamalar).
Timeliness/Freshness (vaxtında): materialın gecikməsi.
Lineage Integrity: Menşe/transformasiya versiyalarının qorunması.

Hər bir domen üçün KPI keyfiyyəti və kritikliyi (critical/major/minor) müəyyən edilir.

3) Müqavilələr və sxemlər (həqiqət mənbəyi)

Məlumat müqavilələri: JSON Schema/Avro/OpenAPI/AsyncAPI, Registry-də yerləşdirilib.
Sabitlik: backward uyğun dəyişikliklər - nullable əlavə; breaking - yeni versiya + ikiqat qeyd.
İzlənilebilirlik: hadisələrdə - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-kimi-kod: artefaktların strukturu

Qaydaları paylayıcılarla birlikdə Git-də saxlayın:

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

Qaydalar: deklarativ YAML/SQL;

Ciddilik: mapping → alert kanalları/eskalasiya səviyyələri;

CI: sxem linterləri, uyğunluq testləri, «dry-run «/simulyator.

5) Qayda nümunələri (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 testləri (nümunələr)

Açarların unikallığı

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

Məcburi sahələrin tamlığı

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

Referanslar/tutarlılıq

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 axını (real vaxt)

Ingest-validation: schema validation, size-limits, növləri və enum 's.
On-stream check: dedup '(event_id, source)', allowed lateness, valyuta/məbləğlərin etibarlılığı.
Sərhədlər: kritik səhvlər → DLQ + alert; kritik deyil → etiketləmə, lakin qaçırmaq ('dq _ flag' bayrağı ilə).
Metriklər: partisitlər üzrə completeness/lag/dup-rate.

8) Səhvlər və istisnalarla işləmək

DLQ/Quarantine: «xəstə» qeydlər saxlanılır, düzəltmək üçün mövcuddur.
Exception records: istisna kartı (owner, son tarix, səbəb, sahə).
Auto-fallback: vitrin son düzgün snapshot istifadə.
SLA bağlama: kritik - ≤ 24-48 saat; major - ≤ 5 qul. gün.

9) Gizlilik və komplayenslə uyğunlaşma

PII-minimallaşdırma: analitik təbəqələrdə «xam» PII yoxlamayın; təxəllüsləri tətbiq edin.
RLS/CLS: yoxlamalar sahələrin maskalanmasını nəzərə alaraq həyata keçirilir.
Regionlaşdırma: qaydalar «jurisdiction» (EEA/UK/BR) nəzərə alınır.
Legal Hold: saxlama çərçivəsində arxivlərin yenidən yazılmasına qadağa.

10) Müşahidə, SLI/SLO və alertlər

Tövsiyə olunan SLI/SLO:
  • Freshness p95 (Gümüş): ≤ 15 dəq.
  • Completeness (critical types): ≥ 99. 5%.
  • Validity (schema): ≥ 99. 9%.
  • Duplicate rate: ≤ 0. 1%.
  • DQ incident MTTR: ≤ 24–48 ч.

Alertlər: ciddiliyə görə marşrutlaşdırma (critical üçün pager), yumşaltma (dedup alerts), «maintenance windows».

11) Daşbordlar (minimum dəsti)

Domenlər və bazarlarda Freshness/Completeness istilik kartı.
incident rate və qiymət düzəlişləri ilə Top-N cədvəllər.
DQ hunisi: ingest → silver → gold (itkilər/düzəlişlər).
Kritik hesabatlar üçün linj kartı (tənzimləyici/GGR/RG/AML).
«Köhnəlmiş» sxemlərin və müştərilərin xəritəsi (SDK/sxemlərin versiyaları).

12) Proseslər və RACI

R (Responsible): Data Engineering (cədvəllərdə qaydalar), Domain Owners (semantika).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Memarlıq, SRE.
I (Informed): BI/Məhsul/Marketinq/Maliyyə/Əməliyyatlar.

Həyat dövrü qaydaları: təklif → review → «qaranlıq başlanğıc» → daxil → monitorinq → retrospektiv.

13) Yoxlama və dəqiqlik (Accuracy)

Nəzarət məbləğləri/əməliyyatlar: ALTP/provayderlər (PSP/KYC) ilə yığma.
İki dövrəli müqayisə: seçici validasiya üçün müstəqil pipeline.
Tolerantlar: metrik faiz həddi (məsələn, GGR uyğunsuzluğu ≤ 0. 2%).
Gündəlik aktlar: audit üçün yoxlama hesabatları.

14) Qiymət və prioritetləşdirmə

Kritik qaydaları daha tez-tez işə salın (axın/saat), minor - daily.
Ağır cədvəllər üçün nümunələr və materialized yoxlamalar istifadə edin.
cost/query və cost/GB izləyin, klasterləşdirmə/indeksləşdirmə tətbiq edin.
DQ üçün büdcəni komandalar (chargeback) baxımından ayırın.

15) Gold vitrin şablonları (GGR Daily nümunəsi)

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) Keyfiyyət hadisələri: idarəetmə və kommunikasiya

Ticketing: Əlavə nümunələr və metriklər ilə problemlərin avtomatik yaradılması.
Comm şablonları: məhsul sahiblərinə/tənzimləyiciyə təsir göstərdikdə bildiriş.
Post-mortem: kök səbəbi (schema drift, upstream bug, yük), CAPA hərəkətləri, «reqressiya qaytarılması» nəzarəti.

17) Tətbiqi yol xəritəsi

MVP (2-4 həftə):

1. Kritik cədvəllər kataloqu (Payments, Gameplay, GGR, Compliance).

2. 10-15 əsas yoxlamalar + CI-validasiya üçün YAML qaydaları.

3. Dashbord Freshness/Completeness və critical üçün alerts.

4. DLQ/Quarantine + runbook düzəlişlər.

Faza 2 (4-8 həftə):
  • Genişlənmə qaydaları (FK/accuracy), «dry-run» simulyatoru, A/B daxil.
  • Lineage, istisnalar və SLA ilə inteqrasiya.
  • «Səs-küylü» mənbələr üçün ingest axını DQ.
Faza 3 (8-12 həftə):
  • Qaydalar, dəyər metrikası üzrə sənədlərin avtogenerasiyası.
  • «Nəzarət konturları» (independent reconciliation), həftəlik retrospektivlər.
  • Rule-as-Code platforma SDK, domen standart yoxlamalar reyestri.

18) Satış öncəsi yoxlama siyahısı

  • Registry müqavilələr və sxemlər, uyğunluq testləri keçir.
  • YAML qaydaları yağlı, severity/eskalasiya təyin.
  • Daşbordlar və alertlər aktivdir; SLO müəyyən və razılaşdırılmışdır.
  • DLQ/Quarantine mövcuddur, runbooks sənədləşdirilmişdir.
  • İstisnalar/uyğunlaşma aktları prosedurları Legal/Compliance ilə razılaşdırılmışdır.
  • Yoxlamaların dəyərinin ölçülməsi və ağır sorğuların limitləri.

19) Tez-tez səhvlər və onlardan necə qaçmaq olar

Müqaviləsiz xam məlumatlar: schema-first və consumer-tests daxil edin.
«Əl» yoxlamaları: DQ-kimi-kod və CI-yə tərcümə edin.
Heç bir prioritet: critical/major/minor və alert kanallarını bölün.
DLQ yoxdur: səhvlərlə işləmək üçün heç bir şey yoxdur - karantin əlavə edin.
İqnor dəyəri: sorğuları profilləşdirin, materiallaşdırmadan istifadə edin.
Post-mortemlər yoxdur: səhvlər təkrarlanır - CAPA və reqressiya nəzarətini daxil edin.

20) Yekun

Məlumatların keyfiyyətinə nəzarət sistemi ayrı-ayrı yoxlamaların dəsti deyil, idarə olunan proqramdır: müqavilələr və sxemlər, DQ-kimi-kod, müşahidə və SLO, insidentlərin və yoxlamaların intizamı. Bu məqalədən sonra, tənzimləyici hesabat, ərzaq həlləri və real vaxt risk detektorları üçün kifayət qədər təkrar edilə bilən, yoxlanıla bilən və qənaətli məlumatlar əldə edəcəksiniz.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.