Projekto një pipeline event-tracking me volum të lartë për raporte dhe ML — cili stack?

Question

IT Interview Practice · Accepted Answer

Në qindra miliona evente/ditë (~disa mijëra/sek, më lart në piqe) lëvizja fituese është të shkëpusësh ingestimin nga serving-u: thith shkrimet në një log të qëndrueshëm, procesoje stream-in një herë, dhe shpërndaji te dy store të përshtatur për punë të kundërta — të para-agreguar për prindërit (lexime të shpejta), të papërpunuar dhe me besnikëri të plotë për ML.

një dhomë poste — collector-i merr postën, Kafka është shiriti transportues, dhe çdo artikull kopjohet në dy rafte: një që prindërit e shohin me një shikim, dhe një në të cilin ekipi i ML gërmon.

**Modeli mendor:** një dhomë poste — collector-i merr postën, Kafka është shiriti transportues, dhe çdo artikull kopjohet në dy rafte: një *tabelë përmbledhëse* që prindërit e shohin me një shikim, dhe një *arkiv i plotë* në të cilin ekipi i ML gërmon.

## Rruga e shkrimit (ingest)

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

- **Collector-i** merr evente **në batch** përmes HTTP — batching-u në klient i kthen qindra miliona shkrime të vogla në shumë më pak kërkesa.
- **Kafka** është buffer-i i qëndrueshëm: thith piqet, shkëput producerat nga consumerat, dhe të lejon të **replay**-osh historikun kur ML shton një feature ose ti fut një rollup të ri.
- **Stream processor-i** lexon Kafka një herë dhe shkruan të dy sink-et — shton raw-in te liqeni, bën upsert të rollup-eve për raportet.

```js
// Një consumer lexon Kafka një herë dhe shkruan të DY sink-et
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) },// agrego -> OLAP (raporte)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Rruga e leximit (serving)

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

Prindërit godasin **përmbledhjet e para-agreguara**, kështu që një raport është një key lookup, kurrë një scan mbi miliarda rreshta. ML kërkon te **liqeni raw**, duke ruajtur çdo fushë për feature engineering.

## Stack-u & pse
- **Kafka** — buffer, shkëputje, replay.
- **ClickHouse / tabela përmbledhëse ditore** — të optimizuara për lexim për dashboard-et e prindërve.
- **S3 + Parquet** — ruajtje raw e lirë, kolonare, fleksibël për ML.
- **Schema registry** — imponon kontratën e eventit që producerat të mos mund të thyejnë consumerat në heshtje.

## Këndvështrimi i intervistës
Intervistuesi heton nëse e ndan **ingestin e optimizuar-për-shkrim nga serving-u i optimizuar-për-lexim**, shmang skanimin e eventeve raw për çdo raport prindi, dhe ruan të dhënat raw për ML. **E dobët:** "vëri të gjitha në Postgres dhe kërkoji." **E fortë:** buffer i qëndrueshëm + dy rrugë serving-u + replay + një kontratë schema, me një ndjenjë për shkallën.

## Kompromiset
Para-agregimi jep lexime të menjëhershme por i fikson dimensionet paraprakisht; liqeni raw është fleksibël por i ngadaltë. Mbaji **të dyja** — ndarja klasike write-once, read-many.

Rruga e shkrimit (ingest)

Rruga e leximit (serving)

Stack-u & pse

Këndvështrimi i intervistës

Kompromiset

Pyetje të ngjashme