Raporlar ve ML için yüksek hacimli bir olay izleme (event-tracking) hattı tasarlayın — hangi stack?

Question

IT Interview Practice · Accepted Answer

Günde yüz milyonlarca olay (~saniyede birkaç bin, zirvelerde daha fazla) ölçeğinde kazanan hamle, veri alımını (ingestion) sunumdan (serving) ayırmaktır: yazımları dayanıklı bir log'a emin, akışı bir kez işleyin ve zıt işler için ayarlanmış iki depoya dağıtın — ebeveynler için önceden toplanmış (hızlı okuma), ML için ham ve tam sadakatli.

bir posta odası — toplayıcı postayı alır, Kafka taşıma bandıdır ve her öğe iki rafa kopyalanır: ebeveynlerin göz attığı bir ve ML ekibinin araştırdığı bir .

**Zihinsel model:** bir posta odası — toplayıcı postayı alır, Kafka taşıma bandıdır ve her öğe iki rafa kopyalanır: ebeveynlerin göz attığı bir *özet panosu* ve ML ekibinin araştırdığı bir *tam arşiv*.

## Yazma yolu (ingest)

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

- **Collector** HTTP üzerinden **batch'lenmiş** olayları alır — istemcide batch'leme yüz milyonlarca küçük yazımı çok daha az isteğe dönüştürür.
- **Kafka** dayanıklı buffer'dır: ani yükselmeleri emer, üreticileri tüketicilerden ayırır ve ML bir özellik eklediğinde veya yeni bir rollup tanıttığınızda geçmişi **replay** etmenizi sağlar.
- **Stream processor** Kafka'yı bir kez okur ve her iki hedefe de yazar — göle ham veriyi append eder, raporlar için rollup'ları upsert eder.

```js
// Bir tüketici Kafka'yı bir kez okur ve HER İKİ hedefe yazar
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();
}
```

## Okuma yolu (serving)

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

Ebeveynler **önceden toplanmış özetlere** erişir, bu yüzden bir rapor bir anahtar araması olur, asla milyarlarca satır üzerinde bir tarama değil. ML **ham göle** sorgu atar, özellik mühendisliği için her alanı saklar.

## Stack & neden
- **Kafka** — buffer, ayrıştırma, replay.
- **ClickHouse / günlük özet tabloları** — ebeveyn panoları için okuma-optimize.
- **S3 + Parquet** — ML için ucuz, kolonlu, esnek ham depolama.
- **Schema registry** — olay sözleşmesini zorunlu kıl, böylece üreticiler tüketicileri sessizce bozamaz.

## Mülakat merceği
Mülakatı yapan kişi, **yazma-optimize ingest'i okuma-optimize serving'den** ayırıp ayırmadığınızı, her ebeveyn raporu için ham olayları taramaktan kaçınıp kaçınmadığınızı ve ML için ham veriyi saklayıp saklamadığınızı araştırıyor. **Zayıf:** "hepsini Postgres'e koy ve sorgula." **Güçlü:** dayanıklı buffer + iki serving yolu + replay + bir schema sözleşmesi, ölçek hissiyle birlikte.

## Ödünleşimler
Önceden toplama anlık okuma sağlar ama boyutları önden sabitler; ham göl esnektir ama yavaştır. **Her ikisini** de tutun — klasik bir kez yaz, çok kez oku ayrımı.

Yazma yolu (ingest)

Okuma yolu (serving)

Stack & neden

Mülakat merceği

Ödünleşimler

İlgili sorular