შეიმუშავეთ დიდი მოცულობის event-tracking pipeline რეპორტებისა და ML-ისთვის — რომელი stack?

Question

IT Interview Practice · Accepted Answer

ასობით მილიონი event-ის დღეში (~რამდენიმე ათასი წამში, პიკებზე მეტი) მოცულობაზე მოგებული სვლა არის ingestion-ის serving-ისგან განცალკევება: შთანთქეთ writes გამძლე log-ში, დაამუშავეთ stream ერთხელ, და გაანაწილეთ ორ store-ზე, დაყენებული საპირისპირო სამუშაოებისთვის — წინასწარ აგრეგირებული მშობლებისთვის (სწრაფი reads), raw და სრული სიზუსტით ML-ისთვის.

საფოსტო ოთახი — collector იღებს ფოსტას, Kafka არის კონვეიერი, და ყოველი ერთეული კოპირდება ორ თაროზე: , რომელსაც მშობლები ხედავენ, და , რომელშიც ML გუნდი იქექება.

**აზროვნების მოდელი:** საფოსტო ოთახი — collector იღებს ფოსტას, Kafka არის კონვეიერი, და ყოველი ერთეული კოპირდება ორ თაროზე: *summary board*, რომელსაც მშობლები ხედავენ, და *full archive*, რომელშიც 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** იღებს **batch**-ებულ events-ს HTTP-ზე — კლიენტზე batching ასობით მილიონ პაწაწინა write-ს აქცევს ბევრად ნაკლებ მოთხოვნად.
- **Kafka** არის გამძლე buffer: ის შთანთქავს spikes-ს, განაცალკევებს producers-ს consumers-ისგან, და გაძლევთ საშუალებას **replay**-ს გააკეთოთ ისტორიისთვის, როცა ML ამატებს feature-ს ან შემოგაქვთ ახალი rollup.
- **Stream processor** კითხულობს Kafka-ს ერთხელ და წერს ორივე sink-ში — append raw lake-ში, upsert rollups რეპორტებისთვის.

```js
// ერთი consumer კითხულობს Kafka-ს ერთხელ და წერს ორივე 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) },// აგრეგაცია -> 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)
```

მშობლები მიმართავენ **წინასწარ აგრეგირებულ summaries**-ს, ამიტომ რეპორტი არის key lookup, არასდროს scan მილიარდობით row-ზე. ML ეკითხება **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 კონტრაქტს, ისე რომ producers-მა მდუმარედ ვერ გატეხოს consumers.

## ინტერვიუს პრიზმა
ინტერვიუერი ამოწმებს, აცალკევებთ თუ არა **write-optimized ingest-ს read-optimized serving-ისგან**, ერიდებით თუ არა raw events-ის scan-ს ყოველი მშობლის რეპორტისთვის, და ინახავთ თუ არა raw data-ს ML-ისთვის. **სუსტი:** „ჩადე ყველაფერი Postgres-ში და ეკითხე." **ძლიერი:** გამძლე buffer + ორი serving path + replay + schema კონტრაქტი, მასშტაბის შეგრძნებით.

## Trade-off-ები
წინასწარი აგრეგაცია იძლევა მყისიერ reads-ს, მაგრამ განზომილებებს ასწორებს წინასწარ; raw lake მოქნილია, მაგრამ ნელი. შეინახეთ **ორივე** — კლასიკური write-once, read-many გაყოფა.

Write path (ingest)

Read path (serving)

Stack და რატომ

ინტერვიუს პრიზმა

Trade-off-ები

დაკავშირებული კითხვები