Tervezz nagy volumenű eseménykövető pipeline-t jelentésekhez és ML-hez — milyen stack?

Question

IT Interview Practice · Accepted Answer

Napi több százmillió eventnél (~néhány ezer/mp, csúcson több) a nyerő lépés az ingest és a kiszolgálás szétválasztása: nyeld el az írásokat egy tartós logba, dolgozd fel a streamet egyszer, és ágaztasd szét két, ellentétes feladatra hangolt tárolóba — előre aggregálva a szülőknek (gyors olvasás), nyersen és teljes felbontásban az ML-nek.

egy postázó — a collector átveszi a postát, a Kafka a futószalag, és minden tétel két polcra másolódik: egy , amit a szülők átfutnak, és egy , amiben az ML csapat vájkál.

**Gondolati modell:** egy postázó — a collector átveszi a postát, a Kafka a futószalag, és minden tétel két polcra másolódik: egy *összefoglaló tábla*, amit a szülők átfutnak, és egy *teljes archívum*, amiben az ML csapat vájkál.

## Írási útvonal (ingest)

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

- **Collector** **batchelt** eventeket vesz át HTTP-n — a kliensoldali batchelés a több százmillió apró írást jóval kevesebb kéréssé alakítja.
- **Kafka** a tartós buffer: elnyeli a csúcsokat, szétválasztja a producereket a consumerektől, és lehetővé teszi a történelem **replay**-ét, amikor az ML új feature-t ad hozzá vagy új rollupot vezetsz be.
- **Stream processor** egyszer olvassa a Kafkát és mindkét sinkbe ír — nyerset a lake-be fűz, rollupokat upsertel a jelentésekhez.

```js
// Egy consumer egyszer olvassa a Kafkát és MINDKÉT sinkbe ír
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();
}
```

## Olvasási útvonal (kiszolgálás)

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

A szülők **előre aggregált összefoglalókat** érnek el, így egy jelentés kulcskeresés, sosem scan milliárdnyi soron. Az ML a **nyers lake-et** kérdezi le, minden mezőt megtartva a feature engineeringhez.

## Stack és miért
- **Kafka** — buffer, szétválasztás, replay.
- **ClickHouse / napi summary táblák** — olvasásra optimalizált a szülői dashboardokhoz.
- **S3 + Parquet** — olcsó, oszlopos, rugalmas nyers tároló az ML-nek.
- **Schema registry** — kényszeríti az event contractot, hogy a producerek ne törhessék csendben a consumereket.

## Interjú szemszögéből
A kérdező azt firtatja, szétválasztod-e az **írásra optimalizált ingestet az olvasásra optimalizált kiszolgálástól**, elkerülöd-e a nyers eventek scannelését minden szülői jelentéshez, és megtartod-e a nyers adatot az ML-nek. **Gyenge:** "tedd az egészet Postgresbe és kérdezd le." **Erős:** tartós buffer + két kiszolgálási útvonal + replay + egy schema contract, a méret érzékével.

## Kompromisszumok
Az előaggregálás azonnali olvasást ad, de előre rögzíti a dimenziókat; a nyers lake rugalmas, de lassú. Tartsd meg **mindkettőt** — a klasszikus írd-egyszer, olvasd-sokszor felosztás.

Írási útvonal (ingest)

Olvasási útvonal (kiszolgálás)

Stack és miért

Interjú szemszögéből

Kompromisszumok

Kapcsolódó kérdések