GH GambleHub

Маалымат сапатын көзөмөлдөө

1) Максаты жана принциптери

Эмне үчүн: ишенимдүү отчеттор (GGR/салыктар), антифрод жана RG-моделдер, комплаенс-разгрузка, буюмдар жана персоналдаштыруу.

Принциптери:
  • Schema-first & Contracts: бардык булактары келишим боюнча маалыматтарды жарыялоого милдеттүү.
  • DQ-код: репозиторийдеги эрежелер, версиялар, тесттер жана ревю.
  • Observability-by-default: метрика/логика/сызык.
  • Privacy-by-design: минималдуу PII, masking жана RLS/CLS.
  • Cost-aware: критикалык эрежелерди артыкчылыктуу, акылдуу үлгүлөрү.

2) Сапатты өлчөө таксономиясы

Completeness (Толук): Милдеттүү талаалардын/саптардын үлүшү.
Validity (Алгылыктуулугу): түрлөрү/диапазондору/маалымдама ылайык.
Uniqueness (Uniqueness): ачкычтарды/окуяларды кайталоо жоктугу.
Consistency (ырааттуулук): референттик бүтүндүк, бизнес-инварианттар.
Accuracy (тактык): "чыныгы" булагы жакындатуу (кыскача салыштыруу).
Timeliness/Freshness (өз убагында): материалдык кечигүү.
Lineage Integrity: келип чыгышын/котормолорун сактоо.

Ар бир домен үчүн аныкталат KPI сапаты жана критикалык (critical/major/minor).

3) Келишимдер жана схемалар (чындыктын булагы)

Маалымат келишимдери: JSON Schema/Euro/OpenAPI/AsyncAPI, реестрине жайгаштырылган.
Туруктуулук: backward ылайыктуу өзгөрүүлөр - nullable кошуу; breaking - жаңы версия + кош жазуу.
trackable: окуялар - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ-сыяктуу-код: артефакттар түзүлүшү

Git эрежелерди пайплайндар менен бирге сактаңыз:

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

Эрежелер: декларативдик YAML/SQL;

Олуттуу: mapping → кооптуу каналдар/эскалация деңгээл;

CI: Линтерс схемалар, шайкештик тесттер, "dry-run "/симулятор.

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, түрлөрү жана enum's.
On-stream текшерүү: dedupe '(event_id, source)', allowed lateness, акча/суммалар.
Чектери: оор каталар → DLQ + алерт; критикалык эмес → тегдөө, бирок сагынам ('dq _ flag' желеги менен).
Метрика: партиялык completeness/lag/dup-rate.

8) Каталар жана өзгөчөлүктөр менен иштөө

DLQ/Quarantine: "оорулуу" жазуулар сакталат, оңдоо үчүн жеткиликтүү.
Exception records: exception card (owner, мөөнөтү, себеби, аянты).
Auto-fallback: акыркы туура snapshot дисплей колдонуу.
SLA жабуу: оор - ≤ 24-48 саат; major - ≤ 5 кул. күн.

9) Купуялык жана комплаенс менен макулдашуу

PII-минималдаштыруу: аналитикалык катмарларда "чийки" PII текшерүү эмес; псевдонимдерди колдонуңуз.
RLS/CLS: текшерүүлөр талааларды жашыруу менен жүргүзүлөт.
Регионалдаштыруу: эрежелер 'jurisdiction' (EEA/UK/BR) эске алат.
Legal Hold: сактоо алкагында архивдерди кайра жазууга тыюу салуу.

10) байкоо, SLI/SLO жана Алерт

Сунушталган SLI/SLO:
  • Freshness p95 (Silver): ≤ 15 мин.
  • Completeness (critical types): ≥ 99. 5%.
  • Validity (schema): ≥ 99. 9%.
  • Duplicate rate: ≤ 0. 1%.
  • DQ incident MTTR: ≤ 24–48 ч.

Алерталар: олуттуулук боюнча багыттоо (critical үчүн pager), тегиздөө (дедуп алерталар), "maintenance windows".

11) Dashboard (минималдуу топтому)

Жылуулук карта Freshness/Completeness домендер жана базарлар боюнча.
Top-N таблицалар incident rate жана тактоо наркы боюнча.
DQ Huni: ingest → silver → алтын (жоготуу/оңдоо).
критикалык отчеттор үчүн Linage карта (жөнгө/GGR/RG/AML).
"Эскирген" схемалардын жана кардарлардын картасы (SDK/схемалардын версиялары).

12) Процесстер жана RACI

R (Responsible): Data Engineering (таблицадагы эрежелер), Domain Owners (семантика).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Архитектура, SRE.
I (Informed): BI/Продукт/Маркетинг/Каржы/Операциялар.

Жашоо айлампасы эрежелери: сунуш → review → "караңгы баштоо" → киргизүү → мониторинг → retrospective.

13) Текшерүү жана тактык (Accuracy)

