import pandas as pd

Data warehousing moderno: architettura e concetti

Un data warehouse moderno non è un deposito ordinato di tabelle. È il luogo in cui dati operativi, definizioni di business e performance analitica diventano un servizio condiviso. Quando questa architettura è confusa, ogni team costruisce la propria verità e i numeri smettono di tornare. Questa lezione chiarisce la base prima della modellazione, e tratta il tema come una serie di scelte operative invece che come un elenco di definizioni.

Quando il problema diventa concreto

Il problema non è conoscere il data warehousing in astratto, ma decidere cosa fare quando i dati arrivano da fonti diverse, quando due dashboard danno numeri diversi per la stessa metrica o quando una query che ieri funzionava oggi costa troppo. Conviene leggere l’architettura distinguendo sistemi transazionali, lake, warehouse, mart e semantic layer. Ogni livello deve avere un motivo, che sia conservare, trasformare, servire o governare. Un warehouse affidabile semplifica le domande difficili perché rende espliciti grain, ownership e contratti.

Come ragionare sulla scelta

La sequenza utile parte dalla decisione e finisce con un controllo. Prima chiarisci cosa cambia se l’architettura migliora, poi quale segnale osservabile riduce l’incertezza, rispetto a quale baseline leggi il risultato, cosa può falsare la lettura e infine quale passo operativo segue.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se l’architettura del warehouse è più chiara?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

Ogni passaggio rende più chiaro il costo di una decisione architetturale sbagliata, che di solito si paga quando il sistema deve scalare.

OLTP e OLAP

La prima distinzione da avere chiara è tra database transazionali e analitici, perché servono mondi diversi.

	OLTP (Database transazionale)	OLAP (Data Warehouse)
Missione	Gestire operazioni in tempo reale	Supportare analisi e decisioni
Query	Poche righe, semplici (SELECT by ID)	Molte righe, complesse (GROUP BY, JOIN)
Schema	Normale (3NF), senza duplicati	Denormalizzato (star schema), ottimizzato per lettura
Esempi	PostgreSQL, MySQL per app	Snowflake, BigQuery, Redshift
Utenti	Applicazioni	Analyst, BI tools

Star schema secondo Kimball

Il modello dimensionale di Kimball è il gold standard da 30 anni e poggia su due tipi di tabelle. La fact table contiene misure numeriche e foreign key, con una riga per evento: per esempio sales_fact con amount, quantity, date_key, customer_key. La dimension table contiene attributi descrittivi, con una riga per entità: per esempio dim_customer con name, country, segment. Il vantaggio è che il modello è semplice da capire e veloce da interrogare, perché le dimensioni sono piccole e i fatti sono grandi ma ben indicizzati, ed è compatibile con ogni BI tool.

Snowflake, BigQuery, Redshift

Le tre piattaforme dominanti hanno architetture diverse, e la scelta dipende da dove sei già e da quanto sono prevedibili i tuoi workload.

	Snowflake	BigQuery	Redshift
Architettura	Disaccoppiato storage/compute	Serverless, shared nothing	Cluster MPP
Scalabilità	Warehouse size configurabile	Automatica, slot-based	Aggiungi nodi al cluster
Semi-structured	Eccellente (VARIANT)	Buono (JSON)	Buono (SUPER)
Costo	Crediti compute + storage	$5/TB scanned (on-demand) o slot	Nodo/ora

Per un team dati moderno Snowflake e BigQuery sono le scelte dominanti. Redshift resta valido per chi è già in AWS e ha workload prevedibili.

Il modello di maturità del warehouse

Un warehouse cresce per stadi. Al primo stadio c’è il raw data dump, copie grezze delle tabelle operative: l’ingestion è facile ma le query sono impossibili. Al secondo stadio arriva lo star schema, con fatti e dimensioni modellati: le query sono veloci ma richiedono ETL. Al terzo stadio si passa a data vault o data mesh, una modellazione per organizzazioni grandi con decine di team indipendenti, dove ogni team possiede i propri dati e li espone tramite contratti.

Leggere l’architettura come sistema

In un progetto reale il warehouse non vive isolato. Fa parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista alle prime armi è trattare il tema come una definizione: imparare il nome, ricordare due regole, applicare un template. Il lavoro professionale è diverso, perché bisogna capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni non valgono.

La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico. Un buon modo per impostare il lavoro è definire il problema in linguaggio business, identificare l’unità di analisi corretta tra utente, account, evento, sessione, ordine o campagna, controllare se i dati misurano davvero il fenomeno o solo una sua ombra, costruire una metrica interpretabile, segmentare per evitare che la media nasconda pattern opposti e trasformare il risultato in una raccomandazione verificabile.

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 il dato non viene trattato come ornamento, bensì come 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. Misura anche segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma distruggono valore nel lungo. Lo stesso vale per l’architettura del warehouse, che deve essere collegata a un outcome: se non aiuta a scegliere tra due azioni alternative, è incompleta.

Esempio SQL: una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea 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.

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 variazioni anomale settimana su settimana.

# 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 azienda questo tipo di analisi alimenta alert, review settimanali e retrospettive di prodotto.

Esercizio

Al livello base scrivi una scheda di una pagina sul warehouse che stai progettando: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale è confermato. Al livello intermedio costruisci una tabella con tre segmenti, periodi o scenari, e per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione. Al livello research-grade prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio.

Per i dati usa warehouse, SQL, modelli dimensionali, dati ordini, eventi e tabelle anagrafiche. Se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome. Un caso pratico realistico è consolidare dati da app, billing e CRM in un’unica base analitica: la decisione architetturale riguarda layer, responsabilità, refresh, qualità e accesso, perché se questi punti restano impliciti il warehouse diventa solo un nuovo posto dove duplicare confusione.

L’errore tipico

L’errore più comune è usare l’architettura come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza indicare quale assunzione potrebbe invalidarla. La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Tre errori di analisi ricorrono spesso. Il primo è 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 cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità, perché se gli utenti che usano una feature convertono di più non significa che la feature causi conversione. Per ridurre questi rischi ogni analisi dovrebbe includere una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Riepilogo

Il data warehousing va trattato come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando i livelli dell’architettura, dai sistemi transazionali al semantic layer, hanno ciascuno un motivo chiaro. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza, e quale metrica useremo per sapere se avevamo ragione.