Infrastruttura dati moderna: fondamenti

Questa lezione apre il modulo sul binario ml-tabellare e ti dà la mappa dell’infrastruttura che un team dati moderno usa davvero: cloud, storage, compute e orchestrazione visti come un unico sistema da progettare.

Che cosa significa infrastruttura dati moderna

L’infrastruttura dati moderna collega storage, compute, orchestrazione e monitoring in una piattaforma con owner e controlli espliciti. In estrema sintesi: non è un insieme di tool, è un sistema che qualcuno governa.

Il percorso di progettazione

1. Mappa storage, compute, ingestion, orchestrazione e monitoring con owner per ciascuno.
2. Scegli servizio gestito o self-hosted con SLA e costo di manutenzione dichiarati.
3. Definisci ambienti, accessi e budget guardrail prima di aggiungere workload.
4. Verifica recovery, backup e runbook con una prova di ripristino.

Il principio managed-first

Prima di costruire in casa poni tre domande. Esiste un servizio gestito con SLA adeguato? Il suo costo resta sotto il costo delle persone per mantenerlo? La flessibilità persa conta davvero per il business? Nella maggior parte dei casi il servizio gestito vince, perché l’infrastruttura non è il core business.

Verdetto: gestito come default e self-hosted solo con SLA e costo scritti.

I sette pilastri e le loro scelte

Pilastro	Cosa fa	Scelte comuni
Storage	Dove vivono i dati	S3/GCS come data lake, Snowflake/BigQuery come warehouse
Compute	Come si processano i dati	Warehouse compute (Snowflake virtual warehouses), Spark (Databricks/EMR), serverless (BigQuery)
Ingestion	Come i dati entrano	ELT managed (Fivetran, Airbyte), CDC (Debezium), streaming (Kafka)
Orchestration	Chi coordina le pipeline	Airflow, Prefect, Dagster, dbt Cloud scheduler
Transformation	Come i dati vengono modellati	dbt, SQL, Spark
Monitoring	Come sai se qualcosa è rotto	Monte Carlo, Elementary, dbt tests, Grafana alerting
Governance	Chi può accedere a cosa	AWS Lake Formation, Immuta, dbt metadata

Ogni pilastro richiede owner, SLA e metrica di salute: senza owner, il guasto rimbalza tra team.

Verdetto: sette pilastri con owner e SLA; ciò che resta senza owner è debito operativo.

Dove finiscono i soldi

I costi si dividono in quattro voci. Le persone pesano per il 60-70 per cento con data engineer, analytics engineer e devops. Il compute del warehouse vale il 15-20 per cento e cresce con il volume delle query. I tool SaaS occupano il 10-15 per cento con costi fissi prevedibili. Lo storage resta al 5-10 per cento ed è quasi trascurabile su scala media. Il risparmio vero arriva da modelli incrementali e viste materializzate, non dal taglio dello storage.

Esempio SQL: costruire una vista di controllo

Il pattern crea una base analitica con metrica, segmento e finestra temporale. Così confronti periodi e gruppi senza riscrivere la logica.

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;

Esempio Python: controllare stabilità e anomalie

Il controllo su finestra mobile segnala le variazioni che meritano indagine senza reagire a ogni oscillazione.

# 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 giorno in cui mancarono i fallback

Il 4 ottobre 2021 Facebook, Instagram e WhatsApp restano irraggiungibili per circa 6 ore per un errore di configurazione del backbone. Il disservizio mostra cosa significa dipendenza senza fallback: un singolo cambiamento propaga il guasto a tutti i servizi del gruppo. Il ripristino richiede accesso fisico ai data center e coordinamento manuale. La lezione per le piattaforme dati è diretta: ogni pilastro critico dichiara owner, SLA e percorso di recovery prima dell’incidente, non durante.

Domande per metterti alla prova

1. Quale pilastro della tua piattaforma resta senza owner dichiarato?
2. Quale scelta tra gestito e self-hosted hai documentato con SLA e costo?
3. Quale prova di ripristino conferma che backup e runbook funzionano?
4. Quale metrica segnala per prima un degrado del servizio?