import pandas as pd

Schema evolution e gestione dei cambiamenti

Una colonna cambia nome, una tabella riceve nuovi stati, un sistema sorgente smette di inviare un campo. Quando succede, il warehouse deve evolvere senza rompere dashboard, job e analisi storiche. La schema evolution tratta questo cambiamento come un processo governato e non come una sorpresa da correggere quando qualcosa si è già rotto in produzione. Il punto della lezione non è accumulare definizioni, ma capire quale decisione cambia quando lo schema deve muoversi.

Il problema concreto

Lo schema di un warehouse non è mai un oggetto isolato. Sopra di esso vivono dashboard, query salvate, modelli statistici e job ETL che si aspettano colonne con un certo nome, un certo tipo e un certo significato. Modificare quello schema vuol dire toccare un contratto implicito con tutti questi consumer.

La difficoltà non è sapere che cosa sia uno schema. È decidere cosa fare quando devi cambiarlo e non hai una mappa completa di chi dipende da quel campo. Una colonna che ti sembra inutile potrebbe alimentare il report mensile di un altro team. Per questo uno schema può cambiare in sicurezza solo quando sai chi lo usa e quale contratto non deve essere violato.

Come ragionare prima di toccare lo schema

Prima di modificare una tabella conviene rispondere a poche domande in sequenza. Quale decisione operativa stai cercando di abilitare con il cambiamento? Quali consumer downstream sono impattati? Esiste una versione del cambiamento che resta retrocompatibile? E se non esiste, qual è il piano di migrazione e in quanto tempo si chiude la finestra di transizione?

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se modifico lo schema in questo modo?	Scelta esplicita
Segnale	Quali consumer e quali job toccano questo campo?	Mappa di lineage
Baseline	Lo stato attuale funziona per tutti i consumer?	Confronto credibile
Vincolo	Che cosa si rompe se il cambiamento non è retrocompatibile?	Assunzione da dichiarare
Azione	Quale passo di migrazione segue, e con quale rollback?	Piano controllabile

Ogni passaggio serve a rendere visibile il costo di una modifica sbagliata, così che la discussione avvenga prima del deploy e non dopo la chiamata di un collega che vede la dashboard a zero.

Rendere espliciti contratto e rischio

Conviene trattare lo schema come un contratto scritto, non come una convenzione che ognuno interpreta a modo suo. Definisci l’unità su cui ragioni, che può essere una tabella, una fact, una dimensione o un intero modello dati. Collega quell’unità a un segnale osservabile come il grain corretto, l’integrità referenziale, le performance o il costo delle query. Infine dichiara quale decisione architetturale stai prendendo: nuovo schema, nuovo mart, nuovo query pattern.

Elemento	Specifica richiesta
Unità di analisi	tabella, fact, dimensione, grain o modello dati
Segnale principale	grain corretto, integrità, performance, costo query, tracciabilità
Baseline	versione attuale dello schema e consumer che ne dipendono
Decisione	schema, mart, query pattern o scelta architetturale
Rischio	rompere un consumer che non sapevi esistesse

Una formalizzazione di questo tipo non complica il lavoro. Rende discutibile il criterio, così uno stakeholder può contestare l’assunzione invece di scoprire il problema quando la pipeline è già rossa.

Strategie di evoluzione

Tre approcci coprono la maggior parte dei casi reali.

Il primo è l’additive-only, il più sicuro. Aggiungi colonne, non ne rimuovi mai. Le colonne vecchie restano, eventualmente deprecate con un commento. I nuovi consumer vedono la nuova colonna, i vecchi la ignorano senza accorgersi di nulla. Funziona in Snowflake, BigQuery e Postgres.

Il secondo è la view intermedia. Invece di esporre la tabella fisica, esponi una view. Quando migri lo schema sottostante, aggiorni la view in modo che i consumer continuino a vedere le stesse colonne con gli stessi nomi. La view diventa il contratto stabile e la tabella fisica può cambiare sotto di essa.

Il terzo è il versionamento esplicito, con tabelle del tipo orders_v1 e orders_v2. I consumer migrano alla nuova versione quando sono pronti e le due versioni coesistono per un periodo di transizione. È l’approccio più complesso, ma diventa necessario quando hai molti consumer indipendenti che non puoi coordinare in un solo deploy.

