GH GambleHub

Деректер сапасын бақылау

1) Мақсаты және қағидаттары

Не үшін: сенімді есептер (GGR/салықтар), антифрод және RG-модельдер, комплаенс-түсіру, өнімдер және дербестендіру.

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

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

Completeness (Толықтығы): міндетті өрістердің/жолдардың үлесі.
Validity (жарамдылық): түріне/ауқымына/анықтамалығына сәйкестігі.
Uniqueness (бірегейлігі): кілттердің/оқиғалардың көшірмелерінің болмауы.
Consistency (Келісім): референттік тұтастық, бизнес-инварианттар.
Accuracy (Дәлдік): «шынайы» дереккөзге жақындату (жиынтық салыстырулар).
Timeliness/Freshness (Уақтылығы): материалды кешіктіру.
Lineage Integrity: шығу тегін/трансформация нұсқаларын сақтау.

Әрбір домен үшін KPI сапасы мен сындылығы (critical/major/minor) анықталады.

3) Келісімшарттар мен схемалар (ақиқат көзі)

Деректер келісімшарттары: JSON Schema/Euro/OpenAPI/AsyncAPI, Registry орналастырылған.
Тұрақтылық: backward-үйлесімді өзгерістер - nullable қосу; breaking - жаңа нұсқа + қос жазба.
Трассалануы: оқиғаларда - '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 ағыны (real-time)

Ingest-валидация: schema validation, size-limits, типтері мен enum's.
On-stream тексеру: дедуп '(event_id, source)', allowed lateness, валюталардың/сомалардың валидтілігі.
Шектері: қателіктер → DLQ + қателіктер; сыни емес → тегтеу, бірақ өткізіп жіберу ('dq _ flag' жалаушасымен).
Өлшемдері: партиялар бойынша completeness/lag/dup-rate.

8) Қателермен және ерекшеліктермен жұмыс істеу

DLQ/Quarantine: «ауру» жазбалар ұсталады, түзету үшін қол жетімді.
Exception records: алып тастау карточкасы (owner, мерзімі, себебі, аумағы).
Auto-fallback: витринаның соңғы дұрыс снапшотын пайдалану.
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) Дашбордтар (ең аз жиынтық)

Домендер мен нарықтар бойынша Freshness/Completeness жылу картасы.
incident rate бойынша және түзетулердің құны бойынша топ-N кестелер.
DQ құйғышы: ingest → silver → gold (жоғалту/түзету).
Сындарлы есептерге арналған линдж картасы (реттегіш/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/Өнім/Маркетинг/Қаржы/Операциялар.

Ереженің өмірлік циклі: ұсыныс → ревью → «қараңғы іске қосу» → қосу → мониторинг → ретроспектива.

13) Салыстыру және дәлдік (Accuracy)

Бақылау сомалары/транзакциялары: OLTP/провайдерлермен жиынтық (PSP/KYC).
Екі контурлы салыстыру: іріктемелі валидация үшін тәуелсіз pipeline.
Шектер: метриктер бойынша пайыздық шектер (мысалы, GGR айырмашылығы ≤ 0. 2%).
Күнделікті актілер: аудит үшін салыстыру есептері.

14) Құны және басымдылығы

Сыни ережелерді жиі іске қосыңыз (ағындық/сағаттық), minor - daily.
Ауыр кестелер үшін іріктемелер мен materialized checks пайдаланыңыз.
cost/query және cost/GB бағдарламаларын қадағалап, кластерлеуді/индекстеуді қолданыңыз.
DQ үшін бюджетті командалар (chargeback) бойынша бөліңіз.

15) Gold-витриналарға арналған үлгілер (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: таңдаулары мен өлшемдері бар тапсырмаларды автоматты түрде жасау.
Comm-шаблондар: өнім/реттегіш иелеріне әсер ету кезінде хабарлау.
Пост-мортем: түбірлік себеп (schema drift, upstream bug, жүктеме), CAPA әрекеттері, «регрессияны қайтаруды» бақылау.

17) Енгізу жол картасы

MVP (2-4 апта):

1. Сыни кестелер каталогы (Payments, Gameplay, GGR, Compliance).

2. 10-15 негізгі тексерулер + CI валидациясы үшін YAML ережелері.

3. Дашборд 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 ретроспективалары.
  • Rule-as-Code платформалық SDK, доменді стандартты тексеру тізілімі.

18) Азық-түлік алдындағы чек-парағы

  • Registry-дегі келісімшарттар мен схемалар, үйлесімділік тестілері өтеді.
  • YAML ережелері қарайған, severity/эскалация тағайындалған.
  • Дашбордтар мен алерттер белсенді; SLO анықталған және келісілген.
  • DLQ/Quarantine қол жетімді, runbooks құжатталған.
  • Алып тастау/салыстыру актілерінің рәсімдері Legal/Compliance компаниясымен келісілген.
  • Тексерулердің құнын өлшеу және ауыр сұрау салуларға арналған лимиттер.

19) Жиі қателер және оларды болдырмау

Келісім-шарттарсыз шикі деректер: schema-first және consumer-tests енгізіңіз.
«Қолмен» тексеру: DQ-ретінде-кодқа және CI-ге аударыңыз.
Басымдығы жоқ: critical/major/minor және алерт арналарын бөліңіз.
DLQ жоқ: қателермен жұмыс істеуге ештеңе жоқ - карантин қосыңыз.
Құн игноры: сұрауларды бейіндеңіз, материалдандыруды пайдаланыңыз.
Пост-мортемалар жоқ: қателер қайталанады - CAPA енгізіңіз және регрессияны бақылаңыз.

20) Қорытынды

Деректер сапасын бақылау жүйесі - бұл бытыраңқы тексерулер жиынтығы емес, басқарылатын бағдарлама: келісімшарттар мен схемалар, DQ-код, бақылау және SLO, инциденттер мен салыстыру тәртібі. Осы бапқа сүйене отырып, сіз реттеуші есептілік, азық-түлік шешімдері және real-time тәуекел детекторлары үшін жеткілікті қайталанатын, тексерілетін және үнемді деректерді аласыз.

Contact

Бізбен байланысыңыз

Кез келген сұрақ немесе қолдау қажет болса, бізге жазыңыз.Біз әрдайым көмектесуге дайынбыз!

Telegram
@Gamble_GC
Интеграцияны бастау

Email — міндетті. Telegram немесе WhatsApp — қосымша.

Сіздің атыңыз міндетті емес
Email міндетті емес
Тақырып міндетті емес
Хабарлама міндетті емес
Telegram міндетті емес
@
Егер Telegram-ды көрсетсеңіз — Email-ге қоса, сол жерге де жауап береміз.
WhatsApp міндетті емес
Пішім: +ел коды және номер (мысалы, +7XXXXXXXXXX).

Батырманы басу арқылы деректерді өңдеуге келісім бересіз.