Originea datelor

Lineage

1) Ce este descendența și de ce este necesar

Data Lineage este o înregistrare formală a "de unde au venit datele, cum au fost transformate, unde și de către cine au fost folosite. "Rezultatul este un grafic direcționat al dependențelor cu atribute (timp, versiuni, proprietari, transformări, politici de acces, calitate), ceea ce face sistemul de date ușor de înțeles și auditat.

• Transparența măsurătorilor (finanțe, produse, riscuri): "de ce este numărul X = 1.234? ».
• Analiza rapidă a impactului schimbărilor (schema/locul de muncă): „ce se va rupe dacă”....
• Conformitatea și auditul (GDPR/ISO/SOC): cale de teren probabilă.
• Accelerarea îmbarcării și reducerea trudei (cunoștințe de autoservire).
• Îmbunătățirea calității: inspecții direcționate în cazul în care riscul este mai mare.

2) Arii de acoperire și niveluri de detaliu

Stream level (pipeline/job): Ce locuri de muncă/orchestratori au dat naștere seturilor de date.
Nivelul setului de date (tabel/vizualizare/subiect/fișier): intrări → ieșiri, versiuni/instantanee.
Coloana/feature-level - cum se calculează fiecare câmp, din ce surse.
Strat de consum: rapoarte BI, API-uri, modele ML, tablouri de bord și alerte.

Pentru entitățile critice (bani, reglementări), este necesară detalierea nivelului coloanelor.

3) Modelul de date Lineage - Entități cheie

Set de date: '{urn, type, schema, proprietarii, pii_class, retentie, tag-uri}'

Job/Task: '{urn, code_ref, version, runtime, scheme, owners}'

Run/Execution: '{run _ id, job_urn, start/end, status, inputs [], outputs [], code_sha, infra}'

Câmp: '{dataset _ urn, name, type, derivation}' (derivare - expresie/AST/operator).

Politica: '{dataset _ urn/field, access_rules, mascare, consent_scope}'

Verificarea calității: '{check _ id, scope, rule, severity, result}'

4) Surse de linie: activ vs asamblare pasivă

Active (bazate pe evenimente): orchestratoare/motoare de instrumente (Spark/DBT/SQL motoare/Kafka) pentru a emite evenimente „loc de muncă început/terminat, intrări/ieșiri, coloană-mapping”.

Pro: precizie, relevanță, minimizarea post-parsare.
Pasiv (deducție): DAG parsim, cereri SQL/DDL/jurnal, jurnale de director/stocare; construi dependențe retroactiv.

Pro: acoperire rapidă a patrimoniului; contra: precizie mai mică la nivel de coloană.

De obicei se folosește un hibrid: evenimente active acolo unde este posibil și analiză pasivă ca „grilă de asigurare”.

5) Arhitectura soluției (referință)

Producatori (orchestratori/motoare) Lineage event bus Normalizer Graph storage Index/search UI/API/alerts Export/catalog.

Evenimente: unificate (job/run/datset/column-lineage), cu URN-uri și versiuni semantice.
Stocare grafic: grafic nivel coloană (de exemplu, pe baza unei baze de date grafic sau relațional + index inversat).
UI: vizualizarea interactivă a celor mai scurte căi, impact/cauză rădăcină, „semnale de calitate” pe margini și noduri.
Integrari: catalog de date, sistem de calitate (DQ), control acces (ABAC), audit (busteni addend-only).

6) Identificatori și versioning

URN/Global ID pentru fiecare set de date/locuri de muncă/domenii: stabil, uman-lizibil, inclusiv platforma/namespace/nume/versiune.
SchemaVersion și versiunea de cod (cod SHA, digest imagine).
Linia de călătorie în timp: reproductibilitatea investigațiilor.

7) Descendență la nivel de coloană: cum să obțineți încredere

Parsarea SQL cu construcția AST și normalizarea pseudonimelor/CTE/viscol.
Adnotări în codul de transformare (teste DBT, comentarii primitive, metadate UDF).

Evenimente din motoare: specificarea "țintă. col = f (src. a, src. b) "

