Integritatea datelor

1) Ce este integritatea datelor

Integritatea datelor este un set de proprietăți și controale pentru a se asigura că datele sunt corecte, coerente și coerente pe tot parcursul ciclului său de viață, de la surse și transformări la storefronturi, API-uri și exporturi. Scopul este că aceeași afirmație dă același răspuns atunci când se repetă, iar orice modificări sunt urmăribile și verificabile.

2) Tipuri de integritate și unde trăiesc

Chei primare unice, fără duplicate.
Referenţial-Valid FK link-uri absenţa „agăţat” link-uri.
Domenii-Valid intervale și formate (tip, lungime, directoare).
Reguli de afaceri: invarianții domeniului subiect (soldul ≥ 0, suma tranzacției = 0 etc.).
Temporar: monotonia și consistența marcajului temporal, zonele de timp corecte.
Politici de acces: RLS/CLS nu încalcă consistența logică a datelor vizibile.

3) Contracte de date și scheme (sursa adevărului)

Stabilim contracte formale pentru seturi și evenimente; le aplicăm la intrare și după fiecare transformare.

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) Garanții tranzacționale și izolare

ACID pentru OLTP: atomicitate, consistență, izolare, durabilitate.
Niveluri de izolare: Read Committed/Repetable Read/Serializable - alege la risc de „murdar „/unic/fantomă citește.
OLAP și lakehouse: angajamente atomice de tabele (jurnal de tranzacții), chiuvetă idempotentă și schemă-evoluție cu control al compatibilității.
Consistența formulelor KPI: strat semantic → un singur adevăr pentru rapoarte și API-uri.

5) Sisteme distribuite: ordine, repetiții, idempotență

Ordinea evenimentului: folosiți 'event _ time' + 'ingested _ at', filigrane și toleranță la întârziere; agregate bazate pe timpul evenimentului.
Redelivery (cel puțin o dată): global 'event _ id', tabele de taste idempotency, upsert/îmbinare prin cheie stabilă.
Out-of-order: recalcularea ferestrelor, strategie de întârziere, compensare.
Exact-o dată în sensul: transportul poate fi cel puțin o dată, receptor - idempotent.

6) Validarea integrității (DQ) pe fiecare strat

• Prospețime/Completitudine/Unicitate/Valori valide/Integritate referențială.
• Anomalii: explozii de duplicate, lipsuri de timp, schimbări ascuțite în distribuții.
• Controlul formulelor KPI: versioning de calcule și teste pentru potrivirea rezultatelor (seturi de aur).
• Controlul exporturilor - Interzicerea emiterii de seturi cu încălcări (carantină).

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) Integritatea financiară și operațională

Dublă intrare: debit/credit în sold; reconcilieri sumare în cut-off.
Total invarianți: suma de plată = suma de anulare + taxele + ajustările.
Invarianți operaționali: măsurătorile SLA/guardrail nu încalcă regulile de afaceri (de exemplu, reparația automată nu creează duplicate).

8) Lineage, audit și reproductibilitate

Linage: sursă pentru prezentare/caracteristică; vizibilitatea transformărilor și a proprietarilor.
Trasee de audit: cine a schimbat ce, când și de ce; schema/formula/versiunile de locuri de muncă.
Instantanee/puncte de control: capacitatea de a recalcula și de a confirma rapoartele anterioare.
Repro: aceeași interogare pe aceeași felie → același rezultat (versiuni și straturi).

9) Securitate și confidențialitate fără pierderea integrității

RLS/CLS: filtrele rând/coloană nu ar trebui să încalce invarianții (de exemplu, suma eșantionului vizibil ar trebui să se potrivească cu cea declarată).
Mascarea/tokenizarea: strategii deterministe pentru a asigura menținerea integrității dedup și referențiale.
Criptare: în canal și "pe disc' după compresie; managementul cheilor și auditul accesului.
DSAR/Retenție: ștergerea/anonimizarea nu rupe conectivitatea (politica în cascadă).

10) Autoservire și reparații automate

Carantină: izolarea părților/loturilor suspecte; consumatori - o ramură „curată”.
Replay/Backfill: Redă o fereastră dintr-un jurnal brut inalterabil.
Reconcilierea: reconcilieri strat și sistem (raw↔curated↔marts; istochnik↔DWH).
Dedup/Compactare/Reconstruire: proceduri de sistem pentru repararea indexurilor/agregatelor.
Policy-as-code: „ce anomalie → ce acțiune → praguri → escaladare”.

