Origine dati

Origine dati (Lineage)

1) Cosa è lineage e perché è necessario

Data Lineage è un record formale «da cui vengono i dati, come sono stati trasformati, dove e chi sono stati utilizzati». Il risultato è un grafico orientato delle dipendenze con attributi (tempo, versioni, proprietari, trasformazioni, criteri di accesso, qualità) che rende il sistema di dati comprensibile e verificabile.

• Trasparenza delle metriche (finanza, prodotto, rischio): "Perché X = 1.234? ».
• Analisi rapida di impatto delle modifiche (schema/deb): «cosa si rompe se»....
• Corrispondenza e controllo (GDPR/ISO/SOCC) - Percorso campo provabile.
• Accelerazione dell'onboard e riduzione del toil (self-service della conoscenza).
• Miglioramento della qualità: controlli mirati dove il rischio è maggiore.

2) Aree di copertura e livelli di dettaglio

Livello di flusso (pipeline/job) - Quali giubbotti/orchestratori hanno generato i dataset.
Livello dataset (table/view/topic/file) - Entrate, uscite, versioni/snapshot.
Livello colonna (column/feature-level) - Come viene calcolato ogni campo, da quali sorgenti.
Livello di consumo: report BI, API, modelli ML, dashboard e avvisi.

Per le entità critiche (denaro, regolazione), il dettaglio column-level è obbligatorio.

