Guida di implementazione

Come implementare il data lineage: guida passo-passo

Dalla pianificazione alla produzione: pattern di architettura, cattura automatica, setup strumenti e best practice per Snowflake, BigQuery, dbt, Airflow e Looker.

25 min di letturaPer data & platform engineerCon esempi di codice

📚 Ti servono raccomandazioni sugli strumenti? Guarda il nostro confronto:

Migliori strumenti di data lineage (comparativa 2025)

1. Roadmap di implementazione in 8 passi

Implementare il data lineage è un progetto multi-fase: 1-3 mesi con tool moderni, 3-6 mesi con piattaforma enterprise. Segui questa roadmap per un roll-out senza sorprese.

1

Definire scope e obiettivi

Durata: 1-2 settimane

Allinea stakeholder e casi d’uso chiari. Così costruisci la soluzione giusta per l’organizzazione.

Azioni chiave
  • Mappa gli stakeholder: data engineer, analisti, compliance, business
  • Prioritizza i casi d’uso: compliance (GDPR/SOX), impatto, troubleshooting, documentazione
  • Definisci il perimetro: sistemi coperti (warehouse, ETL, BI), granularità (tabella vs colonna)
  • Metriche di successo: % copertura, tempo analisi impatto, adozione utenti
Casi d’uso tipici
  • Compliance: tracciare campi PII/sensibili per GDPR/CCPA
  • Analisi d’impatto: "Se cambio questa tabella, cosa si rompe?"
  • Root cause: "Perché questa dashboard è sbagliata?"
  • Migrazioni: capire dipendenze prima di migrare un sistema
  • Onboarding: aiutare i nuovi a capire i flussi
Suggerimento

Parti da un solo caso d’uso ad alto valore (compliance o impatto). Dimostra valore velocemente, poi estendi il perimetro.

2

Scegliere l’approccio

Durata: ~1 settimana

Buy, build o ibrido? Il trade-off principale è tempo, costo e manutenzione.

Buy: catalogo moderno

Strumenti: Atlan, Select Star, Metaphor

Costo: $20-80k/anno

Setup: 1-4 settimane

Ideale per: team mid-market (10-50 pers.) su stack moderno

Build: open source

Strumenti: OpenLineage, DataHub, Marquez

Costo: $0 software, $50-150k/anno di effort

Setup: 1-3 mesi

Ideale per: team con forte capacità engineering e bisogni custom

Ibrido: auto + manuale

Strumenti: Atlan/DataHub + Datadef

Costo: $20-80k/anno + $0-30k

Setup: 2-6 settimane

Ideale per: combinare precisione runtime + documentazione di design

Griglia decisionale

Scegli un catalogo moderno se vuoi andare veloce e hai budget. Scegli open source se vuoi indipendenza e hai dev disponibili. Scegli ibrido se ti serve precisione runtime + documentazione architetturale.

Consulta il nostro confronto completo per i dettagli.

3

Disegnare l’architettura lineage

Durata: 1-2 settimane

Progetta come raccogliere, salvare ed esporre i metadati. Vedi la sezione Pattern architetturali per i dettagli.

Decisioni chiave
  • Storage: Graph DB (Neo4j), relazionale (Postgres) o catalogo gestito
  • Ingestion: Pull schedulato vs Push event-driven (OpenLineage)
  • Granularità: livello tabella (più semplice) vs colonna (più preciso)
  • Visualizzazione: Web UI vs embedded (BI, notebook)
4

Attivare la cattura automatica

Durata: 2-4 settimane

Implementa le tre tecniche: parsing log SQL, estrazione via API, ingestion dei manifest. Vedi Cattura automatica.

1. Parsing dei log

Estrai SQL dai log Snowflake/BigQuery/Redshift per inferire dipendenze

2. API metadati

Recupera lineage dagli strumenti BI via REST/GraphQL

3. Ingestion manifest

Parsa manifest.json dbt e i DAG Airflow

5

Integrare nello stack dati

Durata: 2-4 settimane

Collega tutti i sistemi. È la parte più lunga perché ogni tool ha API e auth proprie.

Data warehouse

Snowflake, BigQuery, Redshift, Databricks — accesso ai log via JDBC/ODBC

Trasformazione

dbt (manifest.json), Airflow (parsing DAG), Spark (listener OpenLineage)

BI & Analytics

