Skip to content

Lineage a livello di campo, da un riquadro della dashboard a una colonna del warehouse

La lineage a livello di tabella ti dice che una dashboard tocca una tabella. La lineage a livello di colonna ti dice quali dashboard si rompono quando elimini una colonna. Ecco la differenza, perché l’ultimo salto è difficile, e come leggere una mappa senza affogarci.

Aggiornato · 5 min di lettura

Cosa aggiunge la granularità di colonna

Una colonna sta per essere eliminata, ritipizzata o rinominata. Due domande suonano uguali in quel momento. Una è: quali dashboard toccano questa tabella. L’altra è: quali dashboard si rompono.

La lineage a livello di tabella risponde alla prima. Su una tabella larga restituisce quaranta dashboard. Due di esse usano la colonna, e ora qualcuno deve aprire quaranta cartelle di lavoro per trovare quelle due. Il rapporto è giusto, e quasi inutile.

La lineage a livello di colonna risponde alla seconda, ed è per questo che il lavoro in più per raggiungere quella granularità vale la pena.

La catena, salto per salto

  1. Un riquadro della dashboard mostra un foglio, e il foglio usa dei campi.
  2. Ogni campo è o un calcolo o un collegamento diretto a un’origine dati.
  3. Un calcolo usa altri campi, a volte su più livelli, a volte attraverso più origini dati.
  4. Un campo dell’origine dati corrisponde a una colonna in una tabella fisica.
  5. Quella tabella ha tabelle a monte, attraverso viste e trasformazioni, fino a dove i dati sono arrivati per la prima volta.

Ogni salto attraversa un confine di sistema. Ogni sistema ha la propria idea di cosa sia un nome. È lì che vive il problema, non nel disegno del grafo.

L’ultimo salto

Qui compaiono due problemi. Entrambi sono stati trovati sondando warehouse reali, non leggendone.

  • I nomi arrivano quotati nel dialetto. Un’API di metadati restituisce il nome completo quotato come lo quota il proprio dialetto. Non è una stringa che un altro motore accetta così com’è.
  • Maiuscole e minuscole contano. I bind di Snowflake distinguono maiuscole e minuscole, e un nome non quotato viene convertito in maiuscolo. Fai il bind di un nome grezzo e non corrisponde a nessuna riga.

Uno zero silenzioso è il peggior guasto nella lineage. Un risultato vuoto sembra identico a una risposta pulita. Un collegamento connesso, configurato bene e che non corrisponde a nulla si legge come un ambiente senza alcuna dipendenza.

La soluzione è normalizzare prima di ogni sondaggio del warehouse, non alla fine. I segmenti Snowflake non quotati vengono convertiti in maiuscolo. I nomi Databricks vengono dequotati e messi in minuscolo nell’SQL stesso. Il nome completo viene diviso in segmenti invece di essere smontato con una ricerca di stringhe.

Da dove vengono gli archi di colonna

Snowflake
La funzione di lineage propria dell’account, con distanza limitata così che un grafo profondo non scappi via. Un ripiego sull’uso dell’account copre gli account più vecchi in cui quella funzione manca.
Databricks
system.access.column_lineage. Vera lineage da colonna a colonna tenuta dalla piattaforma stessa, che è la prova più forte disponibile.
Palantir AIP
I tipi di link, letti da ogni tipo di oggetto a turno. Sono il grafo di join proprio dell’ontologia, e la direzione in cui corrono è quella che la piattaforma dichiara, non una dedotta dai nomi.
Tableau
La Metadata API. Risponde a livello di colonna quando il catalogo ha indicizzato fin lì, e a livello di tabella quando non lo ha fatto. Quel caso va gestito, non dato per risolto.
Corrispondenza per nome
Un ponte da un campo dell’origine dati a una colonna del warehouse tramite il nome. Usato solo dove la corrispondenza è unica, e sempre etichettato come abbinato.

Il quarto merita uno sguardo severo, e il prodotto glielo dà. Un ponte abbinato per nome è etichettato come abbinato, e non viene mai mostrato come dato di catalogo. Un’ipotesi etichettata come ipotesi è utile. Un’ipotesi promossa in silenzio a fatto rovina l’intera mappa, comprese le parti che erano giuste.

Dichiara quale granularità hai raggiunto

Una mappa di lineage dovrebbe dichiarare la granularità che ha raggiunto, e nominare cosa l’ha completata. Il catalogo può rispondere a livello di tabella. Gli elenchi di colonne estratti dal warehouse finiscono poi il lavoro, e la mappa dice esattamente questo.

Sembra una piccola questione di buone maniere. È il divario tra una mappa da cui puoi decidere e una mappa che devi verificare a mano. Una mappa che dichiara sempre la granularità di colonna ogni tanto sbaglierà, e non dirà mai quali volte sono state.

Leggere una mappa senza affogarci

Un grafo completo a livello di colonna di un ambiente reale è difficile da leggere tutto in una volta. Migliaia di nodi non sono una mappa. Sono una trama.

Il primo caricamento mostra la spina dorsale a livello di tabella. Clicca su una scheda e si apre solo la granularità di quella scheda: le sue colonne, e i campi che ne derivano. È un salto, non l’intera chiusura. Il layout poi si riadatta, così ciò che si è aperto arriva in vista.

Quel comportamento è venuto fuori da due giri di uso reale, in entrambe le direzioni. Mostrare tutto è stato provato per primo, ed era inutilizzabile. La risposta si è rivelata un’apertura locale invece di un grafo più piccolo: un’idea diversa, e migliore.

Per cosa usarla

  • Lavoro di impatto prima di una modifica allo schema. Ottieni l’elenco reale delle dashboard colpite, non quello largo.
  • Risalire da un numero alla sua sorgente quando due dashboard non concordano ed entrambi gli autori sono sicuri.
  • Scoprire quali dashboard si appoggiano a una tabella di cui nessuno ammette di essere proprietario.
  • Consegnare a qualcuno una mappa autonoma che può esplorare cliccando, esportata come un unico file HTML. Funziona senza server e senza internet.

L’esportazione merita di essere conosciuta. Le conversazioni di governance avvengono con persone che non hanno un accesso e non lo avranno. Un file che possono aprire batte un invito che non accetteranno.