Concevez un pipeline de tracking d'événements à haut volume pour des rapports et du ML — quelle stack ?

Question

IT Interview Practice · Accepted Answer

À des centaines de millions d'événements/jour (~quelques milliers/sec, davantage aux pics), le bon choix est de découpler l'ingestion du serving : absorber les écritures dans un log durable, traiter le stream une seule fois, et le distribuer vers deux stores optimisés pour des tâches opposées — pré-agrégé pour les parents (lectures rapides), brut et en pleine fidélité pour le ML.

une salle de courrier — le collecteur reçoit le courrier, Kafka est le tapis roulant, et chaque objet est copié sur deux étagères : un que les parents consultent d'un coup d'œil, et une que l'équipe ML fouille.

**Modèle mental :** une salle de courrier — le collecteur reçoit le courrier, Kafka est le tapis roulant, et chaque objet est copié sur deux étagères : un *tableau récapitulatif* que les parents consultent d'un coup d'œil, et une *archive complète* que l'équipe ML fouille.

## Chemin d'écriture (ingestion)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- **Le collecteur** reçoit des événements **en batch** via HTTP — le batching côté client transforme des centaines de millions de minuscules écritures en bien moins de requêtes.
- **Kafka** est le buffer durable : il absorbe les pics, découple les producteurs des consommateurs, et vous permet de **rejouer** (replay) l'historique quand le ML ajoute une feature ou que vous introduisez un nouveau rollup.
- **Le stream processor** lit Kafka une fois et écrit dans les deux sinks — append du brut vers le lake, upsert des rollups pour les rapports.

```js
// Un seul consumer lit Kafka une fois et écrit dans les DEUX sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // brut -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agrège -> OLAP (rapports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Chemin de lecture (serving)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

Les parents interrogent des **résumés pré-agrégés**, donc un rapport est un lookup par clé, jamais un scan sur des milliards de lignes. Le ML interroge le **lake brut**, en conservant chaque champ pour le feature engineering.

## La stack & pourquoi
- **Kafka** — buffer, découpler, replay.
- **ClickHouse / tables de résumé quotidiennes** — optimisé en lecture pour les dashboards des parents.
- **S3 + Parquet** — stockage brut peu coûteux, columnar et flexible pour le ML.
- **Schema registry** — impose le contrat d'événement pour que les producteurs ne puissent pas casser silencieusement les consommateurs.

## L'angle de l'entretien
L'examinateur cherche à savoir si vous séparez l'**ingestion optimisée en écriture du serving optimisé en lecture**, si vous évitez de scanner les événements bruts pour chaque rapport parent, et si vous conservez les données brutes pour le ML. **Mauvais :** « tout mettre dans Postgres et l'interroger ». **Bon :** buffer durable + deux chemins de serving + replay + un contrat de schéma, avec une idée de l'échelle.

## Compromis
La pré-agrégation donne des lectures instantanées mais fige les dimensions à l'avance ; le lake brut est flexible mais lent. Gardez les **deux** — la classique séparation write-once, read-many.

Chemin d'écriture (ingestion)

Chemin de lecture (serving)

La stack & pourquoi

L'angle de l'entretien

Compromis

Questions connexes