Контролдук суммалар/бүтүмдөр: OLTP/провайдерлер менен топтому (PSP/KYC).
Эки жолу салыштыруу: тандалма валидация үчүн көз карандысыз түтүк.
Жол берүүлөр: метрика боюнча пайыздык босоголор (мисалы, GGR айырмачылыгы ≤ 0. 2%).
Күнүмдүк актылар: аудит үчүн салыштыруу отчеттору.

14) Наркы жана артыкчылыктуу

Критикалык эрежелер тез-тез баштоо (агым/саат), minor - daily.
Оор таблицалар үчүн үлгүлөрдү жана materialized текшерүүлөрдү колдонуңуз.
cost/query жана cost/GB ээрчип, кластерлөө/индекстөө колдонуу.
командалар (chargeback) боюнча DQ үчүн бюджетти бөлүп.

15) Gold Showroom үчүн үлгүлөр (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) Сапаттуу окуялар: башкаруу жана байланыш

Ticketing: тиркелген үлгүлөрү жана метриктер менен милдеттерди auto түзүү.
Comm шаблондору: продукт ээлерине/жөнгө салуучу органдарга таасир этүү жөнүндө билдирүү.
Post-mortem: тамыр себеби (shema drift, upstream буг, жүк), CAPA иш-аракеттери, "регрессия кайтаруу" контролдоо.

17) Ишке ашыруунун жол картасы

MVP (2-4 жума):

1. Критикалык таблицалардын каталогу (Payments, Gameplay, GGR, Compliance).

2. YAML эрежелери үчүн 10-15 негизги текшерүү + CI-validation.

3. Dashbord Freshness/Completeness жана critical үчүн алерталар.

4. DLQ/Quarantine + runbook түзөтүүлөр.

2-этап (4-8 жума):
  • Кеңейтүү эрежелери (FK/accuracy), симулятор "dry-run", A/B киргизүү.
  • lineage, өзгөчөлүктөр жана SLA боюнча макулдашуулар менен бириктирүү.
  • "ызы-чуу" булактары үчүн ingest боюнча DQ агымы.
Этап 3 (8-12 жума):
  • Эрежелер, нарк метрикасы боюнча документтердин автогенерациясы.
  • "Контролдук контурлар" (independent reconciliation), weekly retrospektives.
  • Rule-as-Code платформа SDK, домен стандарттык текшерүү реестри.

18) Азык-түлүктүн алдындагы чек-тизме

  • Registry келишимдер жана схемалар, шайкештик тесттер өтөт.
  • YAML эрежелери жумшартылган, severity/эскалация дайындалган.
  • Dashbord жана Алерт активдүү; SLO аныкталган жана макулдашылган.
  • DLQ/Quarantine жеткиликтүү, runbooks документтештирилген.
  • Мыйзамдык/макулдашуу менен макулдашылган өзгөчөлүктөр/салыштыруу актыларынын жол-жоболору.
  • Текшерүү наркын өлчөө жана оор суроо-талаптарды чектөө.

19) Көп каталар жана аларды алдын алуу үчүн кантип

келишимдер жок чийки маалыматтар: schema-first жана consumer-tests киргизүү.
"Кол менен" текшерүү: DQ-кодду жана CI которуу.
Эч кандай артыкчылыктуу: critical/major/minor жана alert каналдарын бөлүп.
DLQ жок: каталар менен иштей турган эч нерсе жок - карантинди кошуңуз.
Ignor наркы: профилдик суроо, материалдык пайдалануу.
Пост-мортемалар жок: каталар кайталанат - CAPA жана регрессияны көзөмөлдөөнү киргизиңиз.

20) Жыйынтык

Маалыматтардын сапатын көзөмөлдөө системасы - бул ар түрдүү текшерүүлөрдүн жыйындысы эмес, башкарылуучу программа: келишимдер жана схемалар, DQ-код, байкоо жана SLO, инциденттердин жана салыштыруулардын тартиби. Бул макаладан кийин, сиз жөнгө салуучу отчеттуулук, азык-түлүк чечимдери жана реалдуу убакыт тобокелдик детекторлору үчүн жетиштүү кайталануучу, текшерилүүчү жана үнөмдүү маалыматтарды аласыз.

Contact

Биз менен байланышыңыз

Кандай гана суроо же колдоо керек болбосун — бизге кайрылыңыз.Биз дайым жардам берүүгө даярбыз!

Telegram
@Gamble_GC
Интеграцияны баштоо

Email — милдеттүү. Telegram же WhatsApp — каалооңузга жараша.

Атыңыз милдеттүү эмес
Email милдеттүү эмес
Тема милдеттүү эмес
Билдирүү милдеттүү эмес
Telegram милдеттүү эмес
@
Эгер Telegram көрсөтсөңүз — Emailден тышкары ошол жактан да жооп беребиз.
WhatsApp милдеттүү эмес
Формат: өлкөнүн коду жана номер (мисалы, +996XXXXXXXXX).

Түшүрүү баскычын басуу менен сиз маалыматтарыңыздын иштетилишине макул болосуз.