API sources
marché + chaîne
- alimente
- Kafkaingérer
Toutes les études de cas
Pipelines de donnéesMétriquesBI3 mois
USDDub
Les tableaux de bord avaient six heures de retard sur la réalité. Ils en ont maintenant cinq minutes.
Fraîcheur des données
5 minutes
Streaming avec étapes rejouables
Avant
6 heures
Extractions batch planifiées
En clair
De quoi il s'agit.
Pas de jargon dans cette section. Le compte rendu technique se trouve plus bas.
Ce qui n'allait pas
Les données arrivaient plus vite que les traitements de nuit ne pouvaient les absorber : quiconque ouvrait un tableau de bord voyait au mieux la situation du matin. Quand il fallait retraiter quelque chose, un ingénieur le faisait à la main, souvent le week-end.
Ce que nous avons construit
Nous avons remplacé les traitements de nuit planifiés par un flux continu rejouable à partir de n'importe quel point, et placé chaque chiffre derrière une définition partagée.
Ce qui a changé
Les décisions se prennent sur des données vieilles de quelques minutes et non de quelques heures, le retraitement ne coûte plus de week-end à personne, et toutes les équipes lisent les mêmes chiffres.
Architecture
Comment l'ensemble s'articule.
Faites défiler les étapes. Tout ce qui est marqué comme ajouté est un composant qui n'existait pas avant ce projet.
Kafka
partitionné
- reçoit de
- API sourcesingérer
- alimente
- ClickHouse
ClickHouse
colonnaire
- reçoit de
- Kafka
- alimente
- Modèles dbttransformer
Modèles dbt
incrémentaux
- reçoit de
- ClickHousetransformer
- alimente
- Couche BI
Couche BI
gouvernée
- reçoit de
- Modèles dbt
API sources
marché + chaîne
- alimente
- Kafkaingérer
Kafka
partitionné
Nous avons ajouté ceci- reçoit de
- API sourcesingérer
- alimente
- ClickHouse
ClickHouse
colonnaire
Nous avons ajouté ceci- reçoit de
- Kafka
- alimente
- Modèles dbttransformer
Modèles dbt
incrémentaux
Nous avons ajouté ceci- reçoit de
- ClickHousetransformer
- alimente
- Couche BI
Couche BI
gouvernée
- reçoit de
- Modèles dbt
Le compte rendu
Comment il serait construit.
Jeu de données, approche, métriques cibles et stack. Écrit pour la personne qui devra le relire.
Pipelines de donnéesMétriquesBI3 mois
USDDub
Des données de marché et des signaux canoniques qui restent cohérents entre les sources et dans le temps.
Problème
Les données de marché et d'événements arrivaient plus vite que les jobs batch existants ne pouvaient les traiter : les tableaux de bord avaient des heures de retard et les backfills exigeaient des relances manuelles.
Jeu de données
- lignes
- 14 M d'événements / jour
- features
- 203
- sources
- API de marché, on-chain, services internes
- fenêtre
- 90 jours glissants
Approche
- 01Remplacé les extractions batch par une couche d'ingestion en streaming
- 02Modélisé un entrepôt colonnaire ajusté aux requêtes réellement exécutées
- 03Rendu chaque étape idempotente pour qu'un backfill soit un simple rejeu, pas un sauvetage
- 04Publié un jeu de métriques gouverné derrière une couche BI
Métriques
- 14 M+
- événements / jour en continu
- 5 min
- fraîcheur des données au lieu de 6 heures
- 410 ms
- p95 des requêtes -8,4 s
- automatisé
- effort de backfill au lieu de manuel
Preuves
- source
- Architecture de référence
- chiffres
- Illustratif — valeurs typiques pour cette architecture
- mesure
- Non mesuré. Valeurs typiques pour une architecture de référence de ce type, non observées sur un système client.
- référence
- Non disponible pour ce projet
- dernière revue
- 2026-08-25
Impact métier
- Décisions prises sur des données vieilles de minutes au lieu d'heures
- Les backfills ne mobilisent plus les week-ends des ingénieurs
- Une couche de métriques partagée par tous les consommateurs internes
Stack technique
- Python
- TimescaleDB
- Kafka
- Prefect
- Grafana
- dbt
- Web3.py
Suite
Besoin d'un système comme celui-ci ?
Répondez à six questions et nous vous dirons si cette architecture correspond à votre problème — y compris quand ce n'est pas le cas.