ETL and pipelines for dashboards

Questa lezione, sul binario ml-tabellare, chiude il cerchio tra sorgenti e schermata: la pipeline è ciò che trasporta i dati grezzi fino alla dashboard senza farli invecchiare o corrompere.

Che cosa fa una pipeline per dashboard

La pipeline ETL porta dati grezzi a tabelle analitiche fresche, testate e documentate per dashboard stabili. In sintesi: è il vettore di fiducia tra i sistemi source e la schermata decisionale.

Progettare il flusso, passo per passo

1. Mappa sorgenti, grain e frequenza di refresh richiesta dalla decisione.
2. Costruisci il flusso batch o operativo con test di volume e freschezza.
3. Versiona le trasformazioni e isola gli ambienti di sviluppo e produzione.
4. Monitora refresh, costi e qualità con alert assegnati a un owner.

Batch o operativa: come scegliere

La pipeline batch tipica collega sorgenti, warehouse e trasformazione notturna fino alla dashboard. Il grain è l’unità di ogni riga e la frequenza di refresh è decisa dalla decisione da supportare.

Source DB → Fivetran/Airbyte ogni ora → Snowflake → dbt run notturno → Tableau/Metabase

Con latenza di un giorno per i dati trasformati e di un’ora per i grezzi copre la maggior parte dei casi. La pipeline operativa per monitoraggio e frodi usa invece stream, tabelle materializzate e refresh di pochi secondi.

Event Stream → Kafka → ClickHouse → Materialized Views → Grafana con refresh ogni 5 secondi

La seconda serve solo dove il ritardo costa più del compute aggiuntivo.

Verdetto: batch giornaliero come default, operativo solo dove il ritardo ha un costo misurabile.

Freschezza contro costo: il compromesso onesto

Refresh	Indicative cost/year	Quando utilizzare
Real-time (<1 min)	$$	Monitoring operativo, rilevamento frodi
Schedule	$	Marketing dashboard, sales ops
Daily (night)	$	Financial reports, executive
Weekly	$	Analisi trend, pianificazione

La maggior parte delle dashboard vive bene con aggiornamento giornaliero. Pagare freschezza che nessuno usa brucia budget senza migliorare le decisioni.

Verdetto: scegli il refresh più lento che mantiene valida la decisione.

La validazione: quattro controlli che non si negoziano

Ogni pipeline include quattro controlli: un test di volume sul numero di righe, un test di freschezza sull’ultimo aggiornamento, un test di integrità referenziale sulle chiavi e un alert automatico in caso di fallimento. Senza questi controlli, una vista in ritardo sembra un calo reale.

SQL example: building a control view

La query crea una base analitica con metrica, segmento e finestra temporale. Così confronti periodi e gruppi senza riscrivere la logica.

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;

Python example: checking stability and anomalies

Una metrica utile è stabile e sensibile insieme. Il controllo su finestra mobile isola le variazioni che meritano indagine.

import pandas as pd

# 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']])

Reference: Kimball, R. e Ross, M. (2013). The Data Warehouse Toolkit, 3rd ed. Wiley.

Il caso che ha definito il modo di orchestrare

Nel 2014 il team dati di Airbnb crea Airflow per orchestrare pipeline batch con dipendenze esplicite, retry e scheduling in Python. Il progetto diventa open source nel 2015 ed entra in Apache nel 2019 come standard per flussi batch verso warehouse e dashboard. Il successo nasce da tre scelte operative: dipendenze dichiarate in codice, backfill dei periodi storici e separazione tra sviluppo e produzione. La lezione per le pipeline da dashboard è diretta: vince il flusso che si può rieseguire e testare, non quello più veloce da scrivere.

Domande per chiudere

1. Quale frequenza di refresh richiede davvero la decisione da supportare?
2. Quale test di volume e freschezza blocca una vista difettosa?
3. Quale segmento confronta la vista di controllo che hai costruito?
4. Quale anomalia merita indagine e quale resta rumore?