Materialized Views and Continuous Aggregates

Anche questa lezione viaggia sul binario ml-tabellare: i nostri eventi finiscono in tabelle, ma le risposte devono arrivare in tempo reale. Il trucco non è leggere più velocemente, è avere già pronta la risposta prima che la domanda arrivi.

L’idea centrale

Le materialized view pre-aggregano gli eventi in strati per minuto e per ora così le dashboard leggono solo l’ultimo strato in tempi interattivi. Si rinuncia a un dettaglio per guadagnare velocità, in modo pianificato.

Come si costruisce una catena di viste

Cinque passi portano dal flusso grezzo alla dashboard pronta.

1. Elenca le query più frequenti e la granularità minima che le rende utili.
2. Costruisci il primo strato di aggregazione al minuto direttamente dallo stream.
3. Deriva strati orari con deduplicazione utenti solo dove serve precisione.
4. Dichiara come tratti eventi tardivi e cambi di definizione prima della go-live.
5. Fai leggere le dashboard solo dall’ultimo strato e misura latenza e freschezza.

La 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;

The dashboard reads from mv_funnel_hourly with uniqMerge(unique_users_state), con risultato in <100ms su qualsiasi volume.

Le rettifiche tardive: i late-arriving events

In un sistema reale gli eventi possono arrivare in ritardo per dispositivi offline o latenza di rete. Se hai già emesso l’aggregazione per un minuto e dopo arriva un evento con tempo precedente, hai tre strade. Puoi ignorarlo: accetti un errore minimo con massima semplicità. Puoi riemettere con retraction su sistemi esterni come Flink o Kafka Streams, perché ClickHouse non supporta update nativi in vista. Oppure puoi correggere in differita su tabella separata con merge orario, accettando un errore temporaneo per tenere la velocità.

Verdetto: ignora i ritardi dove un errore sotto l’uno per cento è accettabile, correggi in differita per reporting critici e usa retraction esterne solo dove serve precisione immediata.

Gli errori più comuni

L’errore più comune è usare le viste come etichetta invece che come processo, con grafici senza decisione e metriche senza baseline. A livello tecnico evita medie globali premature che nascondono segmenti opposti, tracking con duplicati e timezone incoerenti e scambi tra correlazione e causalità. Ogni analisi porta definizione esplicita, confronto per segmento e verifica contro periodo precedente o controllo.

Riferimenti: ClickHouse (2024), Materialized Views su clickhouse.com/docs; Akidau e colleghi (2015), The Dataflow Model su VLDB 2015.

Il Dataflow Model al lavoro

Akidau e colleghi pubblicano nel 2015 il Dataflow Model su VLDB per unificare batch e streaming con finestre, watermark ed eventi tardivi. Il modello introduce retraction e correzione differita come primitive esplicite per aggregazioni continue. ClickHouse riprende lo stesso compromesso con viste a strati e motori aggreganti che privilegiano velocità con correzioni pianificate. Il criterio resta quello: pre-aggrega per le letture dominanti e dichiara prima come tratti ritardi e ridefinizioni.

Domande per ripassare

1. Quale granularità pre-aggreghi al primo strato e perché?
2. Quando usi deduplicazione utenti e quando basta un conteggio?
3. Come tratti eventi tardivi senza rompere le dashboard?
4. Quale ORDER BY rende veloce la lettura dell’ultimo strato?