11) Practici de modelare și stocare

Chei stabile: surogat PK (UUID/ULID), chei naturale neschimbate în cărțile de referință.
Normalizatsiya↔denormalizatsiya: conexiuni FK în surse, vitrine denormalizate cu control logic al versiunii.
SCD1/SCD2: istorie ghidată pentru dimensiuni.
Sortare/grupare: Îmbunătățește RLE/zona-hărți și simplifică reconcilieri.
Hash-uri și sume de control: verificarea integrității fișierelor/loturilor.

12) Integritatea în timp și în raportare

Formula versiuni: Raportul ianuarie 2025 ar trebui să fie reproductibil cu o formulă versiune X.
Cut-off și „închiderea perioadei”: înghețarea ferestrelor magazinelor și a feliilor de arhivă.
Fapte cu întârziere: mecanica de reumplere și renumărări cu marcă versiune raport.
Documentarea suprascrie: ajustări manuale - numai audit.

13) Integrări și API-uri

Contract API: scheme, tipuri, câmpuri obligatorii, coduri de eroare; versioning (v1/v2).
Validarea la intrare: respingeți sarcinile utile proaste, nu „reparați în tăcere”.
Idempotent POST: cheie idempotence, încercați din nou în condiții de siguranță.
Export în fișiere: consistență lot, hash-uri, semnături.

14) Antipattern

SELECTAȚI în interogări de vânzări și viscole - se descompune cu evoluție MINORĂ.
FK „în cuvinte”: nici o verificare de referință reală.
Corecții silențioase ale datelor fără audit și raportare.
Se amestecă TZ și formatele de timp într-un singur set.
„Grip” KPI suprascrie fără versiuni și jurnale.
Cheie unică de eliminare a duplicatelor fără strategii de rezervă.
Ștergerea DSAR fără verificarea link-ului în cascadă.

15) Foaia de parcurs privind implementarea

1. Inventar și critică: hartă set/eveniment, proprietari, riscuri, invarianți.
2. Contracte și scheme: formalizați tipuri/constrângeri/controale de compatibilitate FK, CI.
3. DQ în conductă: prospețime/completitudine/unicitate/RI, carantină, alerte.
4. Baza tranzactionala: chiuveta atomica, upsert/fuziune, istoric SCD, versioning cu formula.
5. Lineage și audit: director, urmă, schimbare-busteni, acces-busteni.
6. Politici de reparare: reluare/backfill/dedup/reconcilia ca cod; runbook'и и SLO MTTR-date.
7. Securitate/priv: RLS/CLS, mascare, criptare, procese DSAR.
8. Raportare: cut-off, freeze-felii, KPI versioning.

16) Pre-lansare listă de verificare/caz de afișare

• PK/FK și constrângerile de domeniu sunt setate și testele de trecere.
• Schema/formula de versionare este activată; schema-diff verde.
• Regulile DQ (prospețime/completitudine/unicitate/intervale/RI) sunt verzi.
• Intrări idempotente: upsert/fuziune, cheie de idempotence (pentru evenimente).
• Timp: 'event _ time' și 'ingested _ at', TZ = UTC; politica de date cu întârziere.
• Lineage și audit vizibile; inclusiv carantină și alerte.
• RLS/CLS/mascarea nu încalcă invarianții și RI.
• Testat DSAR/retenție; cut-off/arhiva este gata.

17) Mini șabloane

SQL: verificarea integrității referențiale

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

politica de carantină/reparare (pseudo-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"

Diagrama SCD2 de măsurare

sql
-- dim_user_status (SCD2)
user_id, status, valid_from, valid_to, is_current

18) Linia de jos

Integritatea datelor nu este o singură verificare, ci un sistem de garanție end-to-end: contracte și restricții formale, invarianți tranzacționați și distribuiți, validarea și automatizarea reparațiilor, liniilor și auditului, confidențialității și drepturilor. Când aceste elemente lucrează împreună, datele devin o bază fiabilă pentru soluții, iar incidentele sunt rare, scurte și previzibile.