Progetta una pipeline di event-tracking ad alto volume per report e ML — quale stack?

Question

IT Interview Practice · Accepted Answer

A centinaia di milioni di eventi/giorno (~qualche migliaio/sec, di più nei picchi) la mossa vincente è disaccoppiare l'ingestione dal serving: assorbi le scritture in un log durevole, elabora lo stream una volta e distribuisci verso due store ottimizzati per lavori opposti — pre-aggregato per i genitori (letture veloci), grezzo e a piena fedeltà per l'ML.

una sala posta — il collector riceve la posta, Kafka è il nastro trasportatore, e ogni elemento viene copiato su due scaffali: una che i genitori scorrono, e un che il team ML scava.

**Modello mentale:** una sala posta — il collector riceve la posta, Kafka è il nastro trasportatore, e ogni elemento viene copiato su due scaffali: una *bacheca riassuntiva* che i genitori scorrono, e un *archivio completo* che il team ML scava.

## Percorso di scrittura (ingest)

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

- **Collector** riceve eventi **in batch** su HTTP — il batching sul client trasforma centinaia di milioni di scritture minuscole in molte meno richieste.
- **Kafka** è il buffer durevole: assorbe i picchi, disaccoppia i producer dai consumer e ti permette di fare **replay** della storia quando l'ML aggiunge una feature o introduci un nuovo rollup.
- **Stream processor** legge Kafka una volta e scrive entrambi i sink — append del grezzo nel lake, upsert dei rollup per i report.

```js
// Un consumer legge Kafka una volta e scrive su ENTRAMBI i sink
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // raw -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregate -> OLAP (reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Percorso di lettura (serving)

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

I genitori colpiscono **riepiloghi pre-aggregati**, quindi un report è una lookup per chiave, mai uno scan su miliardi di righe. L'ML interroga il **lake grezzo**, mantenendo ogni campo per il feature engineering.

## Stack e perché
- **Kafka** — buffer, disaccoppiamento, replay.
- **ClickHouse / tabelle di riepilogo giornaliere** — ottimizzate in lettura per le dashboard dei genitori.
- **S3 + Parquet** — storage grezzo economico, colonnare e flessibile per l'ML.
- **Schema registry** — impone il contratto degli eventi così i producer non possono rompere silenziosamente i consumer.

## Ottica del colloquio
L'intervistatore verifica se separi **l'ingest ottimizzato in scrittura dal serving ottimizzato in lettura**, eviti di scansionare eventi grezzi per ogni report dei genitori, e conservi i dati grezzi per l'ML. **Debole:** "metti tutto in Postgres e interrogalo." **Forte:** buffer durevole + due percorsi di serving + replay + un contratto di schema, con il senso della scala.

## Compromessi
La pre-aggregazione dà letture istantanee ma fissa le dimensioni a monte; il lake grezzo è flessibile ma lento. Tieni **entrambi** — la classica divisione scrivi-una-volta, leggi-molte.

Percorso di scrittura (ingest)

Percorso di lettura (serving)

Stack e perché

Ottica del colloquio

Compromessi

Domande correlate