Maʼlumotlar sifatini nazorat qilish

1) Vazifasi va prinsiplari

Nima uchun: ishonchli hisobotlar (GGR/soliqlar), antifrod va RG-modellar, komplayens-tushirishlar, mahsulotlar va personallashtirish.

• Schema-first & Contracts: barcha manbalar shartnoma ma’lumotlarini e’lon qilishi shart.
• DQ-kod sifatida: repozitoriyadagi qoidalar, versiyalar, testlar va revyu.
• Observability-by-default: metrika/logirovka/linedj.
• Privacy-by-design: minimal PII, kamuflyaj va RLS/CLS.
• Cost-aware: tanqidiy qoidalarni ustuvorlashtirish, aqlli tanlov.

2) Sifat o’lchovlarining taksonomiyasi

Completeness (Toʻliqlik): Majburiy maydonlarning/satrlarning ulushi.
Validity (maqbullik): turlar/diapazonlar/maʼlumotnomalarga muvofiqlik.
Uniqueness (Uniqueness): kalitlar/hodisalarning dublikatlari mavjud emas.
Consistency (Muvofiqlik): referent yaxlitlik, biznes invariantlar.
Accuracy (aniqlik): «haqiqiy» manbaga yaqinlashish.
Timeliness/Freshness (O’z vaqtida): materialning kechikishi.
Lineage Integrity: kelib chiqish/transformatsiya versiyalarini saqlash.

Har bir domen uchun sifat va kritiklik KPI (critical/major/minor) aniqlanadi.

3) Kontraktlar va sxemalar (haqiqat manbai)

Ma’lumotlar kontraktlari: JSON Schema/Avro/OpenAPI/AsyncAPI, Registry’da joylashtirilgan.
Barqarorlik: backward mos keladigan oʻzgarishlar - nullable qoʻshish; breaking - yangi versiya + qoʻshaloq yozuv.
Izlanuvchanlik: hodisalarda -’event _ id’,’trace _ id’,’schema _ version’,’source’.

4) DQ-kod sifatida: artefaktlarning tuzilishi

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

Qoidalar: deklarativ YAML/SQL;

Jiddiyligi: mapping → alert kanallari/eskalatsiya darajasi;

CI: sxemalar linterlari, muvofiqlik testlari, «dry-run «/simulyator.

5) Qoidalar namunalari (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-testlar (namunalar)

Kalitlarning oʻziga xosligi

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

Majburiy maydonlarning to’liqligi

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

Ma’lumotnomalar/konsistentlik

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

7) Oqimli DQ (real-time)

Ingest-validatsiya: schema validation, size-limits, tiplar va enum’lar.
On-stream tekshirish: dedup’(event_id, source)’, allowed lateness, valyutalar/summalar validligi.
Chegaralar: tanqidiy xatolar → DLQ + alert; tanqidiy emas → teglash, lekin oʻtkazib yuborish (’dq _ flag’bayrogʻi bilan).
Metriklar: partitsiyalar bo’yicha completeness/lag/dup-rate.

8) Xatolar va istisnolar bilan ishlash

DLQ/Quarantine: «bemor» yozuvlar ushlab turiladi, ularni tuzatish mumkin.
Exception records: istisno kartasi (owner, muddati, sababi, hududi).
Auto-fallback: vitrinaning oxirgi toʻgʻri snapshotidan foydalanish.

SLA yopilishi: tanqidiy - 24-48 soat ≤; major - ≤ 5 qul. kun

9) Maxfiylik va komplayens bilan kelishish

PII-minimallashtirish: tahliliy qatlamlarda «xom» PIIlarni tekshirmang; taxalluslarni ishlating.
RLS/CLS: tekshirish maydonlarni yashirishni hisobga olgan holda amalga oshiriladi.
Hududlashtirish: qoidalar’jurisdiction’(EEA/UK/BR) ni hisobga oladi.
Legal Hold: ushlab qolish uchun arxivni qayta yozishni taqiqlash.

10) Kuzatish darajasi, SLI/SLO va alertlar

• Freshness p95 (Silver): ≤ 15 daqiqa.
• Completeness (critical types): ≥ 99. 5%.
• Validity (schema): ≥ 99. 9%.
• Duplicate rate: ≤ 0. 1%.
• DQ incident MTTR: ≤ 24–48 ч.

Alertlar: jiddiylik yo’nalishi (pager for critical), tekislash (dedup alertlar), «maintenance windows».

11) Dashbordlar (minimal to’plam)

Domenlar va bozorlar bo’yicha Freshness/Completeness issiqlik xaritasi.
incident rate bo’yicha va tuzatishlar qiymati bo’yicha top-N jadvallar.
DQ hunisi: ingest → silver → gold (yo’qotishlar/tuzatishlar).
Tanqidiy hisobotlar uchun linedj xaritasi (regulyator/GGR/RG/AML).
«Eskirgan» sxemalar va mijozlar xaritasi (SDK/sxemalar versiyasi).