Looker (API LookML), Tableau (Metadata API), Power BI (REST)

Suggerimento: parti dal sistema più critico (spesso il warehouse) e valida la precisione prima di aggiungere altre integrazioni. Vedi Integrazioni per gli step dettagliati.

6

Validare e testare

Durata: 1-2 settimane

Testa la precisione del lineage end-to-end. Correggi i gap prima del roll-out.

Checklist di validazione
  • Tracce end-to-end: traccia 5-10 dashboard critiche fino alle sorgenti
  • Precisione a livello colonna: verifica ricavi, ID cliente
  • Connessioni mancanti: ETL legacy, file Excel/CSV, script
  • Freschezza: il lineage si aggiorna dopo un cambio schema?
  • Performance: regge 1000+ nodi?

Problemi comuni

  • • SQL dinamico difficile da parsare
  • • Lineage cross-database mancante
  • • Sorgenti esterne/API non catturate
  • • Import manuali Excel/CSV non tracciati
7

Attivare i workflow di governance

Durata: 1-3 settimane

Collega il lineage ai casi d’uso business. Qui nasce il valore.

Compliance
  • Propagazione PII: tagga i campi sensibili e propaga a valle
  • Diritto all’oblio: trova tutte le copie dei dati cliente
  • Classificazione: eredita i label di sensibilità via lineage
Operazioni
  • Analisi d’impatto: vedere quali dashboard si romperanno prima di un cambio schema
  • Gestione incidenti: risalire alla causa di un incidente di data quality
  • Ottimizzazione costi: identificare tabelle/view poco usate
8

Deploy e formazione utenti

Durata: 2-4 settimane (continuo)

Il lineage genera valore solo se viene usato. Guida l’adozione attivamente.

Piano di adozione
1
Pilota con power user: 5-10 data engineer/analisti al lancio
2
Scrivi documentazione: guide per impatto, PII, troubleshooting
3
Forma per ruolo: workshop 1h per engineer, analisti, business
4
Rendi obbligatoria l’analisi d’impatto: chiedi il lineage prima di ogni modifica schema
5
Misura l’adozione: utenti attivi mensili, query lineage, uso feature
Metriche di successo

Monitora: Weekly active users (target 50%+ del team data), tempo analisi impatto (prima vs dopo lineage), incidenti evitati (cambi bloccati prima della prod), richieste compliance risolte (localizzazione PII).

2. Buy vs Build vs Ibrido

Prima decisione strutturante: comprare, costruire o mixare. Ogni opzione ha compromessi di costo, tempo e flessibilità.

ApproccioStrumentiCostoTempoEffortIdeale per
Buy: catalogo modernoAtlan, Select Star, Metaphor$20-80k/anno1-4 settimaneBassoTime-to-value rapido, stack moderno
Buy: piattaforma enterpriseInformatica, Collibra$100-500k/anno3-6 mesiMedioScala enterprise, governance forte
Build: open sourceDataHub, OpenLineage + Marquez$0 licenza, $50-150k/anno di effort1-3 mesiAltoTeam eng forte, bisogno di custom
Ibrido: auto + manualeAtlan + Datadef$20-110k/anno2-6 settimaneBasso-medioPrecisione runtime + doc di architettura

Buy: catalogo moderno

Vantaggi

  • • Time-to-value velocissimo
  • • Lineage auto dal giorno 1
  • • UX moderna amata dagli analisti
  • • Zero DevOps

Svantaggi

  • • Costo ricorrente
  • • Vendor lock-in
  • • Meno spazio per custom

Build: open source

Vantaggi

  • • Nessuna licenza
  • • Controllo totale e custom
  • • Indipendenza dal fornitore
  • • Supporto community

Svantaggi

  • • Effort engineering alto
  • • Manutenzione continua
  • • Evoluzioni più lente

Ibrido: best of both

Vantaggi

  • • Precisione runtime automatizzata
  • • Documentazione di intenzione/design
  • • Setup rapido + flessibilità
  • • Copre i buchi (future state, API esterne)

Svantaggi

  • • Due tool da operare
  • • Costo totale più alto
  • • Rischio di duplicati

La nostra raccomandazione

Per la maggior parte dei team: parti con un catalogo cloud moderno (Atlan o Select Star) per andare veloce. Aggiungi Datadef per documentare l’architettura e l’intento di design che i tool auto non catturano.

