import pandas as pd

Data lake: backup e disaster recovery

Un data lake può contenere anni di eventi, tabelle curate, snapshot e dataset critici per il reporting regolatorio. Sapere che S3 è durevole non basta: se una policy sbagliata cancella oggetti o se una regione AWS diventa indisponibile, il team deve sapere quali dati ripristinare, in quale ordine e con quale costo. Questa lezione tratta recovery point, restore time, versioning e replica come decisioni operative, non come una lista di feature da abilitare a caso.

Il problema da risolvere

Leggi questa lezione come un piano di continuità. Il backup è utile solo se sai cosa ripristinare, in che sequenza e con quale prova periodica che il restore funzioni davvero. Quasi tutti scoprono che il backup non funzionava nel momento esatto in cui serviva, quindi la domanda non è “abbiamo abilitato il versioning?” ma “quando abbiamo provato l’ultima volta a ripristinare un dato cancellato?”.

Il caso tipico è una pipeline che elimina per errore una partizione curated usata dal reporting finance. In quel momento conta avere versioning attivo, replica in un’altra regione, una policy di retention chiara e un restore documentato che il team ha già eseguito almeno una volta.

Come ragionare sulla protezione dei dati

Prima di scegliere quali meccanismi attivare, conviene fissare l’unità su cui ragioni e la metrica che vuoi tenere sotto controllo. La tabella seguente raccoglie i quattro punti che rendono una strategia DR discutibile invece che affidata all’autorità di chi la propone.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	Oggetto su cui misuri il rischio	Bucket, prefisso, tabella o partizione
Segnale	Cosa osservi per sapere se sei protetto	Esito di un restore di prova
Baseline	Rispetto a cosa giudichi i tempi	RPO e RTO concordati con il business
Rischio residuo	Errore che resta dopo la protezione	Replica abilitata ma restore mai testato

Il punto di queste righe è uno solo: rendere visibili le assunzioni, così uno stakeholder può discutere il criterio invece di fidarsi del risultato.

Strategie di protezione dati

Il versioning di S3 crea una nuova versione a ogni modifica, quindi una cancellazione accidentale si recupera ripristinando la versione precedente. Il costo è lo storage extra delle versioni multiple, ma è la base su cui poggiano quasi tutte le altre protezioni.

aws s3api put-bucket-versioning --bucket my-lake --versioning-configuration Status=Enabled

La cross-region replication (CRR) copia automaticamente gli oggetti in un’altra regione e richiede il versioning abilitato. Se una regione AWS va giù, i dati restano disponibili nell’altra.

S3 eu-west-1 → S3 us-east-1 (async replication)

L’object lock protegge i dati da cancellazione per un periodo fisso, per esempio sette anni per compliance fiscale, e nemmeno l’admin può cancellarli. La modalità Governance permette l’override con permessi speciali, la modalità Compliance non lo permette a nessuno. Sopra a tutto questo, MFA Delete richiede autenticazione multifattore per cancellare versioni di oggetti, così un attacco che compromette solo le credenziali API non basta a distruggere i dati.

RPO e RTO per data lake

Due numeri tengono insieme tutto il resto. L’RPO (Recovery Point Objective) dice quanti dati puoi permetterti di perdere: con la CRR scende intorno ai quindici minuti. L’RTO (Recovery Time Objective) dice quanto tempo serve per tornare operativi: se fai puntare Athena alla replica, l’RTO si misura in minuti, perché basta cambiare la location della query.

Questi due valori vanno concordati con il business prima dell’incidente, non durante. Sono loro la baseline contro cui giudichi se la strategia regge.

Backup e DR 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; il lavoro professionale è capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni saltano.

La prima domanda non è “quale meccanismo abilito?” ma quale decisione dovrà essere presa grazie a questa protezione. Un piano DR ha valore solo se riduce l’incertezza su una scelta concreta: continuare a servire le query da un’altra regione, ricostruire una tabella corrotta, dimostrare a un auditor che il dato fiscale esiste ancora.

Un modo concreto di impostare il lavoro:

1. definire il rischio in linguaggio business;
2. identificare l’unità da proteggere: bucket, prefisso, tabella, partizione;
3. controllare se la protezione copre davvero quel rischio o solo una sua parte;
4. fissare RPO e RTO realistici;
5. testare il restore su un caso non banale;
6. trasformare l’esito in una procedura ripetibile.

Caso reale: Netflix e la disciplina delle metriche

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 all’esperienza, per esempio una nuova riga di raccomandazioni o un diverso algoritmo di ranking, non misura solo il click immediato. Guarda anche se l’utente segue davvero il contenuto, se torna nei giorni successivi, se riduce il tempo speso a cercare. La stessa disciplina vale per il backup: la protezione ha senso solo se è collegata a un outcome misurabile, cioè la capacità dimostrata di ripristinare il dato giusto nei tempi promessi.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Serve a creare 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 non è la risposta finale. Crea una superficie di osservazione (trend, segmenti, differenze tra canali) da cui formulare ipotesi più precise. Lo stesso spirito vale per i log di un restore: prima li rendi leggibili, poi li interroghi.

Esempio Python: controllare stabilità e anomalie

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 anche per accorgersi che una replica ha smesso di aggiornarsi.

# 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.

Errori comuni da evitare

Il primo errore è trattare il backup come un’etichetta tecnica invece che come un criterio di scelta: si abilita il versioning, si mette una spunta e non si prova mai un restore reale. Il secondo è confondere replica con disaster recovery: avere i dati in due regioni non serve se nessuno sa quale procedura seguire quando una regione cade. Il terzo è ignorare il costo, perché versioni multiple e classi sbagliate possono far esplodere la spesa di storage senza alcun beneficio in termini di rischio.

Per ridurre questi rischi ogni piano DR dovrebbe avere almeno tre controlli: una definizione esplicita di cosa proteggi, RPO e RTO concordati con il business, e un restore di prova eseguito periodicamente e documentato.

Riepilogo

Il backup e il disaster recovery di un data lake diventano utili quando producono una scelta più sicura, non quando aggiungono terminologia. Il versioning recupera le cancellazioni, la CRR copre la perdita di una regione, object lock e MFA Delete proteggono da errori e attacchi, mentre RPO e RTO traducono tutto in numeri discutibili con il business. Una buona strategia non finisce con “abbiamo abilitato la replica”: finisce con la prova che il team sa ripristinare il dato giusto nei tempi promessi.