12) Jarayonlar va RACI

R (Responsible): Data Engineering (jadvaldagi qoidalar), Domain Owners (semantika).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Arxitektura, SRE.
I (Informed): BI/Mahsulot/Marketing/Moliya/Operatsiyalar.

Qoidaning hayot sikli: taklif → revyu → «qorong’u start» → yoqish → monitoring → retrospektiv.

13) Solishtirish va aniqlik (Accuracy)

Nazorat summalari/tranzaksiyalari: OLTP/provayderlar (PSP/KYC) bilan jamlanma.
Ikki konturli taqqoslash: tanlangan validatsiya uchun mustaqil pipeline.
Cheklovlar: metriklar bo’yicha foiz chegaralari (masalan, GGR farqlari ≤ 0. 2%).
Kundalik dalolatnomalar: audit uchun solishtirma hisobotlar.

14) Qiymat va ustuvorlik

Tanqidiy qoidalarni tez - tez ishga tushiring, minor - daily.
Og’ir jadvallar uchun namunalar va materialized checks’dan foydalaning.
Cost/query va cost/GB dasturlarini kuzatib boring.
Buyruqlar kesimida DQ uchun byudjet ajrating (chargeback).

15) Gold-vitrin uchun namunalar (GGR Daily misoli)

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) Sifat hodisalari: boshqaruv va kommunikatsiya

Ticketing: oʻrnatilgan namunalar va metriklar bilan avtomatik vazifalar yaratish.
Komm-shablonlar: mahsulot/regulyator egalarini ta’sirida xabardor qilish.
Post-mortem: ildiz sababi (schema drift, upstream bug, yuk), CAPA harakatlari, «regressiyalarni qaytarish» nazorati.

17) Joriy etish yo’l xaritasi

1. Tanqidiy jadvallar katalogi (Payments, Gameplay, GGR, Compliance).

2. 10-15 ta asosiy tekshirishlar uchun YAML qoidalari + CI-validatsiya.

3. Dashbord Freshness/Completeness va critical uchun alertlar.

4. DLQ/Quarantine + runbook tuzatishlar.

• Qoidalarni kengaytirish (FK/accuracy), «dry-run» simulyatori, A/B qoʻshimchalari.
• Lineage, istisnolar bo’yicha kelishuvlar va SLA bilan integratsiya.
• «Shovqinli» manbalar uchun ingest uchun DQ oqimi.

• Hujjatlarni qoidalar, qiymat metrikasi bo’yicha avtogeneratsiya qilish.
• «Nazorat konturlari» (independent reconciliation), weekly retrospektivlar.
• Rule-as-Code platforma SDK, domenni standart tekshirishlar reyestri.

18) Sotishdan oldingi chek-varaq

• Registridagi kontraktlar va sxemalar, muvofiqlik testlari o’tkaziladi.
• YAML qoidalari buzilgan, severity/eskalatsiyalar tayinlangan.
• Dashbordlar va alertlar faol; SLO aniqlangan va kelishilgan.
• DLQ/Quarantine mavjud, runbooks hujjatlashtirilgan.
• Istisnolar/solishtirma dalolatnomalar tartib-taomillari Legal/Compliance bilan kelishilgan.
• Tekshirishlar qiymatini o’lchash va og’ir so’rovlar uchun limitlar.

19) Tez - tez xatolar va ulardan qanday qochish mumkin

Shartnomasiz xom ma’lumotlar: schema-first va consumer-tests.
«Qo’lda» tekshirish: DQ-kod va CI’ga o’tkazing.
Hech qanday ustuvorlik yoʻq: critical/major/minor va alert kanallarini ajrating.
DLQ mavjud emas: xatolar bilan ishlash uchun hech narsa yo’q - karantin qo’shing.
Qiymat ignori: so’rovlarni profillang, materiallashtirishdan foydalaning.
Post-mortemlar yo’q: xatolar takrorlanadi - CAPA va regressiya nazoratini kiriting.

20) Jami

Ma’lumotlar sifatini nazorat qilish tizimi - bu turli xil tekshiruvlar to’plami emas, balki boshqariladigan dastur: kontraktlar va sxemalar, DQ-kod, kuzatuv va SLO, hodisalar va solishtirmalar tartibi. Ushbu maqolaga amal qilib, siz tartibga solish hisoboti, oziq-ovqat yechimlari va real-time xavf detektorlari uchun yetarli bo’lgan takrorlanadigan, tekshiriladigan va tejamkor ma’lumotlarni olasiz.