Cheat sheet per il real-time analytics

Questa scheda appartiene al binario ml-tabellare e raccoglie in poche righe tutto quello che serve per non sbagliare in produzione: stack, comandi e controlli essenziali da ripassare prima di ogni release.

Di cosa si occupa la scheda

Questa scheda fissa stack, comandi e controlli minimi per revisionare ingestion, viste, dashboard e alert prima della produzione. È uno strumento di review, non di lettura.

Come si applica

Ecco i cinque controlli da eseguire in ordine.

1. Verification event time, idempotenza e gestione dei late data in ingestion.
2. Controlla ORDER BY, partizionamento e uso di FINAL nelle query critiche.
3. Separa dashboard operative da analitiche e fissa owner e runbook per alert.
4. Sostituisci soglie statiche con baseline adattive dove i volumi variano.
5. Blocca il rilascio se freshness, costi o responsabilità restano indefiniti.

Come usare la scheda

Usala da review prima di approvare ingestion, trasformazioni, viste, dashboard e alert. Se una voce non ha risposta chiara, non è un dettaglio da rimandare. È un punto dove la pipeline produce velocemente un errore. La prima domanda non è quale metrica calcoli. È quale decisione migliora grazie all’analisi. Se non cambia una scelta, la voce è documentazione e non controllo.

Lo stack di riferimento

App/Sensori → Kafka → ClickHouse (Kafka Engine) → Materialized Views → Dashboard (Grafana)

Lo stack tipico unisce Kafka per durability e ClickHouse per velocità, con viste a strati che pre-aggregano e alert dinamici che evitano falsi positivi. Tieni separate operative e analitiche, e se il dato può aspettare un’ora il batch resta più economico.

I comandi ClickHouse da ricordare

-- Tabella Kafka (ingestione)
CREATE TABLE kafka_events (...) ENGINE = Kafka
SETTINGS kafka_broker_list='...', kafka_topic_list='...',
         kafka_group_name='...', kafka_format='JSONEachRow';

-- Materialized View in cascata
CREATE MATERIALIZED VIEW mv_1min ENGINE = SummingMergeTree()
ORDER BY (minute, type) AS SELECT toStartOfMinute(time) AS minute,
       type, count() AS cnt FROM kafka_events GROUP BY minute, type;

-- Query con FINAL per deduplicazione
SELECT * FROM customers FINAL WHERE id = 123;

-- Top N ultimi 5 minuti
SELECT type, count() FROM events WHERE time >= now() - INTERVAL 5 MINUTE
GROUP BY type ORDER BY count() DESC LIMIT 10;

La scelta dell’ORDER BY

È la decisione più importante in ClickHouse, perché determina l’ordine fisico su disco e quindi la velocità delle query.

If main query is...	Optimal ORDER BY
Filter by user	(user_id, event_time)
Aggregation by event type	(event_type, event_time)
Pure time series	(event_time, event_type)
JOIN with other tables	Dimension PK as first field

Batch o stream

La scelta tra batch e stream dipende dall’urgenza della decisione che il dato deve supportare.

Batch	Stream
Monthly reports	Fraud detection
ML model training	Operational dashboards
Financial reconciliations	In-session personalization
Data quality audit	Automatic alerting

Verdetto: usa batch dove ore di ritardo sono accettabili e streaming solo dove la decisione perde valore se aspetta, con stack Kafka più ClickHouse e viste a strati.

Gli anti-pattern da bloccare in review

Alcuni errori vanno bloccati in review. Usare SELECT * su ClickHouse forza la lettura di tutte le colonne. Le soglie statiche su volumi variabili producono allarmi inutili e vanno sostituite con baseline adattive. Una vista senza ORDER BY ottimizzato resta lenta quanto la query grezza. Un alert senza azione richiesta è un log, non un alert.

Il caso di Stripe Radar

Stripe, fondata nel 2010, lancia nel 2016 Radar per valutare ogni pagamento in tempo reale con modelli addestrati sulla rete. Nel 2023 supera i 1.000 miliardi di dollari di volume annuo, dove ogni punto base di precisione vale decine di milioni. La checklist nasce da vincoli così: event time contro processing time, late data dopo il verdetto, idempotenza contro doppi addebiti e owner che rispondono in minuti. Ogni voce vale solo se collegata a un outcome di questo tipo.

Domande per ripassare

1. Quale stack usi per durability, velocità e visualizzazione?
2. Quale ORDER BY scegli per filtro utente e serie temporali?
3. Quando batch batte stream per costi e affidabilità?
4. Quale anti-pattern bloccheresti prima in review?