მონაცემთა მთლიანობა
1) რა არის მონაცემების მთლიანობა
მონაცემების მთლიანობა თვისებების და კონტროლის ერთობლიობაა, რაც უზრუნველყოფს, რომ მონაცემები არის სწორი, შეთანხმებული და თანმიმდევრული მთელი ცხოვრების ციკლზე: წყაროებიდან და გარდაქმნებიდან ფანჯრებზე, API და ექსპორტზე. მიზანია, რომ იგივე განცხადება მისცეს ერთსა და იმავე პასუხს განმეორებისას, ხოლო ნებისმიერი ცვლილება ტრეკული და გადამოწმებული იყო.
2) მთლიანობის ტიპები და სად ცხოვრობენ ისინი
არსებითი (Entity): უნიკალური პირველადი გასაღებები, დუბლიკატების არარსებობა.
ბმული (Referential): სწორი კავშირები FK; „ჩამოკიდებული“ ბმულების არარსებობა.
დომენი (დომენი): დასაშვები დიაპაზონი და ფორმატები (ტიპი, სიგრძე, ცნობარი).
ბიზნეს წესები: საგნობრივი რეგიონის ინვარიანტები (ბალანსი 0, გაყვანილობის ჯამი = 0 და ა.შ.).
დროებითი: დროებითი ეტიკეტების ერთფეროვნება და კოორდინაცია, სწორი დროის ზონები.
დაშვების პოლიტიკოსები: RLS/CLS არ არღვევს თვალსაჩინო მონაცემების ლოგიკურ კოორდინაციას.
3) მონაცემთა და სქემების კონტრაქტები (ჭეშმარიტების წყარო)
ჩვენ ვადგენთ ოფიციალურ კონტრაქტებს კომპლექტებისა და მოვლენებისთვის; ჩვენ მათ ვიყენებთ შესასვლელში და თითოეული ტრანსფორმაციის შემდეგ.
მაგალითი (YAML, გამარტივებული):yaml dataset: payments primary_key: txn_id foreign_keys:
- fk: user_id -> users.user_id schema:
- {name: txn_id, type: string, unique: true}
- {name: user_id, type: string, not_null: true}
- {name: amount, type: decimal(18,2), min: 0}
- {name: currency, type: string, in: [USD,EUR,TRY,UAH]}
- {name: event_time, type: timestamp, tz: UTC}
dq_rules:
- "duplicates(txn_id)=0"
- "ref_integrity(user_id, users.user_id)=true"
- "sum(amount) >= 0"
evolution:
semver: [MAJOR, MINOR, PATCH]
breaking_changes_require: approval:data-governance
4) გარიგების გარანტიები და იზოლაცია
ACID OLTP- ისთვის: ატომურობა, თანმიმდევრულობა, იზოლაცია, გამძლეობა.
იზოლაციის დონე: Read Committed/Repeatable Read/Serializable - შეარჩიეთ „ბინძური „/უნიკალური/ფანტომური კითხვების რისკის ქვეშ.
OLAP და lakehouse: ცხრილების ატომური კომუნები (გადასინჯვის ჟურნალი), იდემპოტენტური სინკი და schema-evolution თავსებადობის კონტროლით.
KPI ფორმულების კოორდინაცია: სემანტიკური ფენა - ერთი ჭეშმარიტება მოხსენებებისა და API.
5) განაწილებული სისტემები: წესრიგი, გამეორება, იდემპოტენტობა
ღონისძიების რიგი: ჩვენ ვიყენებთ 'event _ time' + 'ingested _ at', watermarks და lateness დაშვებას; დანაყოფები ღონისძიების დროზე დაყრდნობით.
ხელახალი მიწოდება (at-least-once): გლობალური 'ღონისძიება _ id', idempotence keys ცხრილები, upsert/merge მდგრადი გზით.
Out-of-order: ფანჯრების გადაანგარიშება, შეფერხებების სტრატეგია, კომპენსაცია.
Exactly-once მნიშვნელობით: ტრანსპორტი შეიძლება იყოს ast-least-once, მიმღები არის idempotent.
6) მთლიანობის ალბათობა (DQ) თითოეულ ფენაზე
ჩვენ მოიცავს მთლიანობის წესებს CI/CD- ში და rantime payplines- ში:- Freshness/Completeness/Uniqueness/Valid Values/Referential Integrity.
- ანომალიები: დუბლიკატების ადიდება, დროის უფსკრული, განაწილების მკვეთრი ძვრები.
- KPI ფორმულების კონტროლი: გამოთვლების ვერსია და ტესტები შედეგების დამთხვევისთვის (golden sets).
- ექსპორტის კონტროლი: დარღვევებით კომპლექტების გაცემის აკრძალვა (quarantine).
yaml expect_column_values_to_be_unique: {column: txn_id}
expect_column_values_to_not_be_null: {column: user_id}
expect_column_values_to_be_in_set: {column: currency, value_set: [USD,EUR,TRY,UAH]}
7) ფინანსური და ოპერაციული მთლიანობა
ორმაგი ენა (ორმაგი ჩანაწერი): დებიუტი/სესხი ბალანსში; შემაჯამებელი კრიკეტები cut-off- ში.
საბოლოო ინვარიანტები: გადახდების ოდენობა = ჩამოწერის ოდენობა + საკომისიო + კორექტირება.
ოპერაციული ინვარიანტები: SLA/guardrail მეტრიკა არ არღვევს ბიზნეს წესებს (მაგალითად, მანქანის შეკეთება არ ქმნის დუბლიკატებს).
8) Lineage, აუდიტი და რეპროდუქცია
ხაზები: წყაროდან ფანჯარამდე/fich; ტრანსფორმაციების ხილვადობა და მფლობელები.
აუდიტის ბილიკები: ვინ შეცვალა რა, როდის და რატომ; სქემების/ფორმულების/ჯობის ვერსიები.
Snephots/საკონტროლო წერტილები: წარსული მოხსენებების დათვლისა და დადასტურების შესაძლებლობა.
რეპრო: იგივე შეკრების იგივე მოთხოვნა იგივე შედეგია (ვერსიები და ფენები).
9) უსაფრთხოება და კონფიდენციალურობა მთლიანობის დაკარგვის გარეშე
RLS/CLS: სტრიქონის/სვეტების ფილტრები არ უნდა დაირღვეს ინვარიანტები (მაგალითად, ხილული ნიმუში თანხა უნდა ემთხვეოდეს დეკლარაციას).
შენიღბვა/ტოქსიკაცია: დეტერმინისტული სტრატეგიები, რათა შენარჩუნდეს დედების და რეფერენდუმის მთლიანობა.
დაშიფვრა: არხში და „დისკზე“ შეკუმშვის შემდეგ; კლავიშების მართვა და წვდომის აუდიტი.
DSAR/Retention: მოცილება/ანონიმიზაცია არ არღვევს კავშირს (კასკადის პოლიტიკა).
10) თვითგამორკვევა და ავტომატიზაცია
Quarantine: საეჭვო პარტიების/ბრძოლების იზოლაცია; მომხმარებლები - „სუფთა“ ფილიალი.
Replay/Backfill: ფანჯრის რეპლიკა უცვლელი ჟურნალიდან.
Reconcile: ფენებისა და სისტემების შერწყმა (ჭრილობის ჭრილობა) მარტვილები; წყარო - DWH).
Dedup/Compaction/Rebuild: სისტემური პროცედურები ინდექსების/შეკრების შესაკეთებლად.
policy-as-code: „რა ანომალიაა - რა გავლენას ახდენს ბარიერები - ესკალაცია“.
11) მოდელირებისა და შენახვის პრაქტიკა
სტაბილური გასაღებები: სუროგატი PK (UUID/ULID), უცვლელი ბუნებრივი გასაღებები დირექტორიებში.
ნორმალიზაცია - დენორმალიზაცია: წყაროებში FK კომუნიკაციები, დენორმალიზებული ფანჯრები ლოგიკის ვერსიის კონტროლით.
SCD1/SCD2: კონტროლირებადი გაზომვის ისტორია.
დახარისხება/კლასტერიზაცია: აუმჯობესებს RLE/zone-maps და ამარტივებს კრეკერებს.
ჰაში და მაკონტროლებელი თანხები: ფაილების/პარტიების მთლიანობის შემოწმება.
12) მთლიანობა დროსა და ანგარიშში
ფორმულების ვერსიები: 2025 წლის იანვრის ანგარიში უნდა იყოს რეპროდუცირებული X- ის ვერსიის ფორმულით.
Cut-off და „პერიოდის დახურვა“: ფანჯრების გაყინვა და საარქივო ნაჭრები.
დაბალანსების ფაქტები: საწვავის და გადანაწილების მექანიკა ანგარიშის ვერსიით.
რეგლამენტის დოკუმენტაცია: სახელმძღვანელო კორექტირება - მხოლოდ აუდიტით.
13) ინტეგრაცია და API
API ხელშეკრულება: სქემები, ტიპები, სავალდებულო ველები, შეცდომების კოდი; ვერსია (v1/v2).
მისაბმელიანი შესასვლელი: შენიშვნა ცუდი payload's, არ „შეკეთება ჩუმად“.
Idempotent POST: იდემპოტენტურობის გასაღები, რეპლიკა უსაფრთხოა.
ექსპორტი ფაილებში: პარტიების, ჰეშების, ხელმოწერების კოორდინაცია.
14) ანტიპატერები
SELECTE პროდუქტებსა და ვეშაპებში - იშლება MINOR ევოლუციის დროს.
FK „სიტყვებით“: ბმულების რეალური შემოწმების არარსებობა.
მონაცემთა ჩუმად კორექტირება აუდიტის და ანგარიშგების გარეშე.
TZ და დროის ფორმატის შერევა ერთ ნაკრებში.
KPI- ს „სახელურების“ განსაზღვრა ვერსიებისა და ჟურნალების გარეშე.
ერთადერთი დეპოზიტის გასაღები სათადარიგო სტრატეგიების გარეშე.
DSAR- ის წაშლა კავშირების კასკადის შემოწმების გარეშე.
15) გზის განხორციელების რუკა
1. ინვესტიცია და კრიტიკა: კომპლექტების/მოვლენების რუკა, მფლობელები, რისკები, ინვარიანტები.
2. კონტრაქტები და სქემები: ტიპების/შეზღუდვების ფორმირება/FK, CI თავსებადობის შემოწმება.
3. DQ pline: Freshness/Completeness/Uniqueness/RI, quarantine, alertes.
4. გარიგების საფუძველი: atomic-sink, upsert/merge, SCD ისტორია, ფორმულების ვერსია.
5. Lineage და აუდიტი: კატალოგი, ტრეკერი, change-logs, access-logs.
6. რემონტის პოლიტიკოსები: replay/backfill/dedup/reconcile, როგორც კოდი; runbook’и и SLO MTTR-data.
7. უსაფრთხოება/პრივი: RLS/CLS, შენიღბვა, დაშიფვრა, DSAR პროცესები.
8. ანგარიში: cut-off, freeze-srazes, KPI ვერსიების მენეჯმენტი.
16) ჩეკის სია ნაკრების/ფანჯრის გამოსვლამდე
- PK/FK და აფეთქების ღუმელის შეზღუდვები მოცემულია და გადის ტესტებს.
- სქემების/ფორმულების ვერსია ჩართულია; schema-diff მწვანე.
- DQ წესები (სიახლე/სისრულე/უნიკალურობა/დიაპაზონი/RI) მწვანეა.
- Idempotent ჩანაწერები: upsert/merge, idempotent- ის გასაღები (მოვლენებისთვის).
- დრო: 'event _ time' და 'ingested _ at', TZ = UTC; მონაცემთა პოლიტიკა.
- Lineage და აუდიტი ჩანს; ჩართულია quarantine და alertine.
- RLS/CLS/შენიღბვა არ არღვევს ინვარიანტებს და RI.
- DSAR/Retention ტესტირება; cut-off/არქივი მზად არის.
17) მინი შაბლონები
SQL: ბმულის მთლიანობის შემოწმება
sql select count() as orphans from fact_payments f left join dim_users u on f.user_id = u.user_id where u.user_id is null;
-- ожидаем orphans = 0
Quarantine/repair პოლიტიკა (ფსევდო-YAML)
yaml policy: payments_integrity detect:
- rule: duplicates(txn_id) > 0
- rule: ref_integrity(user_id, users.user_id) = false auto_actions:
- quarantine_partition: {date: today}
- trigger_replay: {window: "last_2h"}
escalate_if:
- condition: violations_persist>30m page: "oncall-data"
SCD2 სქემა გაზომვისთვის
sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current
18) შედეგი
მონაცემების მთლიანობა არ არის ერთჯერადი შემოწმება, არამედ გარანტიების საბოლოო სისტემა: ოფიციალური კონტრაქტები და შეზღუდვები, გარიგების და განაწილებული ინვარიანტები, რემონტის შესაბამისობა და ავტომატიზაცია, ხაზის საჭრელი და აუდიტი, კონფიდენციალურობა და უფლებები. როდესაც ეს ელემენტები ერთად მუშაობენ, მონაცემები ხდება გადაწყვეტილების საიმედო საფუძველი, ხოლო ინციდენტები იშვიათი, მოკლე და პროგნოზირებადი.