API sorgente
mercato + chain
- alimenta
- Kafkaingestion
Tutti i case study
Pipeline di datiMetricheBI3 mesi
USDDub
Le dashboard erano sei ore indietro rispetto alla realtà. Ora sono indietro di cinque minuti.
Freschezza dei dati
5 minuti
Streaming con fasi rieseguibili
Prima
6 ore
Estrazioni batch programmate
In parole semplici
Di cosa si tratta.
Niente gergo in questa sezione. La descrizione tecnica è più in basso.
Cosa non funzionava
I dati arrivavano più velocemente di quanto i job notturni riuscissero a elaborarli, così chi apriva una dashboard vedeva, nel migliore dei casi, la situazione del mattino. Quando qualcosa andava rielaborato, lo faceva a mano un ingegnere, spesso nel fine settimana.
Cosa abbiamo costruito
Abbiamo sostituito i job notturni programmati con un flusso continuo che si può rieseguire da qualsiasi punto, e abbiamo legato ogni numero a un'unica definizione condivisa.
Cosa è cambiato
Le decisioni si prendono su dati vecchi di minuti invece che di ore, la rielaborazione non costa più il fine settimana a nessuno e ogni team legge gli stessi numeri.
Architettura
Come si incastrano le parti.
Scorra le fasi. Tutto ciò che è contrassegnato come aggiunto è un componente che non esisteva prima di questo progetto.
Kafka
partizionato
- riceve da
- API sorgenteingestion
- alimenta
- ClickHouse
ClickHouse
colonnare
- riceve da
- Kafka
- alimenta
- modelli dbttrasformazione
modelli dbt
incrementale
- riceve da
- ClickHousetrasformazione
- alimenta
- Layer BI
Layer BI
governato
- riceve da
- modelli dbt
API sorgente
mercato + chain
- alimenta
- Kafkaingestion
Kafka
partizionato
L'abbiamo aggiunto noi- riceve da
- API sorgenteingestion
- alimenta
- ClickHouse
ClickHouse
colonnare
L'abbiamo aggiunto noi- riceve da
- Kafka
- alimenta
- modelli dbttrasformazione
modelli dbt
incrementale
L'abbiamo aggiunto noi- riceve da
- ClickHousetrasformazione
- alimenta
- Layer BI
Layer BI
governato
- riceve da
- modelli dbt
La descrizione
Come verrebbe costruito.
Dataset, approccio, metriche obiettivo e stack. Scritto per chi dovrà esaminarlo.
Pipeline di datiMetricheBI3 mesi
USDDub
Dati di mercato e segnali canonici che restano coerenti tra fonti diverse e nel tempo.
Problema
I dati di mercato e di evento arrivavano più velocemente di quanto i job batch esistenti riuscissero a elaborarli, così le dashboard erano vecchie di ore e i backfill richiedevano riesecuzioni manuali.
Dataset
- righe
- 14M eventi / giorno
- feature
- 203
- fonti
- API di mercato, on-chain, servizi interni
- finestra
- 90 giorni mobili
Approccio
- 01Estrazioni batch sostituite con un layer di ingestion in streaming
- 02Modellato un warehouse colonnare ottimizzato per i pattern di query reali
- 03Ogni fase resa idempotente, così un backfill è una riesecuzione e non un salvataggio
- 04Pubblicato un set di metriche governato dietro un layer BI
Metriche
- 14M+
- eventi / giorno sostenuti
- 5 min
- freschezza dei dati da 6 ore
- 410ms
- query p95 -8.4s
- automatizzato
- impegno per i backfill da manuale
Evidenza
- fonte
- Reference design
- numeri
- Illustrativo: valori tipici per questo design
- misurazione
- Non misurato. Valori tipici per un progetto di riferimento di questo tipo, non osservati su un sistema di un cliente.
- referenza
- Non disponibile per questo progetto
- ultima revisione
- 2026-08-25
Impatto sul business
- Decisioni prese su dati vecchi di minuti invece che di ore
- I backfill non consumano più i fine settimana degli ingegneri
- Un unico metric layer condiviso da ogni consumatore interno
Stack tecnologico
- Python
- TimescaleDB
- Kafka
- Prefect
- Grafana
- dbt
- Web3.py
Prossimo passo
Le serve un sistema come questo?
Risponda a sei domande e le diremo se questa struttura si adatta al suo problema, anche quando non è così.