Деректер сапасын бақылау
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 ағыны.
- Құн метрикасының ережелері бойынша құжаттаманың автогенерациясы.
- «Бақылау контурлары» (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 тәуекел детекторлары үшін жеткілікті қайталанатын, тексерілетін және үнемді деректерді аласыз.