Спроектируйте высоконагруженный pipeline трекинга событий для отчётов и ML — какой стек?

Question

IT Interview Practice · Accepted Answer

При сотнях миллионов событий в день (~несколько тысяч/сек, больше на пиках) выигрышный ход — отделить приём (ingestion) от отдачи (serving): поглощать записи в durable log, обрабатывать поток один раз и разветвлять на два хранилища, настроенных под противоположные задачи — предагрегированное для родителей (быстрые чтения) и сырое, полное по точности — для ML.

почтовая комната — collector принимает почту, Kafka — это конвейерная лента, и каждый предмет копируется на две полки: , на которую родители бросают взгляд, и , в котором копается ML-команда.

**Ментальная модель:** почтовая комната — collector принимает почту, Kafka — это конвейерная лента, и каждый предмет копируется на две полки: *сводная доска*, на которую родители бросают взгляд, и *полный архив*, в котором копается ML-команда.

## Путь записи (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** события по HTTP — батчинг на клиенте превращает сотни миллионов крошечных записей в гораздо меньшее число запросов.
- **Kafka** — это durable buffer: он поглощает всплески, отделяет producers от consumers и позволяет вам **replay** истории, когда ML добавляет фичу или вы вводите новый rollup.
- **Stream processor** читает Kafka один раз и пишет в оба sink — append сырых данных в lake, upsert rollups для отчётов.

```js
// Один consumer читает Kafka один раз и пишет в ОБА sink
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // сырые -> 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();
}
```

## Путь чтения (serving)

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

Родители обращаются к **предагрегированным сводкам**, поэтому отчёт — это key lookup, а не scan по миллиардам строк. ML запрашивает **сырой lake**, сохраняя каждое поле для feature engineering.

## Стек и почему
- **Kafka** — buffer, decouple, replay.
- **ClickHouse / таблицы дневных сводок** — оптимизированы под чтение для родительских дашбордов.
- **S3 + Parquet** — дешёвое, колоночное, гибкое сырое хранилище для ML.
- **Schema registry** — принудительно соблюдает контракт события, чтобы producers не могли молча сломать consumers.

## Взгляд интервьюера
Интервьюер проверяет, разделяете ли вы **write-optimized ingest от read-optimized serving**, избегаете ли scan сырых событий для каждого родительского отчёта и сохраняете ли сырые данные для ML. **Слабый:** «положить всё в Postgres и делать запросы». **Сильный:** durable buffer + два пути отдачи + replay + контракт схемы, с пониманием масштаба.

## Компромиссы
Предагрегация даёт мгновенные чтения, но фиксирует измерения заранее; сырой lake гибок, но медленный. Держите **оба** — классическое разделение write-once, read-many.

Путь записи (ingest)

Путь чтения (serving)

Стек и почему

Взгляд интервьюера

Компромиссы

Похожие вопросы