Zaprojektuj wysokowolumenowy pipeline śledzenia zdarzeń do raportów i ML — jaki stack?

Question

IT Interview Practice · Accepted Answer

Przy setkach milionów zdarzeń dziennie (~kilka tysięcy/s, więcej w szczytach) zwycięskim ruchem jest oddzielenie ingestu od serwowania: pochłoń zapisy do trwałego logu, przetwórz strumień raz i rozprowadź do dwóch stores dostrojonych do przeciwnych zadań — wstępnie zagregowanych dla rodziców (szybkie odczyty), surowych i o pełnej wierności dla ML.

kancelaria pocztowa — collector odbiera pocztę, Kafka jest taśmociągiem, a każda przesyłka jest kopiowana na dwie półki: , na którą rodzice zerkają, oraz , które przekopuje zespół ML.

**Model mentalny:** kancelaria pocztowa — collector odbiera pocztę, Kafka jest taśmociągiem, a każda przesyłka jest kopiowana na dwie półki: *tablicę podsumowań*, na którą rodzice zerkają, oraz *pełne archiwum*, które przekopuje zespół ML.

## Ścieżka zapisu (ingest)

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

- **Collector** przyjmuje zdarzenia w **batchach** przez HTTP — batchowanie po stronie klienta zamienia setki milionów drobnych zapisów w dużo mniej requestów.
- **Kafka** jest trwałym buforem: pochłania szczyty, oddziela producentów od konsumentów i pozwala **odtworzyć (replay)** historię, gdy ML dodaje feature albo wprowadzasz nowy rollup.
- **Stream processor** czyta Kafkę raz i zapisuje oba sinki — dopisuje raw do lake, upsertuje rollupy do raportów.

```js
// Jeden consumer czyta Kafkę raz i zapisuje OBA sinki
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) },// agregacja -> OLAP (raporty)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Ścieżka odczytu (serwowanie)

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

Rodzice trafiają na **wstępnie zagregowane podsumowania**, więc raport to lookup po kluczu, nigdy skan po miliardach wierszy. ML odpytuje **surowe lake**, zachowując każde pole do feature engineering.

## Stack i dlaczego
- **Kafka** — bufor, oddzielenie, replay.
- **ClickHouse / dzienne tabele podsumowań** — zoptymalizowane pod odczyt dla dashboardów rodziców.
- **S3 + Parquet** — tanie, kolumnowe, elastyczne surowe magazynowanie dla ML.
- **Schema registry** — wymusza kontrakt zdarzenia, aby producenci nie mogli po cichu zepsuć konsumentów.

## Perspektywa rozmowy
Prowadzący sprawdza, czy oddzielasz **ingest zoptymalizowany pod zapis od serwowania zoptymalizowanego pod odczyt**, unikasz skanowania surowych zdarzeń przy każdym raporcie rodzica i zachowujesz surowe dane dla ML. **Słabo:** „wrzuć to wszystko do Postgresa i odpytuj”. **Mocno:** trwały bufor + dwie ścieżki serwowania + replay + kontrakt schematu, z wyczuciem skali.

## Kompromisy
Wstępna agregacja daje natychmiastowe odczyty, ale ustala wymiary z góry; surowe lake jest elastyczne, ale wolne. Zachowaj **oba** — klasyczny podział write-once, read-many.

Ścieżka zapisu (ingest)

Ścieżka odczytu (serwowanie)

Stack i dlaczego

Perspektywa rozmowy

Kompromisy

Powiązane pytania