Navrhni pipeline pro sledování událostí ve velkém objemu pro reporty a ML — jaký stack?

Question

IT Interview Practice · Accepted Answer

Při stovkách milionů událostí/den (~pár tisíc/s, ve špičkách víc) je vítězným tahem oddělit ingest od servírování: pohltit zápisy do trvanlivého logu, zpracovat stream jednou a rozvětvit do dvou úložišť vyladěných na opačné úlohy — předagregovaná pro rodiče (rychlé čtení), surová a v plné věrnosti pro ML.

podatelna — collector přijímá poštu, Kafka je dopravní pás a každá položka se kopíruje na dvě police: , na kterou rodiče mrknou, a , ve kterém se prohrabuje ML tým.

**Mentální model:** podatelna — collector přijímá poštu, Kafka je dopravní pás a každá položka se kopíruje na dvě police: *souhrnnou tabuli*, na kterou rodiče mrknou, a *úplný archiv*, ve kterém se prohrabuje ML tým.

## Zápisová cesta (ingest)

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

- **Collector** přijímá **dávkované** události přes HTTP — dávkování na klientovi promění stovky milionů drobných zápisů v mnohem méně požadavků.
- **Kafka** je trvanlivý buffer: pohltí špičky, oddělí producenty od konzumentů a umožní ti **replay** historie, když ML přidá feature nebo zavedeš nový rollup.
- **Stream processor** čte Kafku jednou a zapisuje do obou sinků — připojí surová data do lake, upsertuje rollupy pro reporty.

```js
// Jeden konzument čte Kafku jednou a zapisuje do OBOU sinků
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // surová -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agregace -> OLAP (reporty)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Čtecí cesta (servírování)

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

Rodiče sáhnou na **předagregované souhrny**, takže report je vyhledání podle klíče, nikdy scan přes miliardy řádků. ML se dotazuje na **surové lake** a zachovává si každé pole pro feature engineering.

## Stack & proč
- **Kafka** — buffer, oddělení, replay.
- **ClickHouse / denní souhrnné tabulky** — optimalizované pro čtení pro dashboardy rodičů.
- **S3 + Parquet** — levné, sloupcové, flexibilní surové úložiště pro ML.
- **Schema registry** — vynucení kontraktu události, aby producenti nemohli tiše rozbít konzumenty.

## Pohled tazatele
Tazatel zkoumá, zda oddělíš **ingest optimalizovaný pro zápis od servírování optimalizovaného pro čtení**, vyhneš se scanování surových událostí u každého reportu rodiče a ponecháš si surová data pro ML. **Slabě:** „dej to všechno do Postgresu a dotazuj se." **Silně:** trvanlivý buffer + dvě servírovací cesty + replay + schema kontrakt, s citem pro měřítko.

## Kompromisy
Předagregace dává okamžité čtení, ale fixuje dimenze předem; surové lake je flexibilní, ale pomalé. Ponech si **oba** — klasické rozdělení write-once, read-many.

Zápisová cesta (ingest)

Čtecí cesta (servírování)

Stack & proč

Pohled tazatele

Kompromisy

Související otázky