Per team con tempo e risorse eng: costruisci su OpenLineage + DataHub per indipendenza e custom. Prevedi 2-3 mesi di setup.

3. Pattern di architettura del lineage

Un’architettura tipica ha tre layer: sorgenti (cosa catturi), storage (dove vive il lineage) e visualizzazione (come lo consumano gli utenti).

Architettura tipo

Layer 1: Sorgenti (estrazione)

Warehouse

Log di query Snowflake, BigQuery, Redshift

ETL/ELT

Manifest dbt, DAG Airflow, lineage Spark

Strumenti BI

API Looker, API metadati Tableau

Pipeline di ingestion

Layer 2: Storage metadati (processing)

Graph DB

Neo4j per query su relazioni

DB relazionale

Postgres per metadati strutturati

Catalogo gestito

Backend SaaS (Atlan, Collibra)

API / GraphQL

Layer 3: Visualizzazione (consumo)

Web UI

Interfaccia catalogo per navigare

Embedded

Lineage incorporato in BI/notebook

Accesso API

Query programmatiche per automazione

Opzioni di storage

Graph DB (Neo4j, Amazon Neptune)

Ideale per query su relazioni complesse

✓ Pro: query rapide, modello naturale per il lineage

✗ Contro: gestione più complessa, skill meno diffuse

DB relazionale (Postgres, MySQL)

Ottimo per metadati strutturati e semplici

✓ Pro: noto, facile da interrogare, tooling standard

✗ Contro: query multi-hop lente

Catalogo gestito (SaaS)

Lo strumento gestisce storage e ottimizzazione

✓ Pro: zero manutenzione, ottimizzato per scala

✗ Contro: lock-in, nessun accesso diretto al DB

Pattern di ingestion

Pull (estrazione schedulata)

Job periodici che estraggono i metadati

• Frequenza: ogni 1-24h via cron/Airflow

• Ideale per: sistemi batch, BI, warehouse

• Latenza: minuti-ore

Push (event-driven)

I sistemi emettono eventi di lineage in tempo reale

• Metodo: eventi OpenLineage via Kafka/HTTP

• Ideale per: streaming, Spark, Airflow

• Latenza: secondi

Ibrido (entrambi)

Push per i pipeline, pull per BI/warehouse

• Combina tempo reale + copertura ampia

4. Metodi di cattura automatica

Tre metodi principali: parsing log SQL, API metadati e ingestion manifest. I tool moderni combinano tutti e tre.

Metodo 1: parsing dei log (warehouse)

Si estraggono le query dai log del warehouse, si parsano per trovare sorgenti e destinazioni e si costruisce il grafo. È il metodo più potente per il layer warehouse.

Come funziona

  1. 1. Connessione ai log di audit
  2. 2. Estrazione delle query SQL
  3. 3. Parsing per trovare tabelle sorgente/target
  4. 4. Costruzione del grafo

Vantaggi

  • • Cattura il runtime reale
  • • Nessun cambio di codice
  • • Precisione a livello colonna possibile
  • • Copre anche l’ad hoc

Limiti

  • • SQL complesso da parsare
  • • SQL dinamico talvolta mancante
  • • Solo storico (non predittivo)
  • • Richiede accesso ai log

Warehouse supportati

✅ Snowflake

Query via: SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY

Livello colonna: ✅ (via ACCESS_HISTORY)

✅ BigQuery

Query via: INFORMATION_SCHEMA.JOBS

Livello colonna: ✅ (con parsing)

✅ Redshift

Query via: STL_QUERY, STV_STATEMENTTEXT

Livello colonna: ⚠️ (limitato)

✅ Databricks

Query via: system.access.audit

Livello colonna: ✅ (Unity Catalog)

Esempio: accesso ai log Snowflake
-- Estrarre il lineage dai log Snowflake
SELECT 
  query_text,
  start_time,
  user_name,
  database_name,
  schema_name,
  tables_scanned,
  tables_modified
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND query_type IN ('SELECT', 'INSERT', 'MERGE', 'CREATE_TABLE_AS_SELECT')
ORDER BY start_time DESC;

Metodo 2: API metadati (BI)

Gli strumenti BI e gli orchestratori espongono API REST/GraphQL per recuperare dashboard, report e sorgenti. Così copri il layer di consumo.

Looker

LookML API + Metadata API

Estrae: explores, views, fields, dashboard

