Suprojektuokite didelės apimties įvykių sekimo pipeline ataskaitoms ir ML — kokį stack?

Question

IT Interview Practice · Accepted Answer

Esant šimtams milijonų įvykių per dieną (~keli tūkstančiai/sek., daugiau piko metu), laimintis žingsnis yra atskirti priėmimą nuo serviravimo: sugerkite rašymus į patvarų log, apdorokite srautą vieną kartą ir išskirstykite į dvi saugyklas, suderintas priešingiems darbams — iš anksto agreguota tėvams (greiti skaitymai), neapdorota ir pilno tikslumo ML.

pašto skyrius — kolektorius priima paštą, Kafka yra konvejerio juosta, ir kiekvienas daiktas nukopijuojamas ant dviejų lentynų: , į kurią tėvai žvilgteli, ir , kurį ML komanda kapstosi.

**Mąstymo modelis:** pašto skyrius — kolektorius priima paštą, Kafka yra konvejerio juosta, ir kiekvienas daiktas nukopijuojamas ant dviejų lentynų: *santraukos lenta*, į kurią tėvai žvilgteli, ir *pilnas archyvas*, kurį ML komanda kapstosi.

## Rašymo kelias (ingest)

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

- **Collector** priima **sudėtus į batch** įvykius per HTTP — batching kliento pusėje šimtus milijonų mažyčių rašymų paverčia gerokai mažiau užklausų.
- **Kafka** yra patvarus buffer: sugeria pikus, atsieja producerius nuo consumerių ir leidžia **replay** istoriją, kai ML prideda feature arba įvedate naują rollup.
- **Stream procesorius** perskaito Kafka vieną kartą ir rašo į abu sinkus — prideda raw į ežerą, upsert'ina rollups ataskaitoms.

```js
// Vienas consumeris skaito Kafka vieną kartą ir rašo į ABU sinkus
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();
}
```

## Skaitymo kelias (serviravimas)

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

Tėvai kreipiasi į **iš anksto agreguotas santraukas**, todėl ataskaita yra rakto paieška, niekada ne skenavimas per milijardus eilučių. ML užklausia **raw ežerą**, išlaikydama kiekvieną lauką feature engineering.

## Stack ir kodėl
- **Kafka** — buffer, atsiejimas, replay.
- **ClickHouse / dienos santraukų lentelės** — skaitymui optimizuota tėvų dashboard'ams.
- **S3 + Parquet** — pigi, stulpelinė, lanksti raw saugykla ML.
- **Schema registry** — įtvirtina įvykių kontraktą, kad producer'iai negalėtų tyliai sulaužyti consumer'ių.

## Interviu perspektyva
Interviuotojas tikrina, ar atskiriate **rašymui optimizuotą ingest nuo skaitymui optimizuoto serviravimo**, vengiate skenuoti raw įvykius kiekvienai tėvų ataskaitai ir išlaikote raw duomenis ML. **Silpnas:** „sudėk viską į Postgres ir užklausk." **Stiprus:** patvarus buffer + du serviravimo keliai + replay + schema kontraktas, su masto pajautimu.

## Kompromisai
Iš anksto agregavimas duoda momentinius skaitymus, bet fiksuoja dimensijas iš anksto; raw ežeras lankstus, bet lėtas. Išlaikykite **abu** — klasikinis write-once, read-many padalijimas.

Rašymo kelias (ingest)

Skaitymo kelias (serviravimas)

Stack ir kodėl

Interviu perspektyva

Kompromisai

Susiję klausimai