მონაცემთა ხარისხის კონტროლი

1) დანიშვნა და პრინციპები

რატომ: საიმედო მოხსენებები (GGR/გადასახადები), ანტიფროდული და RG მოდელები, შესაბამისობის გადმოტვირთვის, პროდუქტებისა და პერსონალიზაციის შესახებ.

• Schema-first & Contracts: ყველა წყარო ვალდებულია გამოაქვეყნოს მონაცემები ხელშეკრულების შესახებ.
• DQ-როგორც კოდი: წესები საცავებში, ვერსიებში, ტესტებში და შურისძიებაში.
• Observability-by-default: მეტრიკა/ლოგიკა/ხაზი.
• პირადი დიზაინი: მინიმალური PII, შენიღბვა და RLS/CLS.
• Cost aware: კრიტიკული წესების პრიორიტეტი, ჭკვიანი ნიმუშები.

2) ხარისხის გაზომვების ტაქსონომია

Completeness (სისრულე): სავალდებულო ველების/ხაზების პროპორცია.
Validity (დაშვება): ტიპების/დიაპაზონის/საცნობარო წიგნების შესაბამისობა.
უნიკალურობა: კლავიშების/მოვლენების დუბლიკატების არარსებობა.
Consistence (შესაბამისობა): რეფერენტის მთლიანობა, ბიზნეს ინვარიანტები.
Accuracy (სიზუსტე): „ჭეშმარიტი“ წყაროს მიახლოება (შერწყმა).
Timeluness/Freshness (დროული): მასალის შეფერხება.
Lineage Integrity: ტრანსფორმაციების წარმოშობის/ვერსიების შენარჩუნება.

თითოეული დომენისთვის განისაზღვრება KPI ხარისხი და კრიტიკა (კრიტიკული/მაიორი/მინი).

3) კონტრაქტები და სქემები (ჭეშმარიტების წყარო)

მონაცემთა კონტრაქტები: JSON Schema/Avro/OpenAPI/AsyncAPI, განთავსებულია Registry- ში.
სტაბილურობა: თავსებადი ცვლილებები - არალეგალური დამატება; breaking - ახალი ვერსია + ორმაგი ჩანაწერი.
ტრეკირება: მოვლენებში - 'event _ id', 'trace _ id', 'schema _ version', 'source'.

4) DQ კოდი: არტეფაქტების სტრუქტურა

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

წესები: დეკლარაციული YAML/SQL;

სერიოზულობა: კაპიტალური არხები/ესკალაციის დონე;

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 'y.
On-stream შემოწმება: dedup '(event _ id, წყარო)', allowed lateness, ვალუტის/თანხების მიზანშეწონილობა.
საზღვრები: კრიტიკული შეცდომები DLQ + Alert; არა კრიტიკული, მაგრამ გამოტოვება (დროშით 'dq _ flag').
მეტრიკა: შეკრება/lag/dup-rate მხარეებისთვის.

8) შეცდომებთან და გამონაკლისებთან მუშაობა

DLQ/Quarantine: „ავადმყოფი“ ჩანაწერები ინახება, გამოსწორებულია.
ექსკლუზიური ჩანაწერები: გამონაკლისი ბარათი (owner, ვადა, მიზეზი, რეგიონი).
Auto-fallback: ფანჯრის ბოლო სწორი სარტყლის გამოყენება.
SLA დახურვა: კრიტიკული - 24-48 საათი; მაიორი - 5 მონა. დღეები.

9) კოორდინაცია კონფიდენციალურობასთან და შესაბამისობასთან

PII მინიმიზაცია: არ შეამოწმოთ „ნედლეული“ PII ანალიტიკურ ფენებში; გამოიყენეთ ფსევდონიმები.
RLS/CLS: შემოწმებები ხორციელდება მინდვრის შენიღბვის გათვალისწინებით.
რეგიონალიზაცია: წესები ითვალისწინებს 'jurisdiction' (EEA/UK/BR).
Legal Hold: არქივების გადაწერის აკრძალვა, როგორც შენარჩუნების ნაწილი.

10) დაკვირვება, SLI/SLO და ალერტები

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

ალერტები: მარშრუტიზაცია სერიოზულად (pager critical), გაბრტყელება (ალერტების დედობა), „windows maintenance“.

11) დაშბორდი (მინიმალური ნაკრები)

Freshness/Completeness თერმული რუკა დომენებისა და ბაზრებისთვის.
ტოპ N ცხრილები ინკლუზიური ნიშნით და კორექტირების ღირებულებით.
ძაბრი DQ: ingest - silver - gold (ზარალი/კორექტირება).
ხაზის რუკა კრიტიკული მოხსენებისთვის (მარეგულირებელი/GGR/RG/AML).
„მოძველებული“ სქემებისა და მომხმარებლების რუკა (SDK/სქემების ვერსიები).

12) პროცესები და RACI

