Dal KPI alla tabella sorgente: usare il lineage in BigQuery e Knowledge Catalog

Perché partire dal KPI quando il numero non torna

Quando una dashboard mostra un valore inatteso, il rischio è discutere il numero finale senza capire da dove arrivi. Il lineage aiuta proprio in questo: permette di risalire dal KPI alle tabelle e alle viste che lo alimentano, per leggere i passaggi che hanno costruito quel risultato e capire dove serve una verifica umana. Google Cloud descrive il data lineage come la mappa del ciclo di vita dei dati e lo collega all’uso in BigQuery e in Knowledge Catalog. (Google Cloud)

Questa guida resta volutamente circoscritta. Non promette copertura totale, non sostituisce il controllo delle query e non entra in temi diversi come policy tags, masking o freschezza delle dashboard. L’obiettivo è pratico: partire da un KPI, individuare la tabella sorgente e leggere il percorso dei dati fino a capire chi deve confermare semantica, trasformazioni e manutenzione.

Prerequisiti minimi prima di aprire il lineage

Prima di usare il lineage servono tre informazioni base:

Il nome del KPI o della metrica mostrata in dashboard.
La tabella BigQuery o la vista che alimenta quel numero.
Il team proprietario del dataset o della trasformazione, così da sapere chi può rispondere su logica e contenuto.

La documentazione Google Cloud indica che il lineage si consulta nel contesto di BigQuery e Knowledge Catalog e che non tutte le origini o trasformazioni sono coperte nello stesso modo. Per questo il controllo va trattato come verifica operativa, non come automatismo infallibile. (Google Cloud)

Procedura operativa: dal KPI alla sorgente

1) Identifica il punto di partenza

Prendi il KPI più importante della dashboard e annota:

nome della metrica;
filtro applicato;
periodo di aggregazione;
tabella o vista che la genera.

Se la dashboard non mostra il dettaglio tecnico, il lineage non sostituisce quel passaggio: lo completa solo dopo che il punto di partenza è stato identificato.

2) Apri la risorsa in BigQuery e controlla il lineage

La documentazione BigQuery indica che il lineage è accessibile direttamente dalla tabella nel prodotto e serve a vedere i collegamenti con gli oggetti a monte e a valle. (Google Cloud)

In questa fase non cercare subito la spiegazione perfetta: osserva prima la struttura del grafo, i nodi intermedi e le trasformazioni note.

3) Risali una tappa alla volta

Per ogni passaggio annota:

oggetto sorgente;
oggetto derivato;
tipo di trasformazione;
responsabile del dataset o della pipeline.

L’idea è ricostruire il percorso in modo leggibile, non dimostrare tutto in una sola schermata. Se il flusso si interrompe, il limite è già un risultato utile: può indicare una copertura non disponibile, una configurazione mancante o un percorso non tracciato dal prodotto. Google Cloud segnala infatti limiti di copertura e di configurazione nel modello di lineage descritto. (Google Cloud)

Esempio simulato: rinomina di una colonna e impatto a valle

Esempio simulato. Serve a mostrare il metodo, non descrive un caso reale specifico.

Immaginiamo una dashboard con il KPI conversion_rate, alimentato dalla tabella mart_marketing_daily.

A monte, una trasformazione legge stg_events.campaign_id per collegare gli eventi a una tabella campagne. In un giorno successivo, la colonna viene rinominata in ad_campaign_id e la query ETL viene aggiornata di conseguenza.

Cosa controllare con il lineage:

il KPI finale continua a puntare alla stessa vista o tabella derivata;
il nodo intermedio cambia nome o percorso;
la colonna finale mantiene la stessa semantica o introduce un nuovo significato;
il proprietario della pipeline conferma che la trasformazione è stata aggiornata insieme allo schema.

Output atteso dell’analisi simulata

Se il lineage mostra il nuovo flusso completo: la dashboard va verificata sul valore finale e sul filtro usato dal KPI.
Se il lineage si interrompe a metà: non si conclude che i dati siano sbagliati; si apre una verifica su copertura, permessi o configurazione.
Se il dettaglio richiesto non emerge chiaramente: si passa al controllo manuale della query e dello schema, con il team proprietario.

Proprietari e verifica: chi controlla cosa

Una buona pratica è separare responsabilità e controlli:

Team analytics o data platform: verifica il tracciato tecnico del KPI e il legame tra tabelle e viste.
Team che mantiene la trasformazione: conferma il significato delle colonne e delle regole di calcolo.
Chi usa la dashboard: controlla che il numero letto corrisponda alla domanda di business.

Checklist di accettazione

La verifica può dirsi sufficiente quando:

il KPI è collegato a una tabella o vista nota;
il percorso a monte è leggibile almeno fino al punto in cui il prodotto mostra lineage;
ogni salto ha un proprietario identificabile;
i limiti della copertura sono stati esplicitati, non ignorati.

Limiti da dichiarare senza ambiguità

Il lineage aiuta a spiegare il percorso dei dati, ma non certifica da solo la correttezza semantica del KPI. Se un valore sembra incoerente, la lettura del grafo va sempre affiancata alla revisione delle query e alla conferma del team responsabile. Inoltre, la documentazione Google Cloud distingue il tema del lineage da quello della semplice catalogazione: il fatto che una risorsa sia presente non significa che ogni dettaglio di trasformazione sia disponibile nello stesso modo. (Google Cloud)

Per questo motivo, la domanda giusta non è “il lineage mostra tutto?”, ma “il lineage mostra abbastanza per decidere il passo successivo in modo responsabile?”. Se la risposta è no, il passaggio successivo resta manuale.

Quando questa guida è utile davvero

Questa procedura serve soprattutto quando un team deve:

spiegare da dove arriva un KPI critico;
preparare una verifica prima di cambiare una colonna;
identificare rapidamente chi deve confermare una trasformazione;
distinguere una rottura del flusso da una semplice mancanza di copertura.

In sintesi, il lineage non sostituisce il governo del dato: lo rende più leggibile. E proprio per questo funziona meglio quando è usato come strumento di verifica, non come prova automatica di correttezza.