import pandas as pd

Data catalog and governance on S3

Un lake senza catalogo diventa in fretta una lista di percorsi S3 che capiscono in pochi. Governare quei dati non vuol dire bloccare l’accesso a tutto: vuol dire sapere cosa esiste, chi lo possiede, chi può leggerlo e con quali limiti. Questa lezione è tecnica, quindi conta meno la definizione e più la decisione che cambia quando un dataset diventa scopribile, descritto, classificato e affidabile.

Il problema concreto

Il problema non è sapere cosa sia un catalogo in teoria. Il problema è decidere cosa fare quando il team lavora con dati incompleti, metriche ambigue e vincoli tecnici che rendono fragile la lettura. Una lezione utile separa il segnale dal rumore, dice rispetto a quale baseline interpretare un numero e indica quale azione diventa difendibile dopo l’analisi.

Un caso ricorrente: un analyst trova tre dataset chiamati customers, ma solo uno ha owner, freshness e classificazione PII aggiornati. Un catalogo che serve davvero non si limita a elencare tabelle. Rende chiaro quale dataset è affidabile, per quale uso e sotto quali permessi.

Come ragionare sulla decisione

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

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo meglio il catalogo?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

La sequenza evita che una nozione tecnica diventi un rituale vuoto. Ogni passaggio dovrebbe rendere più chiaro il costo di una decisione sbagliata. La prima domanda quindi non è “quale metrica calcolo?”, ma quale scelta dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello hanno valore solo se riducono incertezza decisionale; se non cambiano una scelta, sono documentazione.

Formalizzare evidenza e rischio

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

Element	Operational Definition	Controllo minimo
Unit of analysis	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 puo restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

Una formalizzazione è solida quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. Per il catalogo, l’unità di lavoro è il bucket, la partizione, il file, la tabella, il formato o la policy. La metrica osservabile è il costo di scansione, la latenza, l’affidabilità, la freshness o il rischio di accesso. La decisione attesa riguarda il layout dei dati, il table format, il controllo accessi o le lifecycle rule.

Glue Data Catalog

Glue registra i metadati delle tabelle: nomi colonne, tipi, partizioni, formato, posizione S3. Ogni tabella diventa interrogabile da Athena, Redshift Spectrum, EMR e Glue ETL. Senza Glue dovresti definire lo schema in ogni tool separatamente. Con Glue lo definisci una volta e tutti i tool lo vedono.

Il crawler è il processo automatico che scansiona S3, inferisce lo schema e crea o aggiorna le definizioni delle tabelle. Funziona bene con dati semi-strutturati che cambiano schema nel tempo.

Lake Formation e controllo accessi granulare

Senza Lake Formation il controllo accessi su S3 è binario: accesso al bucket sì o no. Con Lake Formation puoi definire chi vede quali colonne (column-level security), chi vede quali righe (row-level security via filter) e chi vede quali tabelle o database.

Un esempio rende l’idea: l’analyst marketing vede la tabella customers ma senza le colonne PII come email e telefono, e solo i clienti EU.

Data lineage

Sapere da dove vengono i dati serve a fidarsi del risultato e a fare debug. Glue, Athena e strumenti come DataHub o OpenLineage tracciano in automatico il percorso S3 → Glue Table → Athena Query → Dashboard. Quando una dashboard mostra numeri sbagliati, risali il lineage fino alla sorgente invece di tirare a indovinare.

Esempio SQL: una vista di controllo

Il pattern seguente è 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 fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui puoi formulare ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da 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 questo tipo di analisi alimenta alert, review settimanali e retrospettive di prodotto.

Lab in tre livelli

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie al catalogo. Indica metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, la lezione è ancora troppo astratta.

Al livello intermedio, costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Inserisci almeno un caso in cui il segnale da solo non basta per decidere.

Al livello research-grade, trasforma l’esercizio in un memo decisionale che includa assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa un export reale, una tabella sintetica, una dashboard interna o un notebook. Il dataset deve avere almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto.

Errori da evitare

L’errore tipico è usare il catalogo come etichetta tecnica invece che come criterio di scelta. Succede quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. In quel caso il dato sembra preciso ma non guida l’azione.

Altri tre errori ricorrono spesso. Il primo è lavorare su dati aggregati troppo presto: una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato, perché eventi duplicati, tracking incompleto e timezone incoerenti producono conclusioni false. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa che la feature causi la conversione, perché potrebbero usarla proprio perché sono già più motivati.

Checkpoint

Prima di chiudere, prova a rispondere a queste domande:

1. Which concrete decision should this lesson improve?
2. Which unit of analysis makes the problem measurable?
3. Quale baseline useresti per evitare una lettura isolata?
4. Quale assunzione, se falsa, cambierebbe la conclusione?
5. Quale controllo presenteresti prima di raccomandare un’azione a uno stakeholder non tecnico?

---

References:

• AWS. (2024). “AWS Glue Developer Guide.” docs.aws.amazon.com/glue.
• AWS. (2024). “AWS Lake Formation.” aws.amazon.com/lake-formation/.

Summary

Il catalogo dati e la governance su S3 diventano utili quando producono una decisione più chiara, non quando aggiungono terminologia. Il valore nasce dal collegare problema, dati, metrica, segmentazione e azione. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”: termina con una frase operativa, cioè quale decisione prendiamo, con quale livello di confidenza, e quale metrica useremo per sapere se avevamo ragione.