Project: complete data infrastructure

Questa è la lezione conclusiva del modulo, sul binario ml-tabellare: un progetto vero in cui progettiamo l’architettura dati end-to-end di un’azienda in crescita, dagli stakeholder al piano a 12 mesi.

Che cosa ottieni con questo progetto

Il progetto trasforma script manuali e costi opachi in piattaforma con owner, controlli e rituali operativi. In una frase: da un insieme di strumenti a un sistema che qualcuno governa.

La sequenza di lavoro

1. Raccogli requisiti di CEO, marketing, prodotto, finance e compliance con SLA.
2. Disegna architettura, stima costi e definisci team e competenze.
3. Metti in produzione warehouse, orchestratore, CI/CD e monitoring con guardrail.
4. Fissa runbook, backup e piano a 12 mesi con rischi e mitigazioni.

Requisiti degli stakeholder: il caso in tensione

Il caso parte da richieste in tensione che la piattaforma deve soddisfare insieme.

• CEO: report mensile di revenue e profitto per paese entro 3 giorni dalla fine del mese.
• Marketing: dashboard di campagne in tempo reale, con meno di 5 minuti di ritardo e ROAS per canale.
• Prodotto: funnel di conversione e retention D30 per coorte.
• Finance: riconciliazione delle transazioni con il gateway di pagamento.
• Compliance: GDPR, con dati EU conservati solo in data center EU.

Ogni requisito produce owner, SLA e metrica di verifica. Senza questi tre la piattaforma resta una lista di strumenti.

Verdetto: requisiti con SLA scritti prima degli strumenti; mai il contrario.

Cosa devi consegnare

Il deliverable risponde a cinque domande: architettura ad alto livello e motivazioni, stima dei costi annuali per componente, team e competenze necessarie, piano di evoluzione a 3, 6 e 12 mesi, rischi principali con mitigazioni. In produzione servono warehouse, orchestratore, CI/CD, monitoring e controllo costi con ambienti, runbook e budget guardrail prima di nuovi workload.

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 alimenta alert e review operative senza inseguire il rumore.

# 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']])

La lezione che costa 440 milioni di dollari

Il 1 agosto 2012 Knight Capital distribuisce un aggiornamento del software di trading con un flag riutilizzato per errore. In 45 minuti il sistema esegue milioni di ordini involontari e accumula una perdita di 440 milioni di dollari. L’azienda, tra i principali market maker americani, non si riprende più e viene acquisita entro l’anno. Il post-mortem elenca tutto ciò che questo progetto prescrive: deploy senza canarino, flag senza owner e monitoraggio che non ferma niente da solo.

Domande per chiudere il progetto

1. Quale requisito di quale stakeholder guida la tua architettura?
2. Quale stima dei costi annuali giustifica ogni componente scelto?
3. Quale runbook consente di diagnosticare un incidente senza ricostruire tutto?
4. Quale piano a 12 mesi ordina priorità, owner e mitigazioni?