Date de auto-vindecare

1) Definiție și obiective

Datele de auto-vindecare sunt o abordare a ingineriei datelor în care defectele sunt detectate automat, iar acțiunile corective (reparare, re-livrare, rollback, re-consolidare, re-indexare) sunt efectuate fără intervenție umană sau cu intervenție minimă (om în buclă pentru cazuri sensibile).
Obiective: Reducerea datelor MTTR, creșterea încrederii, reziliența la derivă și eșec, costul previzibil al proprietății.

2) erori tipice care trebuie tratate pentru

Scheme și contracte: modificări incompatibile, coloane lipsă, conflicte de tip.
Calitate/integritate: duplicate, omisiuni, încălcări unicitate/integritate referențială.
Timp și prospețime: întârzieri de injectare, „găuri” în ferestre, desincronizarea TZ/localizări.
Identificatori și chei: schimbarea generatorului de ID, coliziuni, chei naturale plutitoare.
Ordinea evenimentelor: evenimente târzii, reordonare, re-livrare (cel puțin o dată).
Depozite: degradarea loturilor, fișiere/blocuri sparte, distorsionarea ascuțirii.
Drepturi/securitate: măști incorecte/criptare, scurgeri PII în încărcări.

3) Piloni de auto-vindecare

1. Contracte de date (scheme + reguli) cu teste automate.
2. Conducte idempotente (reporniți fără efecte duble).
3. Jurnalizarea și reproductibilitatea (brut/bronz neschimbabil, descendență).
4. Mecanisme de reparare (reluare, rambursare, compactare, îmbinare-reparare, reconstrui).
5. Observabilitate și SLO (prospețime, completitudine, unicitate, latență).
6. Politici de luare a deciziilor (când auto-fixăm, când escaladăm).

4) Contracte și teste de calitate

Contractul descrie: schema, intervale acceptabile, unicitate, RLS/mascare, SLA prospețime.

yaml dataset: payments 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: created_at; type: timestamp; tz: UTC freshness_sla: 15m constraints:
- "count(distinct txn_id) = count()"
- "pct_null(user_id) < 0. 1%"
privacy:
- mask: card_pan -> BIN6LAST4 actions_on_violation:
- auto_quarantine_partition
- backfill_missing_window
- notify_owner_and_open_ticket

Testele se execută la fiecare pas: injecție → montare → vitrină. Încălcarea regulilor activează auto-repararea (a se vedea mai jos) și/sau carantina.

5) Idempotența și determinismul

Upsert/Merge prin chei stabile (SCD2 pentru istorie, SCD1 pentru felii).
Transformări deterministe: o intrare → o ieșire cu aceiași parametri.
Versioning - Fixați versiunea de cod/schemă/strat și eticheta de date (filigran).
Chiuvetă Idempotent: înregistrare prin staging + swap atomic/redenumire.
Exact-o dată în sensul: acceptabil „cel puțin o dată” transport + receptor idempotent.

6) Setul de instrumente de reparare

Replay/Backfill: redelivery for window 't ∈ [T0, T1]' from inalterable log (raw).
Reconciliere: compararea agregatelor/cheilor între straturi (marte de ↔ brute ↔ curate) și între sisteme (sursă ↔ DWH).
Deduplicare: fereastră-dedup după cheie (txn_id, event_id) + distanță euristică (fuzzy pentru chei murdare).
Compactare: transferul fișierelor mici către părți mari (Parchet/ORC), re-indexare.
Fuziune-reparare: atunci când înregistrările conflict, predicatele prioritare (de sursă/timp/versiune).
Reconstrui indici/materializări: agregate recalculatoare/cub/roll-up.
Carantină/umbră: părțile suspecte se izolează; consumatorii citesc un fir „curat”.
Schema de mediere: selector automat de proiecție (umplere defaults, coloane calculabile) pentru modificări minore.

7) Protecția și integritatea stocării

Verificați sumele și validarea blocurilor (CRC, paritate).
Stocare cvorum (sisteme compatibile RAFT/Paxos, cvorum citește/scrie).
Codificarea ștergerii pentru o redundanță rentabilă.
Magazin de obiecte versioning (undelete).
Atomic comite в Lakehouse (jurnal de tranzacții, ACID- таблицы: Delta/Iceberg/Hudi).

8) Ordinea evenimentelor și „realitatea murdară”

Evenimente târzii: păstrați fereastra de întârziere, utilizați filigran "și; recalcularea ferestrelor.
Redelivery: dedup prin tabelele globale 'event _ id', idempotency-keys.
Timpul offset: normalizarea TZ, stocarea 'ingested _ at' and 'event _ time'.
Out-of-order: agregate event_time-based cu ajustare filigran.

9) Logica decizională (motor de politică)

Regula: „ce anomalie → ce acțiune → ce praguri → cine este proprietarul”.

yaml policy: payments_freshness detect: freshness_delay > 15m auto_actions:
- trigger: backfill(last_60m)
- if: gap_persisted > 30m then: quarantine_partition(date=today, hour=current_hour)
escalate:
- if: gap_persisted > 60m -> page_oncall:data guardrails:
- do_not_expose_unverified_to_marts

10) Observabilitate și SLO pentru date