Reguli semantice: opses UDF/agregare sunt marcate ca „lossy” (cu pierderea de granularitate) sau „sensibil-conservarea” (transferuri PII tag-uri).

8) Conectarea liniei la confidențialitate și securitate

Confidențialitate prin Design: etichete de câmp "pi _ class'," consimțământ _ scope "," păstrare ". La promovarea coloanelor, etichetele sunt transmise în conformitate cu regulile (de exemplu, "e-mail → hash_email' rămășițele derivate din PII).
Tokenizarea PII: tokenizarea/detokenizarea magazinelor și nodurile de servicii token; orice detokenizare este un eveniment de audit.
Criptare: pentru câmpurile AEAD/FPE, descendența captează „statul cripto” și zona cheie (chiriaș/domeniu de aplicare) - fără dezvăluirea cheii.
Audit și WORM - evenimentele de descendență și schimbările de politică sunt stocate într-un jurnal nemodificabil (adăugați numai cu lanțuri hash).

9) Calitatea datelor și SLO-urile bazate pe linii

Verificări pe margini: prospețime, completitudine, unicitate/chei, derivă de distribuții.
SLO/SLI: „95% din locurile de muncă de hrănire a metricii fino-raport finalizate ≤ 06:00 UTC”.
Cauza rădăcinii: graficul + timpii de execuție dau o definiție rapidă a "primului nod'.

10) Analiza impactului și managementul schimbărilor

În cazul unei modificări planificate a schemei/logicii: prin coloana din aval (în aval) - o listă de rapoarte/modele/clienți API afectați.
Politica privind modificările de ultimă oră: notificarea obligatorie a proprietarilor de artefacte din aval, perioada de grație, versiunile paralele („v1 ”/„ v2”) și pavilionul de la apusul soarelui.
PR automat/bilete cu o listă de consumatori și o listă de verificare a migrației.

11) Integrarea cu orchestratori și motoare

Orchestratori: evenimentele „RunStarted/RunFinalized” cu intrări/ieșiri sunt emise înainte/după locul de muncă.
SQL/ELT: conectori la motoare (depozit, lakehouse) pentru a obține planul real de execuție și cartografierea coloanelor.
Stream-procesare: descendența mesajelor (topic→topic, cheie/antete), scheme Avro/Protobuf, evoluția schemelor prin registru.
ML: caracteristici de descendență/seturi de date, versiuni de model, artefacte de formare, surse de caracteristici.

12) Modelarea regulilor de propagare a etichetelor (contracte de date)

Contract set de date: schema + semantica de câmp (chei, PII, agregabilitate, licențe/motive legale, retenție).

• „SELECTAŢI o, b DIN T” → mutaţi etichetele „a, b”.
• 'hash (email)' → etichetă 'derivată din PII (pseudonimizată)' cu detokenizare interzisă.
• „SUMA (suma)” → pierderea individualității; alăturați-vă nu sunt permise pe câmpul de rezultat.
• Contractele sunt validate în CI (blocant în caz de nerespectare), iar încălcările sunt evenimente în audit.

13) Performanță și scară

Injecţie incrementală a evenimentelor de descendenţă; deduplicarea prin „(run_id, job_urn)”.
Stocarea coloanelor: separarea indicelui cald (ultimele 30-90 de zile) și arhiva; instantanee.
Căi de caching pentru cereri frecvente (căi scurte către metrici „de aur”).
Împărțirea de către neimspaces/chiriași; protecție împotriva „nodurilor monstru” (limitare fan-out).

14) Vizualizare și UX

• Calea către metrică: „din care este asamblată metrica”.
• Impact de la sursă: „cine va fi afectat de schimbare”.
• Descendența câmpului: „modul în care se calculează câmpul”.
• Suprapuneri: statusuri de locuri de muncă, calitate, etichete PII, retenții, proprietari.
• Acțiuni: deschideți un contract, creați un bilet pentru migrare, abonați-vă pentru a schimba alertele.

15) Securitatea accesului la grafic