Contratti e test automatici

Con i dbt model contracts, coperti nel modulo di analytics engineering, puoi bloccare in fase di build ogni modifica che violi lo schema atteso. Il vantaggio è che sposti la rottura dal runtime al build time: invece di scoprire il problema da una dashboard muta, lo vedi come una CI rossa che impedisce il deploy e ti costringe a correggere prima.

Prima di un cambio di schema vale la pena passare da una checklist concreta. Sono i consumer downstream a essere impattati, e li hai controllati sul lineage graph? La modifica è retrocompatibile per tutti? Se non lo è, esiste un piano di migrazione con finestra di transizione? I test automatici coprono il nuovo schema? E infine, se qualcosa si rompe in produzione, esiste un rollback plan già pronto?

-- esempio di model contract dbt (semplificato)
-- la build fallisce se la colonna manca o cambia tipo
models:
  - name: orders
    config:
      contract:
        enforced: true
    columns:
      - name: order_id
        data_type: integer
      - name: status
        data_type: varchar

Lo schema come parte di un sistema

In un progetto reale la schema evolution non vive isolata. È parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio di chi è alle prime armi è trattare il tema come una definizione da memorizzare. Il lavoro professionale è diverso: serve capire quale problema risolve il cambiamento, quali assunzioni contiene e cosa succede quando quelle assunzioni saltano.

Nel data warehousing la prima domanda non è “quale metrica calcolo?” ma “quale decisione dovrà essere presa grazie a questa struttura dati?”. Una dashboard o una query hanno valore solo se riducono l’incertezza di una scelta. Se non cambiano nessuna decisione, sono documentazione. Un buon modo per impostare il lavoro è definire il problema in linguaggio business, identificare l’unità di analisi corretta (utente, account, evento, sessione, ordine), controllare se i dati misurano davvero il fenomeno, costruire una metrica interpretabile, segmentare per non far nascondere alla media pattern opposti e infine trasformare il risultato in una raccomandazione verificabile.

Caso reale: Netflix e la disciplina delle metriche

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è che ogni azienda debba copiare Netflix, ma che lì il dato non è un ornamento, è infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Guarda anche segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare. Questa disciplina evita di ottimizzare vanity metric che sembrano positive nel breve ma distruggono valore nel lungo periodo. Lo stesso principio vale qui: una modifica allo schema deve essere collegata a un outcome. Se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. L’obiettivo è creare una base analitica con metrica, segmento e finestra temporale, così da poter confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

Questa query non pretende di essere la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui l’analista può formulare ipotesi più precise, e quando lo schema cambia è proprio questa superficie a dirti subito se qualcosa si è incrinato.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python possiamo controllare le variazioni anomale settimana su settimana, un controllo che vale doppio subito dopo una migrazione di schema.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il valore di questo controllo è pratico: evita di reagire a ogni oscillazione casuale, ma segnala quando una variazione merita un’indagine. In un contesto aziendale alimenta alert, review settimanali e retrospettive di prodotto.

Errori comuni da evitare

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e definizioni cambiate producono conclusioni false, e una migrazione di schema è esattamente il momento in cui le definizioni cambiano. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa che la feature causi la conversione, perché potrebbero usarla proprio perché sono già più motivati.

Per ridurre questi rischi ogni analisi dovrebbe includere almeno una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo. C’è anche un errore più sottile, quello di usare la schema evolution come etichetta tecnica invece che come criterio di scelta: succede quando si presenta un cambiamento senza dire quale decisione abilita e quale consumer protegge.

Riepilogo

La schema evolution va trattata come uno strumento decisionale e non come un argomento da manuale. Il valore nasce quando colleghi il cambiamento di struttura ai consumer che dipendono da essa, alla strategia di compatibilità che scegli e ai controlli che ti dicono se qualcosa si è rotto. Una buona gestione del cambiamento non finisce con “abbiamo aggiornato la tabella”. Finisce con una frase operativa: cosa cambia per i consumer, con quale finestra di transizione, e quale controllo useremo per sapere se la migrazione è andata bene. Decisione, segnale, baseline, rischio e azione restano la forma corretta del lavoro; tutto il resto serve solo se rende più affidabile uno di questi passaggi.