import pandas as pd

Materialized Views e Continuous Aggregates

La stessa query di aggregazione viene lanciata centinaia di volte al giorno e ogni run ricalcola lavoro già noto. La domanda diventa: quale parte del risultato può essere materializzata, con quale ritardo accettabile e con quali regole di correzione? Le materialized views affrontano il trade-off tra risposta rapida e verità aggiornata, e vanno lette come una scelta operativa più che come un argomento da manuale.

Il problema

Conoscere le materialized views in astratto serve a poco. Il problema vero è decidere cosa fare quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Una vista materializzata è utile solo quando rende espliciti i compromessi che propone: cosa è pre-calcolato, quando si aggiorna, come gestisce dati in ritardo e cosa succede se la definizione cambia.

In un progetto reale il tema non vive mai isolato. È parte di un sistema fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista principiante è trattarlo come una definizione: imparare il nome, ricordare due formule, applicare un template. Il lavoro professionale è capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni non sono vere. La prima domanda non è “quale metrica calcolo”, ma quale decisione dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello hanno valore solo se riducono incertezza decisionale.

Modello concettuale

Un buon modo per impostare il lavoro è seguire una sequenza che parte dal business e arriva alla raccomandazione: definire il problema in linguaggio business; identificare l’unità di analisi corretta (utente, account, evento, sessione, ordine, campagna); controllare se i dati misurano davvero il fenomeno o solo una sua ombra; costruire una metrica interpretabile; segmentare per evitare che la media nasconda pattern opposti; trasformare il risultato in una raccomandazione verificabile.

Fase	Cosa chiarire	Output
Domanda	Quale scelta reale deve migliorare?	Decisione da prendere
Misura	Quale segnale osservabile rappresenta il problema?	Metrica o dato sorgente
Controllo	Quale baseline rende il risultato interpretabile?	Confronto credibile
Azione	Che cosa cambia dopo l’analisi?	Prossimo passo operativo

Il modello è intenzionalmente semplice: decisione, dato, controllo, azione. Ogni approfondimento tecnico deve rafforzare almeno uno di questi quattro punti.

Formalizzazione rigorosa

Per rendere le materialized views analizzabili, definisci prima l’unità di lavoro: evento, finestra temporale, materialized view, alert o metrica live. Poi collegala a una metrica osservabile: latenza, freshness, falsi positivi, throughput, costo query. Infine dichiara la decisione attesa: pipeline realtime, vista aggregata, alert o dashboard operativa.

Elemento	Specifica richiesta
Unità di analisi	evento, finestra temporale, materialized view, alert o metrica live
Segnale principale	latenza, freshness, falsi positivi, throughput e costo query
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	pipeline realtime, vista aggregata, alert o dashboard operativa
Rischio	Scambiare un numero disponibile per una prova sufficiente

La formalizzazione è solida quando un altro analista può riprodurre la logica, criticare le assunzioni e ottenere la stessa decisione partendo dagli stessi dati.

Catena di aggregazione a strati

Un funnel di conversione in tempo reale mostra bene il pattern. Gli eventi grezzi entrano da Kafka, una prima materialized view aggrega al minuto, una seconda aggrega all’ora deduplicando gli utenti, e la dashboard legge solo l’ultimo strato.

Eventi Grezzi (Kafka)
      │
      ▼
MV_events_per_minute: event_type × minuto, count()
      │
      ▼
MV_funnel_hourly: funnel_step × ora, unique_users
      │
      ▼
Dashboard: leggi da MV_funnel_hourly

Il primo livello aggrega al minuto:

CREATE MATERIALIZED VIEW mv_events_per_minute
ENGINE = SummingMergeTree()
ORDER BY (event_time, event_type)
AS SELECT toStartOfMinute(event_time) AS event_time,
          event_type, count() AS cnt
FROM kafka_events GROUP BY event_time, event_type;

Il secondo aggrega all’ora con deduplicazione utenti:

CREATE MATERIALIZED VIEW mv_funnel_hourly
ENGINE = AggregatingMergeTree()
ORDER BY (hour, funnel_step)
AS SELECT toStartOfHour(event_time) AS hour,
          funnel_step,
          uniqState(user_id) AS unique_users_state
FROM mv_events_per_minute
JOIN funnel_definitions USING (event_type)
GROUP BY hour, funnel_step;

La dashboard legge da mv_funnel_hourly con uniqMerge(unique_users_state), con risultato in <100ms su qualsiasi volume.

Rettifiche tardive: i late-arriving events

In un sistema reale gli eventi possono arrivare in ritardo, per un dispositivo offline o per latenza di rete. Se hai già emesso l’aggregazione per il minuto 10:00 e alle 10:03 arriva un evento con event_time 10:00, cosa fai? Hai tre strade.

Puoi ignorarlo (at-least-once): l’evento tardivo è perso, è semplice ma inaccurato. Puoi riemettere: la materialized view emette un UPDATE all’aggregazione precedente, ma ClickHouse non supporta UPDATE nativi in MV, quindi devi appoggiarti a un sistema esterno come Flink o Kafka Streams con retraction. Oppure puoi correggere in differita: scrivi l’evento tardivo su una tabella separata e ogni ora fai un merge corretto, accettando un errore temporaneo in cambio della velocità.

La scelta dipende dal requisito di accuratezza rispetto alla latenza. Per dashboard operative, ignorare è spesso accettabile (errore <1%). Per reporting finanziario, conviene la correzione differita.

Esempio SQL: una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. L’obiettivo è 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 pretende di essere la risposta finale. Crea una superficie di osservazione su trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui l’analista formula ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python si possono controllare 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 valore di questo controllo è pratico: evita di reagire a ogni oscillazione casuale e segnala quando una variazione merita investigazione. In azienda alimenta alert, review settimanali e retrospettive di prodotto.

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. Il punto non è che ogni azienda debba copiare Netflix. È metodologico: il dato non è ornamento, è infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, una nuova riga di raccomandazioni, una diversa immagine di copertina, un algoritmo di ranking, non misura solo il click immediato. Misura anche segnali di qualità: l’utente guarda davvero il contenuto? torna nei giorni successivi? riduce il tempo speso a cercare? Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma danneggiano valore nel lungo periodo. Lo stesso principio vale qui: una materialized view deve essere collegata a un outcome. Se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

Lab

Tre livelli di difficoltà crescente.

Al livello base, scrivi una scheda di una pagina: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale è confermato.

Al livello intermedio, costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione.

Al livello research-grade, prepara un decision memo: ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione.

Per i materiali usa ClickHouse, stream eventi, CDC, metriche operative, dashboard realtime e log applicativi. Se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errore tipico da evitare

L’errore più comune è usare le materialized views come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza indicare quale assunzione potrebbe invalidarla. Il primo errore tecnico è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione 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 conversione, potrebbero usarla perché già più motivati. Per ridurre questi rischi, ogni analisi dovrebbe includere almeno tre controlli: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Checkpoint

1. Quale decisione concreta dovrebbe migliorare questa lezione?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura ingenua?
4. Quale errore tipico potrebbe cambiare la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

Le materialized views vanno trattate come strumento decisionale, non come argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”. Termina con una frase operativa: quale decisione prendiamo, con quale livello di confidenza e quale metrica useremo per sapere se avevamo ragione.

---

Riferimenti:

• ClickHouse. (2024). “Materialized Views.” clickhouse.com/docs.
• Akidau, T. et al. (2015). “The Dataflow Model.” VLDB 2015.