import pandas as pd

ClickHouse nel data warehouse moderno

ClickHouse non è una nozione da memorizzare, è una scelta di architettura. La domanda vera non è “che cos’è ClickHouse” ma “quando conviene affiancarlo o sostituirlo al warehouse principale, e quali compromessi accetto facendolo”. Questa lezione tratta il tema come una decisione tecnica con costi e benefici espliciti, non come una definizione da imparare a memoria.

Quando il problema diventa concreto

ClickHouse rende velocissime le query su grandi volumi, ma solo se il modello fisico segue i pattern di lettura: colonne, partizioni, sorting key, compressione e merge. Il problema concreto arriva quando una dashboard operativa deve rispondere in tempo reale su miliardi di righe e il warehouse general-purpose comincia a costare troppo o a rispondere troppo lentamente. A quel punto la scelta non è teorica: o si accetta la latenza, o si introduce un motore specializzato e si paga il prezzo della complessità in più.

Per impostare bene la valutazione conviene partire dai workload invece che dallo strumento. Quali colonne leggi, quali filtri applichi, quale freshness ti serve e quali query devono restare interattive. ClickHouse non è una scorciatoia generica: dà il meglio quando schema e access pattern sono progettati insieme.

Come ragionare sulla scelta

La sequenza utile parte sempre dalla decisione e finisce con un controllo verificabile. Prima chiarisci cosa cambia se introduci ClickHouse, poi quale segnale osservabile riduce l’incertezza, rispetto a quale baseline leggi il risultato, cosa può falsare la lettura e infine quale passo operativo segue.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se introduciamo ClickHouse nel sistema?	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

Ogni passaggio serve a rendere visibile il costo di una scelta sbagliata, prima che diventi un problema di produzione.

La filosofia di ClickHouse

Snowflake è un warehouse general-purpose, ClickHouse è un one-trick pony, ma quel trick lo fa meglio di chiunque altro. Il trick sono le aggregazioni su volumi enormi, ed è progettato per ingerire milioni di righe al secondo, rispondere a query analitiche in millisecondi, comprimere i dati 5-10x rispetto a Parquet e scalare orizzontalmente senza single point of failure. Questa specializzazione è la ragione per cui funziona così bene quando lo usi nel suo dominio, e la ragione per cui delude quando lo forzi fuori.

ClickHouse o Snowflake: quando usare cosa

La scelta dipende dal tipo di carico, non dalle preferenze. Per una dashboard operativa real-time che deve rispondere sub-second su miliardi di righe, ClickHouse vince. Per un report finanziario con transazioni complesse, dove servono ACID, governance e audit, vince Snowflake. Per i log analytics di CDN, firewall e DNS, ClickHouse gestisce ingestione massiva e compressione estrema. Per il data modeling a lenta evoluzione, Snowflake porta il tooling dbt, il catalog e il lineage. Per le time-series di IoT e monitoring, ClickHouse ha motori specializzati.

Scenario	Usa	Perché
Dashboard operativa real-time	ClickHouse	Latenza sub-second su miliardi di righe
Report finanziario con transazioni complesse	Snowflake	ACID, governance, audit
Log analytics (CDN, firewall, DNS)	ClickHouse	Ingestione massiva, compressione estrema
Data modeling con lenta evoluzione	Snowflake	Tooling dbt, catalog, lineage
Time-series (IoT, monitoring)	ClickHouse	Motori specializzati per time-series

ClickHouse come acceleratore

Nella maggior parte dei casi reali non si tratta di scegliere ClickHouse al posto del warehouse, ma di affiancarlo. Il pattern è semplice:

Snowflake/BigQuery (source of truth, governance, ETL)
        │
        ▼
ClickHouse (aggregazioni veloci, dashboard live)

I dati canonici vivono nel warehouse principale con modellazione dbt, test e governance. Un subset, tipicamente metriche aggregate e ultimi N giorni, viene replicato in ClickHouse per dashboard e query interattive. Questo pattern è usato da Cloudflare, Uber e Spotify, e ha il vantaggio di tenere la verità in un posto solo lasciando le query veloci dove servono.

Leggere ClickHouse come parte di un sistema

In un progetto reale ClickHouse non vive isolato. Fa parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista alle prime armi è trattare il tema come una definizione: imparare il nome, ricordare due comandi, applicare un template. Il lavoro professionale è diverso, perché bisogna capire quale problema risolve, quali assunzioni contiene e cosa succede quando quelle assunzioni non valgono.

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. Se non cambiano una scelta, sono documentazione o teatro analitico. Un buon modo per impostare il lavoro è definire il problema in linguaggio business, identificare l’unità di analisi corretta tra utente, account, evento, sessione, ordine o 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 e trasformare il risultato in una raccomandazione verificabile.

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, ma che il dato non viene trattato come ornamento, bensì come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o 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, aumenta la soddisfazione implicita. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma distruggono valore nel lungo. Lo stesso principio vale qui: ClickHouse deve essere collegato a un outcome, e se il risultato non aiuta a scegliere tra due azioni alternative l’analisi è incompleta.

Esempio SQL: una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea una base analitica con metrica, segmento e finestra temporale, così da poter 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;

Questa query non pretende di essere la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui l’analista può formulare ipotesi più precise.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python possiamo 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, ma segnala quando una variazione merita un’indagine. In azienda questo tipo di analisi alimenta alert, review settimanali e retrospettive di prodotto.

Esercizio

Parti dal livello base e scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a ClickHouse, indicando metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il problema è ancora troppo astratto. Al livello intermedio costruisci una tabella con quattro colonne, segnale osservato, interpretazione prudente, controllo necessario e azione consigliata, e includi almeno un caso in cui il segnale 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.

Per i dati usa un export reale, una tabella sintetica, una dashboard interna o un notebook di studio. Il dataset deve contenere almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto. Un caso pratico utile è valutare la migrazione di una dashboard su eventi prodotto ad alto volume: prima di migrare conviene confrontare query reali, cardinalità, sorting key, costo dei merge e frequenza degli aggiornamenti, evitando di scegliere il database solo per benchmark favorevoli.

L’errore tipico

L’errore più comune è usare ClickHouse 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. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

A questo si aggiungono tre errori classici di analisi. Il primo è 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à, perché se gli utenti che usano una feature convertono di più non significa che la feature causi conversione, potrebbero usarla perché sono già più motivati. Per ridurre questi rischi ogni analisi dovrebbe includere almeno una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Riepilogo

ClickHouse va trattato come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando scegli il motore in base al workload: aggregazioni veloci e dashboard live a lui, verità canonica e governance al warehouse principale. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza, e quale metrica useremo per sapere se avevamo ragione.

---

Riferimento: ClickHouse. (2024). “ClickHouse vs Traditional Data Warehouses.” clickhouse.com.