R (Responsible): მონაცემთა ინჟინერია (ცხრილების წესები), დომენის ომნერები (სემანტიკა).
A (Accountable): Head of Data/CDO.
C (Consulted): კომპლექსი/ლეგალური/DPO, არქიტექტურა, SRE.
I (ინფორმირებული): BI/პროდუქტი/მარკეტინგი/ფინანსები/ოპერაციები.

წესების სასიცოცხლო ციკლი: რევიზიის შეთავაზება არის „ბნელი გაშვება“, რეტროსპექტივის ჩართვა და მონიტორინგი.

13) კრეკერები და სიზუსტე (Accuracy)

მაკონტროლებელი თანხები/გარიგებები: კოდექსი OLTP/პროვაიდერებთან (PSP/KYC).
ორმაგი წრიული შედარებები: დამოუკიდებელი მილის შერჩევა.
მისცეს: პროცენტული ბარიერები მეტრიკებზე (მაგალითად, GGR შეუსაბამობა - 0. 2%).
ყოველდღიური აქტები: აუდიტის შედუღების მოხსენებები.

14) ღირებულება და პრიორიტეტი

უფრო ხშირად დაიწყეთ კრიტიკული წესები (streaming/საათები), minor - daily.
გამოიყენეთ ნიმუშები და materialized checks მძიმე ცხრილებისთვის.
თვალყური ადევნეთ cost/query და cost/GB, გამოიყენეთ კლასტერიზაცია/ინდექსაცია.
გამოყავით ბიუჯეტი DQ- სთვის გუნდების ჭრილში.

15) შაბლონები ოქროს ფანჯრისთვის (მაგალითი 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 შაბლონები: პროდუქტის მფლობელების/მარეგულირებლების შეტყობინება გავლენის დროს.
პოსტ-mortem: ფესვის მიზეზი (schema drift, upstream bug, დატვირთვა), CAPA- ს მოქმედებები, კონტროლი „რეგრესიების დაბრუნებაზე“.

17) საგზაო რუკა

1. კრიტიკული ცხრილების კატალოგი (Payments, Gameplay, GGR, Compliance).

2. YAML წესები 10-15 ძირითადი შემოწმებისთვის + CI სავალდებულო.

3. დაშბორდ ფრეშნესი/კომპლექსი და ალერტები კრიტიკულისთვის.

4. DLQ/Quarantine + runbook კორექტირება.

• წესების გაფართოება (FK/accuracy), სიმულატორი „dry-run“, A/B ჩანართები.
• ინტეგრაცია ხაზთან, გამონაკლისის ხელშეკრულებები და SLA.
• ნაკადი DQ ingest- ზე „ხმაურიანი“ წყაროებისთვის.

• დოკუმენტაციის ავტომატური წარმოება წესების შესაბამისად, ღირებულების მეტრიკა.
• „საკონტროლო კონტურები“, ყოველკვირეული რეტროსპექტივები.
• Rule-as-Code პლატფორმის SDK, სტანდარტული დომენის შემოწმების რეესტრი.

18) ჩეკის სია გაყიდვამდე

• კონტრაქტები და სქემები რეგისტერში, თავსებადობის ტესტები გადის.
• YAML წესები არის sneakering, დაგეგმილია severity/ესკალაცია.
• დაშბორდი და ალერტები აქტიურია; SLO განისაზღვრება და შეთანხმებულია.
• DLQ/Quarantine ხელმისაწვდომია, runbooks დოკუმენტირებულია.
• შერწყმის გამონაკლისის/აქტების პროცედურები შეთანხმებულია Legal/Compliance- სთან.
• მძიმე მოთხოვნების შემოწმებისა და შეზღუდვების ღირებულების გაზომვები.

19) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ნედლეული მონაცემები კონტრაქტების გარეშე: შემოიღეთ schema-first და consumer-tests.
შემოწმებები „ხელით“: გადაიტანეთ DQ კოდი და CI.
პრიორიტეტი არ არის: გაიზიარეთ კრიტიკული/მაიორი/მინორი და ალერტის არხები.
არ არსებობს DLQ: შეცდომებთან მუშაობის არაფერი აქვს - დაამატეთ კარანტინი.
ფასის უგულებელყოფა: პროფილის მოთხოვნები, გამოიყენეთ მატერიალიზაცია.
არ არსებობს პოსტ-mortems: შეცდომები მეორდება - შემოიტანეთ CAPA და რეგრესიების კონტროლი.

20) შედეგი

მონაცემთა ხარისხის კონტროლის სისტემა არ არის განსხვავებული შემოწმებების ერთობლიობა, არამედ კონტროლირებადი პროგრამა: კონტრაქტები და სქემები, DQ კოდი, დაკვირვება და SLO, ინციდენტების დისციპლინა და შედუღება. ამ სტატიის შემდეგ, თქვენ მიიღებთ რეპროდუქციულ, შემოწმებულ და ეკონომიურ მონაცემებს, რომლებიც საკმარისია მარეგულირებელი ანგარიშგების, სასურსათო გადაწყვეტილებებისა და რეალური ტიპის რისკის დეტექტორებისთვის.