Modern data infrastructure: fundamentals

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.

The managed-first principle

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

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

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.

SQL example: building a control view

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;

Python example: checking stability and anomalies

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?