为报表和 ML 设计一个高吞吐量的事件追踪管道——用什么技术栈？

Question

IT Interview Practice · Accepted Answer

当每天有数亿个事件（约每秒几千个，峰值更高）时，制胜之举是**将写入摄取（ingestion）与对外服务（serving）解耦**：把写入吸收进一个持久化 log，把流**只处理一次**，然后扇出（fan out）到**两个为相反任务而调优的存储**——为家长预聚合（读取快），为 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** 通过 HTTP 接收**成批（batched）**的事件——在客户端做 batching 会把数亿次微小写入变成少得多的请求。
- **Kafka** 是持久化 buffer：它吸收尖峰、把生产者与消费者解耦，并让你在 ML 新增特征或你引入新 rollup 时**回放（replay）**历史。
- **Stream processor** 只读一次 Kafka 并写入两个 sink——把原始数据追加到 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) },// aggregate -> 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)
```

家长访问的是**预聚合的摘要**，所以一次报表就是一次键查找，绝不是对数十亿行的扫描。ML 查询**原始 lake**，为特征工程保留每一个字段。

## 技术栈与原因
- **Kafka**——buffer、解耦、replay。
- **ClickHouse / 每日汇总表**——为家长看板做读优化。
- **S3 + Parquet**——便宜、列式、灵活的原始存储，供 ML 使用。
- **Schema registry**——强制执行事件契约，让生产者无法悄无声息地破坏消费者。

## 面试视角
面试官在考察你是否把**写优化的 ingest 与读优化的 serving**分开、是否避免为每次家长报表都扫描原始事件，以及是否为 ML 保留原始数据。**弱：**"全放进 Postgres 然后查询它。"**强：**持久化 buffer + 两条服务路径 + replay + 一份 schema 契约，并对规模有直觉。

## 权衡
预聚合带来即时读取，但会预先固定维度；原始 lake 灵活但慢。**两者都保留**——这就是经典的一次写入、多次读取（write-once, read-many）拆分。

写入路径（ingest）

读取路径（serving）

技术栈与原因

面试视角

权衡

相关问题