ABAC: Vizibilitatea nodului/marginii este limitată la chiriași/roluri.
Redactare: ascunderea numelor de câmpuri sensibile (sau aliasing-le) în UI pentru roluri neantrenate.
mTLS/OIDC pentru evenimente de linie API sunt semnate cu identități de serviciu.
WORM și controlul citirii: citirea segmentelor critice ale graficului este, de asemenea, înregistrată.

16) Funcționare: SLO, monitorizare, alerte

Grafic SLO: întârziere eveniment <5 min; acoperire completă> 98% din conductele critice; 100% din „metricile de aur” au descendență la nivel de coloană.
Alerte: rupere lanț, a alerga fără evenimente de finalizare, scheme inconsecvente, seturi de date orfane, ventilator de creștere/cicluri.
Rapoarte: săptămânal „starea de acoperire descendență”, top 10 noduri de risc.

17) Confidențialitate și conformitate (pachete)

GDPR/PbD: stocați bazele de procesare și retențiile ca tag-uri; descendența oferă căi rapide DSAR și „dreptul de a șterge” prin ștergerea cripto în cascadă a segmentelor corespunzătoare.
Gestionarea secretă: sursele de acces la materii prime nu intră niciodată în descendență ca credite deschise; numai rolul/referința politicii este stocată.
Jurnalele de audit/nemodificate - toate evenimentele de descendență sunt semnate și fixate în depozitul numai pentru adăugare (a se vedea articolul corespunzător).

18) Liste de verificare

• Acorduri URN definite pentru seturi de date/locuri de muncă/domenii.
• A permis emisia de evenimente de descendență de la orchestratori și motoare.
• SQL/DDL parser și schema de lucru normalizator.
• Sunt aprobate contractele de date și normele de propagare PII/păstrare.
• Configurat jurnal de evenimente WORM și backup grafic.
• BI/ML sunt conectate ca consumatori de linie (rapoarte, modele, caracteristici).

• Lineage acoperire pentru domenii critice ≥ 98%, coloana-nivel pentru „bani” = 100%.
• Alerte pentru pauze, seturi de date orfane, derivă de circuit sunt pornite.
• Audituri trimestriale ale etichetelor și contractelor PII.
• Fluxul de documente de modificări (rupere) și distribuție către consumatori.

19) Mini rețete

json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

20) Greșeli frecvente și cum să le evitați

Descendență „în imagine” fără un model formal. Sunt necesare evenimente/scheme/URN, altfel graficul nu este scalat.
Nu există nici o coloană-nivel în cazul în care există "bani. "Calculele nu pot fi explicate fără un nivel de coloană.
Evenimente incomplete (fără scheme code_sha/versii). Reproductibilitatea nu este posibilă.
Ignoră intimitatea. Etichetele PII trebuie să trăiască și să fie transportate cu câmpurile.
O bază de date mare grafic fără sharding. Împărțiți după namespace-uri, stocați instantanee.
Credinţa oarbă în parseri. În cazuri controversate - evenimente active din motoare.

21) Runbook'и

Incident: Metric „a sărit”.

1. Deschideți „Calea către metrică” → verificați ultimele noduri 'Run' de pe traseu.
2. Verificați versiunile de cod/schemă, verificați starea DQ pe margini.
3. Dacă se găsește o legătură ruptă, creați un bilet pentru proprietar, permiteți „păstrarea” temporară a publicației metrice.
4. După fixare - marcați RCA și asociați-vă cu nodurile graficului.

Modificarea schemei sursă.

1. Solicit un impact în aval.
2. Trimiteți notificări proprietarilor, creați PR-uri de migrare.
3. Ridicați paralel "v _ next', păstrați ambele versiuni până la apusul soarelui.
4. Închideți „v _ anterior”, actualizați contractele și graficul de descendență.

• „Confidențialitate prin design (GDPR)”
• „Tokenizarea datelor PII”
• „Managementul secret”
• „Audit și jurnale imuabile”
• „În repaus/În tranzit criptare”
• „Managementul și rotația cheilor”