Design en high-volume event-tracking-pipeline til rapporter og ML — hvilken stack?

Question

IT Interview Practice · Accepted Answer

Ved hundredvis af millioner events/dag (~et par tusinde/sek, højere ved spidsbelastning) er det vindende træk at afkoble ingestion fra serving: absorbér writes ind i en durable log, processér streamen én gang, og fan ud til to stores tunet til modsatte jobs — præ-aggregeret til forældre (hurtige reads), rå og fuld-fidelitet til ML.

et postrum — collectoren modtager post, Kafka er transportbåndet, og hvert stykke kopieres til to hylder: en forældre kigger på, og et ML-teamet graver i.

**Mental model:** et postrum — collectoren modtager post, Kafka er transportbåndet, og hvert stykke kopieres til to hylder: en *summary board* forældre kigger på, og et *fuldt arkiv* ML-teamet graver i.

## Write path (ingest)

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

- **Collector** tager **batchede** events over HTTP — batching på klienten forvandler hundredvis af millioner af bittesmå writes til langt færre requests.
- **Kafka** er den durable buffer: den absorberer spikes, afkobler producers fra consumers, og lader dig **replaye** historik når ML tilføjer en feature eller du introducerer en ny rollup.
- **Stream-processor** læser Kafka én gang og skriver til begge sinks — append rå til lake'en, upsert rollups til rapporter.

```js
// Én consumer læser 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) },// aggregér -> OLAP (rapporter)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read path (serving)

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

Forældre rammer **præ-aggregerede summaries**, så en rapport er et key-opslag, aldrig en scan over milliarder af rækker. ML forespørger den **rå lake**, og beholder hvert felt til feature engineering.

## Stack & hvorfor
- **Kafka** — buffer, afkobl, replay.
- **ClickHouse / daglige summary-tabeller** — read-optimeret til forælder-dashboards.
- **S3 + Parquet** — billig, kolonneorienteret, fleksibel rå lagring til ML.
- **Schema registry** — håndhæv event-kontrakten så producers ikke stille kan bryde consumers.

## Interview lens
Intervieweren undersøger om du adskiller **write-optimeret ingest fra read-optimeret serving**, undgår at scanne rå events til hver forælder-rapport, og beholder rå data til ML. **Svagt:** "put det hele i Postgres og forespørg det." **Stærkt:** durable buffer + to serving-paths + replay + en schema-kontrakt, med fornemmelse for skalaen.

## Trade-offs
Præ-aggregering giver øjeblikkelige reads men fastlåser dimensionerne på forhånd; den rå lake er fleksibel men langsom. Behold **begge** — det klassiske write-once, read-many-split.

Write path (ingest)

Read path (serving)

Stack & hvorfor

Interview lens

Trade-offs

Relaterede spørgsmål