レポートと ML のための大量イベントトラッキングパイプラインを設計してください — どんなスタックにしますか？

Question

IT Interview Practice · Accepted Answer

1 日あたり数億 events（毎秒 ~数千、ピーク時はさらに多い）では、勝ち筋は 取り込み（ingestion）を配信（serving）から decouple する ことだ。書き込みを durable な log に吸収し、stream を 一度だけ 処理して、正反対の仕事に合わせた 2 つのストア に fan out する — 親向けには pre-aggregated（高速な読み込み）、ML 向けには raw かつ full-fidelity。

メールルーム — collector が郵便を受け取り、Kafka がベルトコンベア、そして各アイテムが 2 つの棚にコピーされる。親がちらっと見ると、ML チームが掘り下げるだ。

**メンタルモデル:** メールルーム — collector が郵便を受け取り、Kafka がベルトコンベア、そして各アイテムが 2 つの棚にコピーされる。親がちらっと見る *サマリーボード* と、ML チームが掘り下げる *完全なアーカイブ* だ。

## 書き込みパス（取り込み）

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

- **Collector** は HTTP で **batch 化された** events を受け取る — クライアント側の batch 化により、数億の小さな書き込みがはるかに少ないリクエストになる。
- **Kafka** は durable な buffer だ。スパイクを吸収し、producer を consumer から decouple し、ML が feature を追加したり新しい rollup を導入したりしたときに履歴を **replay** できるようにする。
- **Stream processor** は Kafka を一度読み、両方の sink に書く — raw を lake に append し、reports 用に rollup を upsert する。

```js
// 1 つの 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) },// aggregate -> OLAP (reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## 読み込みパス（配信）

```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 なサマリー** にアクセスするので、report は key lookup であり、数十億行の scan には決してならない。ML は **raw な lake** を query し、feature engineering のためにすべての field を保持する。

## スタックとその理由
- **Kafka** — buffer、decouple、replay。
- **ClickHouse / 日次サマリーテーブル** — 親の dashboard 向けに読み込み最適化。
- **S3 + Parquet** — ML 向けに安価・カラムナ・柔軟な raw ストレージ。
- **Schema registry** — event contract を強制し、producer が consumer を静かに壊せないようにする。

## 面接の視点
面接官は、あなたが **書き込み最適化の ingest を読み込み最適化の serving から** 分離するか、親の report ごとに raw events を scan するのを避けるか、ML 用に raw データを保持するかを見ている。**弱い:**「全部 Postgres に入れて query する」。**強い:** durable な buffer + 2 つの serving パス + replay + schema contract、そして規模感を伴うこと。

## トレードオフ
pre-aggregation は即座の読み込みを与えるが、dimensions を前もって固定する。raw な lake は柔軟だが遅い。**両方** を持て — 古典的な write-once, read-many の分割だ。

書き込みパス（取り込み）

読み込みパス（配信）

スタックとその理由

面接の視点

トレードオフ

関連する質問