Reka bentuk pipeline event-tracking bervolum tinggi untuk laporan dan ML — stack yang mana?

Question

IT Interview Practice · Accepted Answer

Pada ratusan juta event/hari (~beberapa ribu/saat, lebih tinggi pada waktu puncak) langkah menang ialah memisahkan ingestion daripada serving: serap writes ke dalam log tahan lasak, proses stream sekali sahaja, dan fan out ke dua store yang ditala untuk kerja bertentangan — pra-agregat untuk ibu bapa (bacaan pantas), mentah dan penuh-fideliti untuk ML.

sebuah bilik mel — collector menerima mel, Kafka ialah tali sawat penghantar, dan setiap item disalin ke dua rak: satu yang ibu bapa lihat sepintas lalu, dan satu yang pasukan ML gali.

**Model mental:** sebuah bilik mel — collector menerima mel, Kafka ialah tali sawat penghantar, dan setiap item disalin ke dua rak: satu *papan ringkasan* yang ibu bapa lihat sepintas lalu, dan satu *arkib penuh* yang pasukan ML gali.

## Laluan tulis (ingest)

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

- **Collector** mengambil event **ter-batch** melalui HTTP — batching pada klien menukar ratusan juta writes kecil menjadi jauh lebih sedikit request.
- **Kafka** ialah buffer tahan lasak: ia menyerap lonjakan, memisahkan producer daripada consumer, dan membolehkan anda **replay** sejarah apabila ML menambah feature atau anda memperkenalkan rollup baharu.
- **Stream processor** membaca Kafka sekali dan menulis kedua-dua sink — append mentah ke lake, upsert rollups untuk laporan.

```js
// Satu consumer membaca Kafka sekali dan menulis KEDUA-DUA sink
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // mentah -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agregat -> OLAP (laporan)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Laluan baca (serving)

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

Ibu bapa mengakses **ringkasan pra-agregat**, jadi satu laporan ialah lookup kunci, tidak pernah scan ke atas berbilion baris. ML query **lake mentah**, mengekalkan setiap medan untuk feature engineering.

## Stack & sebabnya
- **Kafka** — buffer, decouple, replay.
- **ClickHouse / jadual ringkasan harian** — dioptimumkan-baca untuk dashboard ibu bapa.
- **S3 + Parquet** — storan mentah murah, columnar, fleksibel untuk ML.
- **Schema registry** — kuatkuasakan kontrak event supaya producer tidak boleh senyap-senyap memecahkan consumer.

## Sudut pandang temu duga
Penemu duga menguji sama ada anda memisahkan **ingest dioptimumkan-tulis daripada serving dioptimumkan-baca**, mengelakkan scan event mentah untuk setiap laporan ibu bapa, dan mengekalkan data mentah untuk ML. **Lemah:** "masukkan semuanya ke Postgres dan query." **Kuat:** buffer tahan lasak + dua laluan serving + replay + kontrak schema, dengan naluri terhadap skalanya.

## Trade-off
Pra-agregat memberi bacaan segera tetapi menetapkan dimensi di awal; lake mentah fleksibel tetapi perlahan. Kekalkan **kedua-duanya** — pemisahan klasik write-once, read-many.

Laluan tulis (ingest)

Laluan baca (serving)

Stack & sebabnya

Sudut pandang temu duga

Trade-off

Soalan berkaitan