Tableau

Metadata API (GraphQL)

Estrae: workbooks, datasource, colonne

Power BI

REST API + Scanner API

Estrae: report, dataset, dataflow

Esempio: estrazione Looker
# Python: estrarre lineage Looker via SDK
import looker_sdk

sdk = looker_sdk.init40()

# Tutti i dashboard
dashboards = sdk.all_dashboards(fields="id,title")

for dashboard in dashboards:
    elements = sdk.dashboard_dashboard_elements(dashboard.id)
    
    for element in elements:
        if element.query:
            query = sdk.query(element.query.id)
            # Estrai tabelle sorgente dalla query
            print(f"Dashboard: {dashboard.title}")
            print(f"  Tables: {query.view}, {query.model}")

Metodo 3: ingestion del manifest (dbt, Airflow)

dbt e Airflow generano metadati (manifest, DAG) che descrivono le trasformazioni. Parsandoli ottieni un lineage di trasformazione perfetto.

Manifest dbt

dbt genera manifest.json con tutti i modelli, sorgenti, test e dipendenze.

✓ Lineage a livello colonna integrato

✓ Metadati dei test inclusi

✓ Descrizioni catturate

✓ DAG accurato

DAG Airflow

Parsa i file Python dei DAG per estrarre dipendenze e flussi.

✓ Dipendenze tra task

✓ Tipi di operatori

✓ Info di schedule

✓ Eventi OpenLineage sui run

Esempio: parsing del manifest dbt
# Python: parsare il manifest.json di dbt per il lineage
import json

with open('target/manifest.json') as f:
    manifest = json.load(f)

for node_id, node in manifest['nodes'].items():
    if node['resource_type'] == 'model':
        print(f"Model: {node['name']}")
        print(f"  Depends on: {node['depends_on']['nodes']}")
        
        # Lineage a livello colonna
        for col_name, col_info in node['columns'].items():
            print(f"    Column: {col_name}")
            if 'meta' in col_info and 'upstream' in col_info['meta']:
                print(f"      From: {col_info['meta']['upstream']}")

5. Esempi di integrazione

Passi concreti per collegare i principali strumenti dello stack moderno.

Integrazione Snowflake (query log)

Passi

  1. 1
    Dai accesso a ACCOUNT_USAGE
    GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE lineage_role;
  2. 2
    Interroga QUERY_HISTORY
    SELECT query_text, database_name, schema_name
    FROM snowflake.account_usage.query_history
    WHERE query_type IN ('SELECT', 'INSERT', 'MERGE')
  3. 3
    Opzione: ACCESS_HISTORY per livello colonna
    SELECT * FROM snowflake.account_usage.access_history
    WHERE query_start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP());

Tip: ACCESS_HISTORY dà precisione colonna ma richiede edizione Enterprise. I log da soli danno il livello tabella su tutte le edizioni.

Integrazione del manifest dbt

Passi

  1. 1
    Genera il manifest dopo dbt run
    dbt run
    # Genera target/manifest.json automaticamente
  2. 2
    Carica il manifest nel tool di lineage
    # Upload verso API del catalogo
    curl -X POST https://catalog.example.com/api/dbt/manifest   -H "Authorization: Bearer $API_KEY"   --data-binary @target/manifest.json
  3. 3
    Automatizza in CI/CD

    Aggiungi l’upload del manifest al deploy dbt

Best practice: la maggior parte dei cataloghi (Atlan, Select Star, DataHub) ha integrazioni dbt native. Usa i loro plugin invece di script custom.

OpenLineage + Airflow

Passi

  1. 1
    Installa il plugin OpenLineage Airflow
    pip install openlineage-airflow
  2. 2
    Configura il backend in airflow.cfg
    [openlineage]
    transport = http://marquez-api:5000
    namespace = prod-data-pipelines
  3. 3
    Lineage emesso automaticamente in esecuzione

    Nessun cambio codice nei DAG: gli eventi partono via OpenLineage

Operator supportati: SQLExecuteQueryOperator, PythonOperator, BigQueryOperator, SnowflakeOperator, ecc.

Vedi la documentazione OpenLineage per la lista completa.

6. Esempi di codice

Esempio: script Python per il lineage Snowflake

import snowflake.connector
import json
from collections import defaultdict

