Designa en pipeline för händelsespårning med hög volym för rapporter och ML — vilken stack?

Question

IT Interview Practice · Accepted Answer

Vid hundratals miljoner händelser/dag (~några tusen/sek, högre vid toppar) är det vinnande draget att frikoppla ingestion från serving: absorbera skrivningar i en durable log, processa strömmen en gång, och fördela ut till två datalager finjusterade för motsatta jobb — föraggregerat för föräldrar (snabba läsningar), rått och fullständigt för ML.

ett postrum — collectorn tar emot post, Kafka är löpande bandet, och varje objekt kopieras till två hyllor: en som föräldrar ögnar igenom, och ett som ML-teamet gräver i.

**Mental modell:** ett postrum — collectorn tar emot post, Kafka är löpande bandet, och varje objekt kopieras till två hyllor: en *sammanfattningstavla* som föräldrar ögnar igenom, och ett *fullständigt arkiv* som ML-teamet gräver i.

## Skrivväg (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 **batchade** händelser över HTTP — batchning på klienten förvandlar hundratals miljoner små skrivningar till långt färre requests.
- **Kafka** är den durable buffern: den absorberar spikar, frikopplar producers från consumers, och låter dig **replay:a** historik när ML lägger till en feature eller du inför en ny rollup.
- **Stream processor** läser Kafka en gång och skriver till båda sinks — appendar rått till sjön, upsertar rollups för rapporter.

```js
// En consumer läser Kafka en gång och skriver till BÅDA sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // rått -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregera -> OLAP (rapporter)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Läsväg (serving)

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

Föräldrar träffar **föraggregerade sammanfattningar**, så en rapport är en nyckeluppslagning, aldrig en scan över miljarder rader. ML frågar den **råa sjön**, och behåller varje fält för feature engineering.

## Stack & varför
- **Kafka** — buffra, frikoppla, replay.
- **ClickHouse / dagliga summeringstabeller** — läsoptimerade för föräldradashboards.
- **S3 + Parquet** — billig, kolumnär, flexibel rålagring för ML.
- **Schema registry** — upprätthåll händelsekontraktet så att producers inte tyst kan bryta consumers.

## Intervjuperspektiv
Intervjuaren undersöker om du separerar **skrivoptimerad ingest från läsoptimerad serving**, undviker att scanna råa händelser för varje föräldrarapport, och behåller rådata för ML. **Svagt:** "lägg allt i Postgres och fråga det." **Starkt:** durable buffer + två serving-vägar + replay + ett schema-kontrakt, med en känsla för skalan.

## Avvägningar
Föraggregering ger omedelbara läsningar men fixerar dimensionerna på förhand; den råa sjön är flexibel men långsam. Behåll **båda** — den klassiska write-once, read-many-uppdelningen.

Skrivväg (ingest)

Läsväg (serving)

Stack & varför

Intervjuperspektiv

Avvägningar

Relaterade frågor