Proiectează un pipeline de tracking de evenimente cu volum mare pentru rapoarte și ML — ce stivă tehnologică?

Question

IT Interview Practice · Accepted Answer

La sute de milioane de evenimente/zi (~câteva mii/sec, mai mult la vârfuri) mișcarea câștigătoare este să decuplezi ingestia de servire: absoarbe scrierile într-un log durabil, procesează stream-ul o singură dată și distribuie către două store-uri optimizate pentru sarcini opuse — pre-agregat pentru părinți (citiri rapide), brut și cu fidelitate completă pentru ML.

o cameră de corespondență — colectorul primește poșta, Kafka este banda transportoare, iar fiecare articol este copiat pe două rafturi: un la care părinții aruncă o privire și o pe care echipa de ML o cercetează.

**Model mental:** o cameră de corespondență — colectorul primește poșta, Kafka este banda transportoare, iar fiecare articol este copiat pe două rafturi: un *panou de sumar* la care părinții aruncă o privire și o *arhivă completă* pe care echipa de ML o cercetează.

## Calea de scriere (ingest)

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

- **Collector** preia evenimente **grupate în batch** prin HTTP — gruparea pe client transformă sute de milioane de scrieri minuscule în mult mai puține cereri.
- **Kafka** este buffer-ul durabil: absoarbe vârfurile, decuplează producătorii de consumatori și îți permite să faci **replay** al istoricului când ML adaugă o caracteristică sau introduci un nou rollup.
- **Stream processor** citește Kafka o singură dată și scrie în ambele sink-uri — append brut în lake, upsert rollups pentru rapoarte.

```js
// Un singur consumer citește Kafka o dată și scrie în AMBELE sink-uri
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // brut -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// agregat -> OLAP (rapoarte)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Calea de citire (servire)

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

Părinții accesează **sumare pre-agregate**, așa că un raport este o căutare după cheie, niciodată un scan peste miliarde de rânduri. ML interoghează **lake-ul brut**, păstrând fiecare câmp pentru feature engineering.

## Stiva și de ce
- **Kafka** — buffer, decuplare, replay.
- **ClickHouse / tabele de sumar zilnic** — optimizate pentru citire pentru dashboard-urile părinților.
- **S3 + Parquet** — stocare brută ieftină, coloană, flexibilă pentru ML.
- **Schema registry** — impune contractul de eveniment astfel încât producătorii să nu poată strica în tăcere consumatorii.

## Perspectiva de interviu
Intervievatorul verifică dacă separi **ingestia optimizată pentru scriere de servirea optimizată pentru citire**, dacă eviți scanarea evenimentelor brute pentru fiecare raport al părintelui și dacă păstrezi datele brute pentru ML. **Slab:** „pune totul în Postgres și interoghează.” **Puternic:** buffer durabil + două căi de servire + replay + un contract de schema, cu simțul scalei.

## Compromisuri
Pre-agregarea oferă citiri instantanee, dar fixează dimensiunile din start; lake-ul brut este flexibil, dar lent. Păstrează-le pe **ambele** — clasica separare write-once, read-many.

Calea de scriere (ingest)

Calea de citire (servire)

Stiva și de ce

Perspectiva de interviu

Compromisuri

Întrebări conexe