conn = snowflake.connector.connect(
    account='YOUR_ACCOUNT',
    user='YOUR_USER',
    password='YOUR_PASSWORD',
    warehouse='COMPUTE_WH',
    database='SNOWFLAKE',
    schema='ACCOUNT_USAGE'
)

query = """
SELECT 
    query_id,
    query_text,
    database_name,
    schema_name,
    user_name,
    start_time
FROM snowflake.account_usage.query_history
WHERE query_type IN ('INSERT', 'MERGE', 'CREATE_TABLE_AS_SELECT')
  AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC
LIMIT 1000;
"""

cursor = conn.cursor()
cursor.execute(query)

lineage_graph = defaultdict(list)

for row in cursor:
    query_id, query_text, db, schema, user, timestamp = row
    
    if 'INSERT INTO' in query_text.upper():
        target = extract_table_name(query_text, 'INSERT INTO')
        sources = extract_table_names(query_text, ['FROM', 'JOIN'])
        
        for source in sources:
            lineage_graph[source].append({
                'target': target,
                'query_id': query_id,
                'user': user,
                'timestamp': str(timestamp)
            })

with open('lineage_output.json', 'w') as f:
    json.dump(dict(lineage_graph), f, indent=2)

print(f"Estratto lineage per {len(lineage_graph)} tabelle sorgente")
conn.close()

Esempio: DAG Airflow per estrarre il lineage

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta
import requests

def extract_snowflake_lineage():
    """Estrai il lineage da Snowflake e invia al catalogo"""
    lineage_data = get_snowflake_lineage()
    
    response = requests.post(
        'https://catalog.example.com/api/lineage',
        headers={'Authorization': f'Bearer {CATALOG_API_KEY}'},
        json=lineage_data
    )
    response.raise_for_status()
    print(f"Caricate {len(lineage_data)} relazioni di lineage")

def extract_dbt_lineage():
    """Parsa il manifest dbt e carica"""
    with open('/dbt/target/manifest.json') as f:
        manifest = json.load(f)
    
    response = requests.post(
        'https://catalog.example.com/api/dbt/manifest',
        headers={'Authorization': f'Bearer {CATALOG_API_KEY}'},
        json=manifest
    )
    response.raise_for_status()

default_args = {
    'owner': 'data-platform',
    'depends_on_past': False,
    'start_date': datetime(2025, 1, 1),
    'email_on_failure': True,
    'retries': 2,
    'retry_delay': timedelta(minutes=5),
}

with DAG(
    'lineage_extraction',
    default_args=default_args,
    description='Estrazione giornaliera metadati di lineage',
    schedule_interval='@daily',
    catchup=False,
) as dag:

    extract_snowflake = PythonOperator(
        task_id='extract_snowflake_lineage',
        python_callable=extract_snowflake_lineage,
    )

    extract_dbt = PythonOperator(
        task_id='extract_dbt_lineage',
        python_callable=extract_dbt_lineage,
    )

    extract_snowflake >> extract_dbt

7. FAQ

Come implementare il data lineage?

1) Scope + obiettivi, 2) strumenti (catalogo, open source, manuale), 3) architettura (storage, ingestion, visualizzazione), 4) cattura auto (log, API, manifest), 5) integrazione nello stack (warehouse, ETL, BI), 6) validazione, 7) governance, 8) formazione. Tempo: 1-3 mesi con tool moderni, 3-6 mesi con piattaforma enterprise.

Qual è il modo migliore per automatizzare?

1) Parsing log SQL (Snowflake, BigQuery, Redshift), 2) API metadati (Looker, Tableau), 3) manifest dbt, 4) OpenLineage per Airflow/Spark. Atlan o Select Star automatizzano questi metodi.

Quanto tempo serve?

Cataloghi cloud: 1-4 settimane. Piattaforme enterprise: 2-6 mesi. Open source: 1-3 mesi. Strumenti visuali (Datadef): immediato ma manutenzione manuale.

Quali strumenti servono?

1) Piattaforma lineage (Atlan, Collibra, DataHub), 2) estrattori per il tuo stack (dbt, Airflow, Looker/Tableau), 3) accesso ai log SQL (ACCOUNT_USAGE, INFORMATION_SCHEMA), 4) orchestrazione per refresh, 5) opzione: OpenLineage e documentazione visuale (Datadef).

Passa all’azione

Risparmia settimane di setup e genera diagrammi di lineage professionali in pochi minuti con l’IA.