import pandas as pd

Data Lifecycle and Storage Management

Un bucket cresce ogni giorno con log grezzi, file intermedi, snapshot e output analytics, ma quei dati non hanno lo stesso valore dopo 7, 90 o 365 giorni. Leggi questa lezione come governance del tempo: il lifecycle corretto non è solo risparmio di storage, decide quali dati restano disponibili, quali diventano freddi e quali non dovrebbero più esistere. Imparare a spostare, archiviare o cancellare dati in base a uso, obblighi e costo è il vero contenuto operativo.

Il problema da risolvere

Il caso tipico: i log raw servono spesso per trenta giorni, raramente per dodici mesi e quasi mai dopo due anni, ma alcuni devono restare per audit. Una regola unica per tutto il bucket è quasi sempre sbagliata, perché tratta allo stesso modo dati con valore e obblighi diversi. Servono lifecycle policy distinte per raw, curated e compliance.

La domanda guida non è “quale classe di storage esiste?” ma “quale dato voglio poter ancora interrogare domani, e quanto sono disposto a pagare per tenerlo caldo?”. Sbagliare costa in due direzioni: troppo caldo brucia budget, troppo freddo rende un dato di fatto irraggiungibile quando serve.

Come ragionare sul ciclo di vita

Prima di scrivere una policy conviene fissare l’unità su cui ragioni e il segnale che osservi. La tabella seguente rende esplicite le assunzioni, così uno stakeholder può discutere il criterio invece di subirlo.

Element	Operational Definition	Controllo minimo
Unit of analysis	Oggetto su cui applichi la regola	Prefisso, classe di dato, tabella
Signal	Cosa osservi per decidere	Frequenza di accesso e obblighi di retention
Baseline	Rispetto a cosa giudichi il costo	Spesa attuale per classe di storage
Rischio residuo	Errore che resta dopo la policy	Dato in Glacier che ti serviva caldo

Ogni regola di lifecycle deve rispondere a una domanda concreta: dopo quanti giorni questo dato smette di valere il prezzo della classe in cui sta.

S3 storage classes: from hot to cold

Le classi S3 si distinguono per costo, latenza e prezzo di recupero. La regola pratica è semplice: più un dato è freddo, meno costa tenerlo ma più costa e più è lento rileggerlo.

Class	Cost/GB/month	Access latency	Recovery	For data...
S3 Standard	~$0.023	Milliseconds	Free	Last 30-90 days
S3 IA (Infrequent Access)	~$0.0125	Milliseconds	$0.01/GB	3-12 months, rare access
S3 Glacier	~$0.004	Minutes/hours	$0.01-0.03/GB	>12 months, compliance only
S3 Deep Archive	~$0.00099	Hours	$0.02/GB	Obsolete history, almost never read

Lifecycle policy in practice

Una policy concreta sposta i dati lungo le classi man mano che invecchiano e li cancella alla fine del periodo di retention.

{
  "Rules": [
    {"Transition": {"Days": 30, "StorageClass": "STANDARD_IA"}},
    {"Transition": {"Days": 90, "StorageClass": "GLACIER"}},
    {"Expiration": {"Days": 2555}}  // 7 anni
  ]
}

Dopo trenta giorni i dati passano in Infrequent Access (costo ridotto del 45%), dopo novanta giorni in Glacier (costo ridotto dell’83%), dopo sette anni vengono cancellati. Su un data lake da 200 TB una policy del genere può far risparmiare centinaia di migliaia di dollari all’anno.

Querying archived data

Qui sta la trappola più comune. Athena non può interrogare direttamente i dati in Glacier: vanno ripristinati prima, con ore di attesa. Per dati storici che potresti dover interrogare, lasciali in S3 IA invece che in Glacier. Glacier va riservato alla pura compliance, per esempio dati fiscali di cinque anni fa che quasi certamente non leggerai mai.

Il pattern che funziona: tieni in S3 Standard i dati degli ultimi novanta giorni, in IA quelli tra tre e ventiquattro mesi, in Glacier il resto. Le dashboard leggono solo Standard, le query di audit richiedono un restore da Glacier con preavviso.

---

References:

• AWS. (2024). “S3 Storage Classes.” aws.amazon.com/s3/storage-classes/.

Il lifecycle come parte di un sistema

In un progetto reale questo tema non vive isolato. Fa parte di un sistema fatto di decisioni, dati disponibili, vincoli tecnici e incentivi organizzativi. Il rischio del principiante è trattarlo come una definizione da memorizzare; la pratica professionale è capire quale problema risolve e cosa succede quando le assunzioni saltano, per esempio quando un dato spostato in Glacier serviva invece per un’analisi urgente.

La prima domanda non è “quale classe scelgo?” ma quale decisione dipende da quel dato. Una regola di retention ha valore solo se riduce incertezza su una scelta concreta: quanto budget di storage allocare, quali dati garantire per l’audit, quali eliminare per ridurre la superficie di rischio. Un modo concreto di impostare il lavoro:

1. define the problem in business language;
2. identificare l’unità di analisi corretta: prefisso, classe di dato, tabella;
3. controllare se la policy copre davvero il rischio o solo una parte;
4. stimare costo e tempo di recupero per classe;
5. segmentare le regole per tipo di dato invece di applicarne una sola;
6. trasformare il risultato in una policy verificabile.

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. Non si tratta di copiare Netflix, ma di trattare il dato come infrastruttura decisionale e non come ornamento.

Quando l’azienda valuta una modifica, per esempio una nuova riga di raccomandazioni o un diverso algoritmo di ranking, non misura solo il click immediato ma anche se l’utente segue il contenuto e se torna nei giorni successivi. Lo stesso principio vale per il lifecycle: una policy ha senso solo se è collegata a un outcome, cioè a un costo che scende o a un rischio che si riduce in modo misurabile.

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 crea una superficie di osservazione (trend, segmenti, differenze tra canali) da cui formulare ipotesi più precise. Lo stesso approccio serve per stimare quanto e quando un certo prefisso viene davvero letto, prima di deciderne la classe.

Python example: checking stability and anomalies

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python si possono individuare variazioni anomale settimana su settimana, utile per accorgersi che un dato considerato freddo è tornato improvvisamente caldo.

# 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 valore del controllo è pratico: evita di reagire a ogni oscillazione casuale e segnala quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive.

Common mistakes to avoid

Il primo errore è applicare una sola regola di lifecycle a tutto il bucket, ignorando che raw, curated e dati di compliance hanno valore e obblighi diversi. Il secondo è mandare in Glacier dati che potresti dover interrogare, scoprendo solo durante un incidente che il restore richiede ore. Il terzo è confondere risparmio di storage con risparmio reale: una policy che cancella dati ancora soggetti a obbligo di retention sposta il costo dal cloud alla multa.

Per ridurre questi rischi ogni policy dovrebbe avere almeno tre controlli: una definizione esplicita di cosa cancelli e quando, una stima del costo e del tempo di recupero per classe, e una verifica degli obblighi di retention prima di impostare l’expiration.

Summary

La gestione del ciclo di vita diventa utile quando produce una scelta più chiara su costo e disponibilità, non quando elenca classi di storage. Le transizioni spostano i dati da Standard a IA a Glacier man mano che si raffreddano, l’expiration li cancella alla fine della retention, e il vincolo da ricordare è che Glacier non è interrogabile a freddo. Una buona policy non finisce con “abbiamo risparmiato sullo storage”: finisce sapendo quali dati restano caldi, quali freddi e quali non dovrebbero più esistere.