Data lake monitoring e data quality

Questa lezione, come le altre del binario ml-tabellare, parte da un’evidenza scomoda: un lake continua a ricevere file anche quando arrivano in ritardo, con schema cambiato o volumi anomali. Il problema spesso emerge solo a valle, in un report business già sbagliato. Monitorare un data lake significa trasformare questi silenzi in segnali osservabili: file attesi, partizioni mancanti, qualità dei dati e costi fuori soglia. Leggi la lezione come la costruzione di un sistema di allarme che intercetta freschezza, completezza, duplicati e drift prima che guidino una decisione sbagliata.

L’idea in una frase

Monitorare un data lake significa controllare ogni giorno freschezza, completezza, schema e costi delle partizioni prima che i dati sbagliati raggiungano i report.

Come procedere, passo dopo passo

1. Definisci per ogni tabella la partizione attesa e la sua finestra di arrivo.
2. Misura ogni giorno le righe per partizione e confrontale con la media mobile a sette giorni.
3. Controlla dimensione dei file, schema dei nuovi arrivi e duplicati prima del job a valle.
4. Instrada ogni anomalia verso un alert con soglia scritta e responsabile di intervento.
5. Registra i falsi positivi e rivedi le soglie finché ogni alert porta a una decisione.

Il problema concreto

Il caso tipico è una partizione giornaliera arrivata con metà dei file attesi e uno schema leggermente diverso, mentre il job successivo continua senza fallire. Monitoring e data quality servono a controllare volume, freschezza, schema e valori anomali prima che i dati finiscano in analytics.

La prima domanda non è quale metrica calcolare, ma quale decisione dovrà cambiare grazie a questa analisi. Se il risultato non cambia una scelta, è documentazione, non monitoring.

Come ragionare sulla decisione

Conviene tenere a mente una sequenza, dalla decisione all’azione misurabile.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se capiamo meglio il monitoring?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

Formalizzare evidenza e rischio

Leggi la lezione come una relazione tra decisione, evidenza e rischio. La tabella rende esplicite le assunzioni, così uno stakeholder può discutere il criterio invece di fidarsi del risultato per autorità.

Elemento	Definizione operativa	Controllo minimo
Unita di analisi	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che può restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

L’unità di lavoro è il bucket, la partizione, il file, la tabella o la policy. La metrica osservabile è il costo di scansione, la latenza, l’affidabilità, la freschezza o il rischio di accesso.

Le cinque metriche che contano

Queste cinque metriche coprono i guasti più costosi: partizioni mancanti, volumi crollati, file illeggibili, schema cambiato e costi fuori controllo.

Metrica	Tool	Alert se
Freschezza partizioni	Glue/Athena query su MAX(partition)	Ultima partizione >24 ore fa
Volume righe per partizione	Athena COUNT(*) per partizione	Volume <50% della media mobile 7gg
File size anomalo	S3 inventory	File <10MB o >5GB
Schema validity	Glue Schema Registry	Nuovo file non matcha lo schema atteso
Cost anomalies	AWS Cost Explorer	Costo Athena >budget mensile

Implementare data quality checks

I due controlli minimi sono freschezza dell’ultima partizione e volume rispetto alla media settimanale.

-- Check freschezza: ultima partizione caricata
SELECT MAX(CONCAT(year, '-', LPAD(month,2,'0'))) AS last_partition
FROM information_schema.partitions
WHERE table_name = 'orders';

-- Check volume: confronto con media 7 giorni
SELECT COUNT(*) AS today_rows
FROM orders WHERE year=2024 AND month=3 AND day=15;
-- Alert se today_rows < avg_7gg * 0.5

Questi check vanno integrati in un workflow Airflow o Prefect che gira ogni ora e invia un alert su Slack o via email quando qualcosa non torna.

Esempio SQL: una vista di controllo

Il pattern è 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 con trend, segmenti, differenze tra canali e variazioni nel tempo, da cui formulare ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica deve essere stabile per orientare le decisioni e sensibile per segnalare cambiamenti reali. In Python puoi controllare le variazioni anomale settimana su settimana.

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

Errori da evitare

L’errore tipico è usare il monitoring come etichetta tecnica invece che come criterio di scelta: presentare un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. Tre errori ricorrono spesso: aggregare troppo presto, ignorare duplicati e timezone incoerenti, e confondere correlazione con causalità.

Il caso Knight Capital

Knight Capital, uno dei principali market maker statunitensi, il primo agosto 2012 mandò in produzione un aggiornamento software con una funzione obsoleta riattivata per errore. Senza controlli di deployment e limiti di esposizione adeguati, il sistema eseguì in meno di un’ora milioni di ordini anomali sul mercato azionario americano. La società dichiarò una perdita di circa 440 milioni di dollari e pochi giorni dopo dovette accettare un salvataggio che pose fine alla sua indipendenza. La lezione per un data lake è diretta: senza check di freschezza, volume e anomalie con soglie scritte e alert instradati, un errore silenzioso a monte diventa una perdita a valle.

Verdetto: monitora ogni giorno freschezza, completezza, schema e costi delle partizioni prima che i dati sbagliati raggiungano i report: instrada ogni anomalia verso un alert con soglia scritta e responsabile, e registra i falsi positivi finché ogni alert porta a una decisione.

Domande per verificare quello che hai capito

1. Quale partizione attesa controlli per prima quando un report risulta sospetto?
2. Quale soglia di volume rispetto alla media a sette giorni fa scattare il tuo alert?
3. Quale check di schema e dimensione dei file esegui prima del job a valle?
4. Quale alert hai ricevuto per ultimo e quale decisione ha cambiato?