Eine hochvolumige Event-Tracking-Pipeline für Reports und ML entwerfen — welcher Stack?

Question

IT Interview Practice · Accepted Answer

Bei Hunderten Millionen Events/Tag (~ein paar Tausend/Sek., in Spitzen höher) ist der entscheidende Zug, Ingestion vom Serving zu entkoppeln: Writes in ein durables Log aufnehmen, den Stream einmal verarbeiten und auf zwei für gegensätzliche Aufgaben getunte Stores fächern — vorab aggregiert für Eltern (schnelle Reads), roh und in voller Detailtreue für ML.

eine Poststelle — der Collector nimmt die Post entgegen, Kafka ist das Förderband, und jedes Stück wird auf zwei Regale kopiert: eine , auf die Eltern einen Blick werfen, und ein , das das ML-Team durchwühlt.

**Mentales Modell:** eine Poststelle — der Collector nimmt die Post entgegen, Kafka ist das Förderband, und jedes Stück wird auf zwei Regale kopiert: eine *Übersichtstafel*, auf die Eltern einen Blick werfen, und ein *Vollarchiv*, das das ML-Team durchwühlt.

## Write-Pfad (Ingest)

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

- **Collector** nimmt **gebündelte** Events über HTTP entgegen — Batching auf dem Client verwandelt Hunderte Millionen winziger Writes in weit weniger Requests.
- **Kafka** ist der durable Buffer: Er absorbiert Spikes, entkoppelt Producer von Consumer und lässt dich die Historie **replayen**, wenn ML ein Feature hinzufügt oder du ein neues Rollup einführst.
- **Stream-Prozessor** liest Kafka einmal und schreibt in beide Sinks — hänge Rohdaten an den Lake an, upserte Rollups für Reports.

```js
// Ein Consumer liest Kafka einmal und schreibt in BEIDE Sinks
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // roh -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregieren -> OLAP (Reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read-Pfad (Serving)

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

Eltern treffen auf **vorab aggregierte Summaries**, sodass ein Report ein Key-Lookup ist, niemals ein Scan über Milliarden von Zeilen. ML fragt den **Roh-Lake** ab und behält jedes Feld für Feature Engineering.

## Stack & warum
- **Kafka** — Buffer, Entkopplung, Replay.
- **ClickHouse / tägliche Summary-Tabellen** — read-optimiert für Eltern-Dashboards.
- **S3 + Parquet** — günstiger, spaltenorientierter, flexibler Rohspeicher für ML.
- **Schema Registry** — erzwingt den Event-Contract, damit Producer Consumer nicht still und heimlich brechen können.

## Interview-Perspektive
Der Interviewer prüft, ob du **write-optimierten Ingest von read-optimiertem Serving** trennst, das Scannen von Rohevents für jeden Eltern-Report vermeidest und Rohdaten für ML behältst. **Schwach:** "alles in Postgres packen und abfragen." **Stark:** durabler Buffer + zwei Serving-Pfade + Replay + ein Schema-Contract, mit einem Gespür für die Größenordnung.

## Trade-offs
Vorab-Aggregation liefert sofortige Reads, legt aber die Dimensionen im Voraus fest; der Roh-Lake ist flexibel, aber langsam. Behalte **beide** — der klassische Write-once-, Read-many-Split.

Write-Pfad (Ingest)

Read-Pfad (Serving)

Stack & warum

Interview-Perspektive

Trade-offs

Ähnliche Fragen