Gestione dei costi dell’infrastruttura dati

Sul binario ml-tabellare, questa lezione affronta il tema che nessuno ama ma tutti pagano: dove vanno i soldi dell’infrastruttura e come farli fruttare.

Che cosa significa controllare i costi dati

Il controllo dei costi attribuisce ogni spesa a workload e owner con guardrail misurabili. In una frase: se una spesa non ha un proprietario, non è un costo, è una fuga.

Il metodo di lavoro

1. Identifica i cinque modelli o query più costosi con viste di sistema del warehouse.
2. Separa costi fissi da costi variabili per workload e team.
3. Converti i modelli append-only in incrementali e limita le finestre temporali.
4. Assegna owner e budget guardrail con dashboard dei costi visibile a tutti.

L’audit dei costi: partire dai cinque più grandi

Si parte dai cinque modelli più costosi, che spesso superano metà della spesa totale. In Snowflake emergono dalla cronologia delle query, in BigQuery dallo schema informativo dei job. Per ciascuno chiedi se il costo è necessario e se il modello può diventare incrementale. Poi separa i costi fissi come storage e infrastruttura dai costi variabili come query ad hoc e job schedulati.

Verdetto: prima i cinque modelli più costosi, poi tutto il resto.

Le quattro leve che riducono davvero la spesa

La conversione da tabella completa a modello incrementale taglia il costo dell’80-95 per cento sui grandi flussi append-only. I filtri sulle date evitano di leggere cinque anni quando servono 90 giorni; in sviluppo bastano 30 giorni di dati. Il dimensionamento del warehouse pesa molto, perché una taglia XL consuma sedici volte una XS: aumenta solo quando serve e riduci subito dopo. I timeout automatici, tipicamente dieci minuti sulle query di produzione, fermano le esecuzioni fuori controllo.

Verdetto: incrementale, finestre corte e taglie piccole come default operativo.

La cultura dei costi si costruisce mostrando i numeri

La dashboard con costo per modello, costo per team e trend mensile cambia i comportamenti più di qualsiasi policy. Quando un team vede il costo reale della propria dashboard trova subito il modo di ridurlo. La spesa diventa responsabilità condivisa solo se resta visibile nello stesso posto dove si decide.

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

Lo stesso schema a finestra mobile individua i picchi di spesa fuori dalla variabilità settimanale.

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

L’IPO che ha spiegato dove stanno i soldi

Il 16 settembre 2020 Snowflake si quota al NYSE con una raccolta di circa 3,36 miliardi di dollari nella maggiore IPO software dell’epoca. Il prospetto mostra la separazione che governa ogni budget dati: il compute cresce con le query e si ottimizza con incrementali e viste materializzate, mentre lo storage resta una voce quasi trascurabile. La lezione per il controllo dei costi è diretta: si governa il compute con owner e guardrail, non si taglia lo storage alla cieca.

Domande per chiudere

1. Quali cinque modelli consumano oltre metà del tuo budget warehouse?
2. Quale conversione a incrementale taglia di più il costo ricorrente?
3. Quale guardrail assegna owner e budget a ogni workload?
4. Quale dashboard rende visibile la spesa a tutti i team?