• Prospețimea carcaselor de afișare ≤ 15 min.
• Completitudine> 99. 5% pe câmpurile cheie.
• Unicitate: duplicate <0. 01%.
• Latența calculului: p95 <5 min.
• Stabilitatea reparațiilor: date MTTR <30 min.

Metrică și alerte: expoziție în Prometheus/Grafana; Construiți o bandă prioritară a incidentelor de date.

11) Reconciliere (practici)

Verificați agregatele: 'count/sum/min/max' între straturi/sisteme pe fereastra glisantă.
Reconcilierea cheie: diferența simetrică a seturilor 'Δ = (A\B) ∪ (B\A)'.
Periodic „job de audit”: comparație cu sursa, verificare selectivă la sursă.
Plăți/finanțe: dublă intrare, reconcilieri zilnice, jurnal de ajustare.

12) Managementul circuitului și evoluția

SemVer pentru scheme: MAJOR (pauze )/MINOR (adăugări )/PATCH (remedieri).
Contracte în CI/CD: schema-diff, compatibilitatea, autogenerarea migrațiilor.
Cârlig Backfill: cu MINOR adăugați câmpuri implicite/calculate, recalculați vitrinele.
Proiecții flexibile: Cititorii citesc subseturi de coloane; interzice „SELECT”.

13) Securitate, confidențialitate, conformitate

RLS/CLS: filtre rând/coloană, în special în ramurile de reparații și exporturi.
Tokenizare bazată pe PII pentru o eliminare durabilă a duplicatelor.
Audit de acces/export: cine a văzut ce au exportat, unde l-au trimis.
DSAR/Retentie: auto-stergere/anonimizare in procesele de reparatii; kickbacks iau în considerare cerințele legale.

14) Costul și performanța

Rambursare fără costuri: limitarea lățimii ferestrelor (de exemplu, alunecarea 3-7 zile).
Materializări și cache-uri: recalcularea doar a loturilor schimbate (incremental).
Prioritizarea: în primul rând vitrine critice (finanțe, riscuri), apoi analitice.
Reparații off-peak: ferestre de noapte/prioritate scăzută în programator.

15) Simulări de testare și incidente

Haos-date-testare: Rupeți în mod deliberat partiții/circuite pe scenă.
Întârzieri false: loturi false, out-of-order, duplicate.
Seturi de date de aur: repere pentru reconcilierea post-reparație.
GameDays: antrenament regulat al echipei pe runbooks.

16) Antipattern

„Invizibil” remediază: modificări silențioase fără audit sau raportare.
Backfills netestat: nici o sursă de adevăr/versiune formulă.
Solicitări grele live către OLTP în timpul reparațiilor: terminați prod.
SELECT în consumatori: pauze cu orice modificare MINOR.
Singura cheie pentru eliminarea duplicatelor este absența cheilor de rezervă/semnăturilor hash.

17) Foaia de parcurs privind implementarea

1. Descoperire: seturi/valori critice, riscuri, proprietari; hartă dependență.
2. Contracte și încercări: formalizați scheme/reguli în CI; publică glosarul.
3. Idempotency: rescrieți conductele cheie în upsert/îmbinare, chiuvetă atomică.
4. Jurnal brut și descendență: strat imuabil, metadate complete, filigran "și.
5. Mecanica de reparare: rambursare/reluare, dedup, compactare, carantină; motor de politică.
6. Observabilitate și SLO: tablouri de bord de calitate, alerte, bandă prioritară.
7. Haos-date și formare: exerciții regulate + runbook 'și.
8. Optimizarea costurilor: recalculări incrementale, prioritizarea ferestrelor.

18) Lista de verificare înainte de lansare

• Contractele de date și testele de calitate acoperă seturi critice.
• Conductele sunt idempotente; există comite atomice și pullback.
• Backfill/reluarea și carantina sunt configurate, politicile de escaladare sunt specificate.
• Prospețime/Completitudine/Unicitate/Metrica latenței și alerte în prod.
• Auditul inclus al editărilor/reparațiilor; stochează versiuni de formule și vitrine.
• DSAR/Retenția este urmată pentru reparații și rollback.
• Există un runbook 'și, exerciții efectuate, MTTR-țintă fixă.
• Costul rambursărilor este limitat de gărzile bugetare.

19) Exemple de auto-acțiuni (șabloane)

„Fereastra prospețime eșec X” → rambursare (last_2h) → dacă nu este ok în 30 de minute → carantină + pagina de apel.
„Duplicate txn_id spike” → include dedup strict + reconciliere sursă → raport de cauză.
„Schimbare schemă minoră” → genera un câmp implicit calculat → reconstrui agregate.
„Pierderea loturilor” → → restabili verificarea sumei de verificare din obiectul versionat.

Linia de fund: datele de auto-vindecare nu este un „script de reparații”, ci o arhitectură de sistem: contracte formale, conducte idempotente, exploatare forestieră fiabilă, mecanică automată de reparații și observabilitate transparentă cu SLO-uri stricte. Un astfel de sistem nu numai că se repară, ci și transformă incidentele în evenimente ușor de gestionat cu un cost și un timp de recuperare ușor de înțeles.