Design en høyvolums event-tracking-pipeline for rapporter og ML — hvilken stack?

Question

IT Interview Practice · Accepted Answer

Ved hundrevis av millioner events/dag (~noen få tusen/sek, høyere ved topper) er det vinnende trekket å koble ingest fra serving: absorber writes inn i en durabel log, prosesser strømmen én gang, og fan ut til to lagre tunet for motsatte jobber — pre-aggregert for foreldre (raske reads), rå og full-fidelity for ML.

et postrom — collectoren mottar post, Kafka er samlebåndet, og hvert element kopieres til to hyller: en foreldre kaster et blikk på, og et ML-teamet graver i.

**Mental modell:** et postrom — collectoren mottar post, Kafka er samlebåndet, og hvert element kopieres til to hyller: en *oppsummeringstavle* foreldre kaster et blikk på, og et *fullt arkiv* ML-teamet graver i.

## Write-vei (ingest)

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

- **Collector** tar imot **batchede** events over HTTP — batching på klienten gjør hundrevis av millioner små writes til langt færre requests.
- **Kafka** er den durable bufferen: den absorberer topper, kobler produsenter fra konsumenter, og lar deg **replaye** historikk når ML legger til en feature eller du innfører en ny rollup.
- **Stream-prosessoren** leser Kafka én gang og skriver til begge sinks — append rå til lake, upsert rollups for rapporter.

```js
// Én consumer leser Kafka én gang og skriver til BEGGE sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // rå -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggreger -> OLAP (rapporter)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read-vei (serving)

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

Foreldre treffer **pre-aggregerte oppsummeringer**, så en rapport er et key-oppslag, aldri en scan over milliarder av rader. ML spør mot **rå-laken**, og beholder hvert felt for feature engineering.

## Stack & hvorfor
- **Kafka** — buffer, dekobling, replay.
- **ClickHouse / daglige oppsummeringstabeller** — read-optimert for foreldre-dashboards.
- **S3 + Parquet** — billig, kolonnebasert, fleksibel rålagring for ML.
- **Schema registry** — håndhev event-kontrakten så produsenter ikke kan bryte konsumenter stille.

## Intervjuperspektiv
Intervjueren undersøker om du separerer **write-optimert ingest fra read-optimert serving**, unngår å scanne rå events for hver foreldrerapport, og beholder rådata for ML. **Svakt:** «legg alt i Postgres og spør på det.» **Sterkt:** durabel buffer + to serving-veier + replay + en schema-kontrakt, med en følelse for skalaen.

## Avveininger
Pre-aggregering gir øyeblikkelige reads, men fastsetter dimensjonene på forhånd; rå-laken er fleksibel, men treg. Behold **begge** — den klassiske write-once, read-many-splitten.

Write-vei (ingest)

Read-vei (serving)

Stack & hvorfor

Intervjuperspektiv

Avveininger

Relaterte spørsmål