import pandas as pd

Modern data infrastructure: fundamentals

Un team dati moderno non gestisce solo query e dashboard. Gestisce storage, compute, orchestrazione, accessi, costi, deploy e incidenti. Quando una pipeline critica fallisce, la domanda che conta non è “chi ha sbagliato?”, ma quale parte dell’infrastruttura era priva di owner, di controllo o di fallback. Questa lezione costruisce la mappa che permette di rispondere, trattando l’infrastruttura come una serie di scelte operative invece che come un elenco di tecnologie da memorizzare.

Il problema da risolvere

Conoscere l’infrastruttura dati in astratto non serve. Serve sapere cosa decidere quando hai vincoli tecnici, costi che crescono e responsabilità poco chiare. Una lezione utile separa il segnale dal rumore: dice quale baseline usare, quale controllo eseguire e quale azione diventa difendibile dopo aver guardato il sistema nel suo insieme.

Conviene leggere il tema come una review di responsabilità. Quali componenti sono gestiti da un fornitore e quali sono self-hosted, quali SLA contano davvero e quali decisioni operative restano senza un owner. L’infrastruttura è buona quando rende affidabile il lavoro dei team senza nascondere costi e rischi sotto il tappeto.

Come ragionare sulla decisione

Conviene leggere ogni scelta come una sequenza che collega decisione, evidenza e rischio. La tabella sotto funziona da mappa di lavoro e impedisce che una scelta tecnica diventi un rituale vuoto.

Step	Question to ask	Expected output
Decision	Che cosa cambia se progettiamo meglio l’infrastruttura?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Ogni riga deve rendere piu chiaro il costo di una decisione sbagliata. Se un passaggio non incide su una scelta concreta, diventa documentazione o teatro analitico.

Formalizzare unita, segnale e decisione

Per analizzare l’infrastruttura conviene fissare prima l’unita di lavoro, poi il segnale, poi la decisione attesa. L’unita di analisi qui è il job, la pipeline, il servizio, l’alert, il deploy o la risorsa cloud. Il segnale principale è SLA, MTTR, costo, failure rate, freshness o qualità dei dati. La decisione attesa è un runbook, un alert, una policy di costo, una configurazione CI/CD o un piano di recovery.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui misuri il fenomeno	job, pipeline, service, alert, deploy, or cloud resource
Variabile osservata	Segnale che rappresenta il comportamento	SLA, MTTR, costo, failure rate, freshness, qualità dati
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Mistaking an available number for sufficient proof

La formalizzazione non complica la lezione. Rende visibili le assunzioni, così un altro analista può riprodurre la logica, criticare le ipotesi e arrivare alla stessa decisione partendo dagli stessi dati.

The managed-first principle

Prima di costruire qualcosa in casa conviene farsi tre domande. Esiste un servizio gestito che fa questa cosa, e con quale SLA? Il costo del servizio è inferiore al costo delle persone necessarie per mantenerlo? La flessibilità che perdi affidandoti al fornitore è davvero rilevante per il business? Nell’ottanta per cento dei casi il servizio gestito vince, perché l’infrastruttura dati non è il core business, a meno che tu non sia Snowflake o Databricks.

The pillars of data infrastructure

Pillar	What it does	Common choices
Storage	Where data lives	S3/GCS as data lake, Snowflake/BigQuery as warehouse
Compute	How data is processed	Warehouse compute (Snowflake virtual warehouses), Spark (Databricks/EMR), serverless (BigQuery)
Ingestion	How data enters	Managed ELT (Fivetran, Airbyte), CDC (Debezium), streaming (Kafka)
Orchestration	Who coordinates pipelines	Airflow, Prefect, Dagster, dbt Cloud scheduler
Transformation	How data is modeled	dbt, SQL, Spark
Monitoring	How do you know if something is broken	Monte Carlo, Elementary, dbt tests, Grafana alerting
Governance	Who can access what	AWS Lake Formation, Immuta, dbt metadata

The cost model

L’infrastruttura dati ha quattro componenti di costo, in ordine tipico di grandezza. Le persone pesano per il 60-70%: data engineer, analytics engineer, devops. È il costo più grande e il più difficile da ridurre senza perdere capacità. Il warehouse compute vale il 15-20%: Snowflake credits o BigQuery slots, cresce col volume delle query ed è ottimizzabile con modelli incremental e materialized view. I tool SaaS, come Fivetran, dbt Cloud, Monte Carlo e Tableau, occupano il 10-15% con costi fissi prevedibili. Lo storage, infine, sta sul 5-10%: S3 e lo storage di Snowflake sono la voce più economica, quasi trascurabile su scala media.

Esempio: centralizzare o lasciare autonomia

Un team deve scegliere se centralizzare warehouse, orchestrazione e monitoring oppure lasciare a ogni squadra i propri tool. La decisione mette a confronto autonomia, costo operativo, compliance e velocità di diagnosi quando qualcosa si rompe. La tabella sotto mostra come leggere alcune evidenze tipiche.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Look for comparison and segment
One segment changes more than others	The aggregated average hides a difference	Separate cohorts or use cases
Cost grows along with the result	Impact must be read on the margin	Estimate trade-offs and sustainability

La domanda non è “qual è l’architettura corretta?” ma “quale scelta diventa meno rischiosa se l’analisi è fatta bene?”.

SQL example: building a control view

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 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;

La query non pretende di dare la risposta finale. Serve a creare una superficie di osservazione: trend, segmenti, differenze tra canali, variazioni nel tempo. Da qui l’analista formula ipotesi più precise.

Python example: checking stability and anomalies

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare cambiamenti reali. In Python possiamo controllare le 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 controllo evita di reagire a ogni oscillazione casuale ma segnala quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive di prodotto.

Real case: Netflix and the discipline of metrics

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 è copiare Netflix, ma il metodo: 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 nuovo algoritmo di ranking, non misura solo il click immediato. Guarda anche i 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 periodo ma erodono valore nel lungo. Lo stesso vale per l’infrastruttura: se le scelte non sono collegate a un outcome, l’analisi resta incompleta.

Esercizio

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare l’infrastruttura del tuo team, indicando metrica, unita di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il tema è ancora troppo astratto.

Al livello intermedio, costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Includi almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade, trasforma l’esercizio in un decision memo con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa log pipeline, metriche dell’orchestratore, cost explorer, incident report e dashboard ops; se non hai dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Common mistakes to avoid

L’errore più frequente è usare l’infrastruttura come etichetta invece che come criterio di scelta: il team mostra un grafico senza decisione, una metrica senza baseline, una conclusione senza dire quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei?

Tre errori ricorrenti restano in agguato. 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é gli utenti che usano una feature potrebbero convertire di più solo perché erano già più motivati. Per ridurre questi rischi, ogni analisi dovrebbe includere definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Checkpoint

Prima di chiudere, prova a rispondere. Quale decisione concreta dovrebbe migliorare questa lezione? Quale unita di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura isolata? Quale assunzione, se falsa, cambierebbe la conclusione? Quale output consegneresti a uno stakeholder non tecnico?

Summary

L’infrastruttura dati moderna è uno strumento decisionale, non un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non finisce con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione. La forma utile resta sempre la stessa: decisione, segnale, baseline, rischio e azione. Tutto il resto serve solo se rende più affidabile uno di questi passaggi.