Σχεδιάστε ένα high-volume event-tracking pipeline για reports και ML — ποιο stack;

Question

IT Interview Practice · Accepted Answer

Στα εκατοντάδες εκατομμύρια events/ημέρα (~μερικές χιλιάδες/δευτερόλεπτο, υψηλότερα στις αιχμές) η νικηφόρα κίνηση είναι να αποσυνδέσετε το ingestion από το serving: απορροφήστε τα writes σε ένα durable log, επεξεργαστείτε το stream μία φορά, και κάντε fan out σε δύο stores ρυθμισμένα για αντίθετες δουλειές — pre-aggregated για τους γονείς (γρήγορα reads), raw και πλήρους πιστότητας για ML.

ένα mailroom — ο collector παραλαμβάνει την αλληλογραφία, το Kafka είναι ο μεταφορικός ιμάντας, και κάθε αντικείμενο αντιγράφεται σε δύο ράφια: έναν που κοιτάζουν οι γονείς με μια ματιά, και ένα στο οποίο σκάβει η ομάδα ML.

**Νοητικό μοντέλο:** ένα mailroom — ο collector παραλαμβάνει την αλληλογραφία, το Kafka είναι ο μεταφορικός ιμάντας, και κάθε αντικείμενο αντιγράφεται σε δύο ράφια: έναν *summary board* που κοιτάζουν οι γονείς με μια ματιά, και ένα *πλήρες αρχείο* στο οποίο σκάβει η ομάδα ML.

## Write path (ingest)

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

- **Collector** παίρνει **batched** events μέσω HTTP — το batching στον client μετατρέπει εκατοντάδες εκατομμύρια μικροσκοπικά writes σε πολύ λιγότερα requests.
- **Kafka** είναι ο durable buffer: απορροφά τις αιχμές, αποσυνδέει τους producers από τους consumers, και σας επιτρέπει να κάνετε **replay** το ιστορικό όταν το ML προσθέτει ένα feature ή εισάγετε ένα νέο rollup.
- **Stream processor** διαβάζει το Kafka μία φορά και γράφει και στα δύο sinks — append το raw στο lake, upsert τα rollups για τα reports.

```js
// Ένας consumer διαβάζει το Kafka μία φορά και γράφει ΚΑΙ ΣΤΑ ΔΥΟ sinks
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();
}
```

## Read path (serving)

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

Οι γονείς χτυπούν **pre-aggregated summaries**, οπότε ένα report είναι ένα key lookup, ποτέ ένα scan πάνω σε δισεκατομμύρια γραμμές. Το ML κάνει query το **raw lake**, κρατώντας κάθε πεδίο για feature engineering.

## Stack & γιατί
- **Kafka** — buffer, decouple, replay.
- **ClickHouse / daily summary tables** — read-optimized για dashboards γονέων.
- **S3 + Parquet** — φθηνό, columnar, ευέλικτο raw storage για ML.
- **Schema registry** — επιβάλλει το event contract ώστε οι producers να μην μπορούν να σπάσουν σιωπηλά τους consumers.

## Interview lens
Ο interviewer διερευνά αν διαχωρίζετε το **write-optimized ingest από το read-optimized serving**, αποφεύγετε το scan raw events για κάθε report γονέα, και κρατάτε raw data για ML. **Αδύναμη:** "βάλ' τα όλα στην Postgres και κάνε query." **Δυνατή:** durable buffer + δύο serving paths + replay + ένα schema contract, με αίσθηση της κλίμακας.

## Trade-offs
Το pre-aggregation δίνει άμεσα reads αλλά κλειδώνει τις διαστάσεις εκ των προτέρων· το raw lake είναι ευέλικτο αλλά αργό. Κρατήστε **και τα δύο** — το κλασικό split write-once, read-many.

Write path (ingest)

Read path (serving)

Stack & γιατί

Interview lens

Trade-offs

Σχετικές ερωτήσεις