Rancang pipeline pelacakan event bervolume tinggi untuk laporan dan ML — stack mana?

Question

IT Interview Practice · Accepted Answer

Pada ratusan juta event/hari (~beberapa ribu/detik, lebih tinggi saat puncak) langkah pemenang adalah memisahkan ingestion dari serving: serap tulisan ke log yang durable, proses stream sekali, lalu sebarkan ke dua store yang disetel untuk pekerjaan berlawanan — pre-aggregated untuk orang tua (baca cepat), raw dan full-fidelity untuk ML.

ruang surat — collector menerima surat, Kafka adalah ban berjalan, dan tiap item disalin ke dua rak: yang dilirik orang tua, dan yang digali tim ML.

**Model mental:** ruang surat — collector menerima surat, Kafka adalah ban berjalan, dan tiap item disalin ke dua rak: *papan ringkasan* yang dilirik orang tua, dan *arsip lengkap* yang digali tim ML.

## Jalur 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** menerima event **batched** lewat HTTP — batching di klien mengubah ratusan juta tulisan kecil menjadi jauh lebih sedikit request.
- **Kafka** adalah buffer durable: menyerap lonjakan, memisahkan producer dari consumer, dan memungkinkan Anda **replay** riwayat saat ML menambah fitur atau Anda memperkenalkan rollup baru.
- **Stream processor** membaca Kafka sekali dan menulis kedua sink — append raw ke lake, upsert rollup untuk laporan.

```js
// Satu consumer membaca Kafka sekali dan menulis ke KEDUA sink
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();
}
```

## Jalur 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)
```

Orang tua mengenai **ringkasan pre-aggregated**, jadi sebuah laporan adalah key lookup, tak pernah scan miliaran baris. ML meng-query **raw lake**, menyimpan setiap field untuk feature engineering.

## Stack & alasannya
- **Kafka** — buffer, decouple, replay.
- **ClickHouse / tabel ringkasan harian** — dioptimalkan baca untuk dashboard orang tua.
- **S3 + Parquet** — murah, kolumnar, penyimpanan raw fleksibel untuk ML.
- **Schema registry** — menegakkan event contract agar producer tak diam-diam merusak consumer.

## Sudut pandang wawancara
Pewawancara menyelidiki apakah Anda memisahkan **ingest yang dioptimalkan tulis dari serving yang dioptimalkan baca**, menghindari scan raw event untuk tiap laporan orang tua, dan menyimpan data raw untuk ML. **Lemah:** "taruh semua di Postgres dan query." **Kuat:** buffer durable + dua jalur serving + replay + sebuah schema contract, dengan pemahaman skala.

## Trade-off
Pre-aggregation memberi baca instan tapi mengunci dimensi di awal; raw lake fleksibel tapi lambat. Simpan **keduanya** — pembagian klasik tulis-sekali, baca-banyak.

Jalur tulis (ingest)

Jalur baca (serving)

Stack & alasannya

Sudut pandang wawancara

Trade-off

Pertanyaan terkait