3) Modello di dati lineage: entità chiave

Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`

Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`

Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`

Field: '{dataset _ urn, name, type, derivation}' (espressione/AST/operatore).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Sorgenti lineage - Assieme passivo attivo vs

Attivo (event-based) - Consente di utilizzare gli orchestratori/motori (Spark/DBT/SQL engines/Kafka) per emettere eventi «job started/finished, inputs/outputs, column-mapping».

I vantaggi sono precisione, rilevanza, minimizzazione del post-parsing.
Passivo (inference): parsim DAG 'e, SQL/DDL/logic query, login di directory/storage; costruiamo dipendenze in modo retroattivo.

Pro: copertura rapida del patrimonio; contro: più bassa precisione su column-level.

Di solito vengono utilizzati gli eventi ibridi, gli eventi attivi dove è possibile e l'analisi passiva come «griglia di assicurazione».

5) Architettura della soluzione (riferimento)

Producers (orchestratori/motori) Gomma eventi lineage Normalizzatore Indice/Ricerca UI/API/alert Esporta/directory.

Eventi unificati (job/run/dataset/column-lineage), con identificatori URN e versioni semantiche.
L'archivio grafico è un grafico column-level (ad esempio basato su database grafico o relazionale + inverted index).
UI: visualizzazione interattiva dei percorsi più brevi, impatto/radice-causa, «segnali di qualità» su costole e nodi.
Integrazioni: catalogo dei dati, sistema di qualità (DQ), controllo dell'accesso (ABAC), controllo (append-only registri).

6) Identificatori e versioning

URN/Global ID per ogni dataset/jobs/campo: stabile, umano, inclusa piattaforma/neimspace/nome/versione.
Versioni dello schema (SchemaVersion) e del codice (code SHA, immagine digest).
Istantanee di tempo (time-travel lineage) - Riproduzione delle indagini.

7) Column-level lineage: come ottenere in modo affidabile

Parsing SQL con costruzione AST e normalizzazione degli aliasi/STE/uch.
Annotazioni nel codice delle trasformazioni (DBT test, comme primitive, UDF-metadata).
Eventi dai motori - Specifica le espressioni "target. col = f(src. a, src. b)».
Regole semantiche: UDF/ops di aggregazione sono contrassegnati come «lossy» (con perdita di granolarità) o «sensitive-faciliting» (trasferisce etichette PII).

8) Collegamento lineage con privacy e sicurezza

Privacy by Design: etichette dei campi «pii _ class», «consent _ scope», «retention». Quando si promuovono colonne, le etichette vengono trasmesse secondo le regole (ad esempio, «email n'hash _ email» rimane PII-derived).
Torning PII: lineage memorizza il torning/disinstallazione e i nodi del servizio di token; Qualsiasi detonazione è un evento di revisione.
Crittografia: per i campi AEAD/FPE lineage registra «stato cripto» e l'area chiave (tenant/scope) è senza rivelazione chiavi.
Controllo e WORM - Gli eventi lineage e le modifiche ai criteri vengono memorizzati in un registro non modificabile (append-only con catene hash).

9) Qualità dei dati e SLO basato su lineage

Assegni delle costole: freschezza (freshness), completezza (completeness), unicità/chiavi, deriva di distribuzione.
SLO/SLI: «Il 95% delle ≤ che alimentano le metriche finotette sono completate alle 6:00 UTC».
Root-cause - Grafico + tempi di esecuzione consentono di definire rapidamente il «primo nodo rotto».

10) Analisi e gestione delle modifiche

Quando lo schema o la logica vengono modificati pianificatamente, il grafico in basso per flusso (downstream) è un elenco di report/modelli/client API interessati.
Criterio «breaking changes»: notifica obbligatoria ai proprietari degli artefatti downstream, periodo grace, versioni parallele («v1 »/« v2») e flag «sunset-date».
PR/ticket automatici con elenco dei consumatori e assegno di migrazione.

11) Integrazione con orchestratori e motori

Orchestratori: prima/dopo job vengono emessi gli eventi «RunStarted/RunCompleted» con inputs/outputs.
SQL/ELT: connettori ai motori (warehouse, lakehouse) per ottenere il piano effettivo di esecuzione e mapping delle colonne.
Stream-processing: lineage dei messaggi (topic→topic, key/headers), schemi Avro/Protobuf, evoluzione dei diagrammi attraverso registry.
ML: lineage fitch/dataset, versioni del modello, artefatti di allenamento, fonti di segni.

12) Modellazione delle regole di espansione delle etichette (data contracts)

Contratto set di dati: schema + semantico dei campi (chiavi, PII, aggregabilità, licenze/basi legali, retention).

• "SELECT a, b FROM T" → a, b ".
• «hash (email)», etichetta «PII-derived (pseudonymized)», con disattivazione proibita.
• «SUM (amount)» è una perdita di personalità; non sono consentiti join'sul campo del risultato.
• I contratti sono validi in CI (blocker in caso di inadempienza) e le violazioni sono eventi di verifica.

13) Prestazioni e scala

Iniezione incrementale di eventi lineage; deduplicazione per '(run _ id, job _ urn)'.
Archiviazione del grafico: suddivisione dell'indice caldo (ultimi 30-90 giorni) e dell'archivio Snapshot.
Memorizzazione nella cache dei percorsi per le query frequenti (brevi percorsi per le metriche dorate).
Sharding per Neimspace/affittuari; Protezione da «nodi mostri» (vincolo fan-out).

14) Visualizzazione e UX

• Path to metric: «Da cosa viene raccolta la metrica».
• Effetto from source: «chi sarà influenzato dal cambiamento».
• Field lineage: «come calcolato il campo».
• Overlay: states, qualità, etichette PII, retenze, proprietari.
• Azioni: aprire un contratto, creare un ticket per la migrazione, sottoscrivere gli alert del cambiamento.

15) Protezione dell'accesso al grafico

ABAC - La visibilità nodi/costole è limitata agli affittuari/ruoli.
Redaction - Nasconde i nomi dei campi sensibili (o li alias) in UI per i ruoli non preparati.
mTLS/OIDC per l'API gli eventi lineage sono firmati da identità di servizio.
WORM e controllo della lettura: anche la lettura dei segmenti critici del grafico viene registrata.

16) Utilizzo: SLO, monitoraggio, alert

SLO grafico: ritardo della comparsa dell'evento <5 min; completezza della copertura> 98% pipline critiche Il 100% delle «metriche d'oro» sono column-level lineage.
Alert: rottura della catena, run senza eventi di completamento, incoerenza degli schemi, dataseti «orfani», crescita del fan-out/ciclo.
Report: Stato of lineage coverage settimanale, top 10 nodi rischiosi.

17) Privacy e compilazione (legamenti)

GDPR/PbD - Memorizzare le basi di elaborazione e ritenzione come tag. lineage consente di individuare rapidamente i percorsi DSAR e «diritto di eliminazione» attraverso la crittografia a cascata per eliminare i segmenti appropriati.
Gestione dei segreti: le fonti di accesso alle materie prime non entrano mai nel lineage come credenze aperte; memorizzato solo il riferimento al ruolo/criterio.
Registri non modificati: tutti gli eventi lineage sono firmati e fissati in un archivio append-only (vedere l'articolo appropriato).

18) Assegno fogli

• Definiti gli accordi URN per i datasets/jobs/fields.
• È abilitata l'emissione di eventi lineage da orchestratori e motori.
• Funziona il parser SQL/DDL e il normalizzatore degli schemi.
• Approvati i data contracts e le regole di espansione PII/retensioni.
• Il registro eventi WORM e i backup del grafico sono stati configurati.
• BI/ML sono collegati come utenti lineage (report, modelli, fitch).

• Copertura lineage per domini critici: 98%, column-level per «denaro» = 100%.
• Gli alerti di rottura, i dataseti «orfani», la deriva degli schemi sono accesi.
• Controllo trimestrale delle etichette PII e dei contratti.
• Elaborazione delle modifiche (breaking) e distribuzione ai consumatori.

19) Mini-ricette

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) Errori frequenti e come evitarli

Lineage «immagine» senza modello formale. Sono necessari eventi/schemi/URN, altrimenti il conte non è scalabile.
Non c'è column-level dove «soldi». Impossibile spiegare i calcoli senza un livello di colonna.
Eventi incompleti (senza code _ sha/versione degli schemi). Impossibile riprodurre.
Ignorare la privacy. Le etichette PII devono essere vissute e trasportate insieme ai campi.
Un grande database di grafica senza charding. Dividetevi per i Neimspace, tenete i snapshot.
Fede cieca ai parsers. In caso di controversie, eventi attivi da motori.

21) Runbook’и

L'incidente è che la metrica è saltata.

1. Apri Path to metric per controllare gli ultimi nodi Run lungo il percorso.
2. Incrocia le versioni codice/schema, lo stato DQ degli assegni sulle nervature.
3. Se trovate un anello rotto, create un ticket al proprietario, attivate la pubblicazione temporanea «hold» della metrica.
4. Dopo la fix, segnare RCA e associare ai nodi del grafico.

Modifica dello schema di origine.

1. Richiedi l'impatto downstream.
2. Invia notifiche ai proprietari, crea messaggi di migrazione.
3. Alza il parallelo «v _ next», mantenendo entrambe le versioni fino alla data sunset.
4. Chiudi v _ prev, aggiorna i contratti e il grafico lineage.

• «Privacy by Design (GDPR)»
• Tornitura dei dati PII
• «Gestione dei segreti»
• Controllo e registri invariati
• Crittografia At Rest/In Transit
• Gestione e rotazione delle chiavi