对每天数百万笔交易做实时营收分析：怎么做？

Question

IT Interview Practice · Accepted Answer

**把交易通过 Kafka 流式送入一个流处理器（stream processor），它预聚合到一个 OLAP 存储中，这样仪表盘读取的是微小的预计算汇总（rollup），而不是扫描原始事件。**在每天数百万笔交易下，你绝不会在每次页面加载时对原始表跑 `SUM()`——你在写入时聚合一次。

## 架构

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## 工作原理

- **Kafka** 是持久日志。每笔支付发布一个事件（`amount`、`currency`、`ts`、`merchant`）。它缓冲尖峰、把生产者与消费者解耦，并让你**重放（replay）**历史以重建聚合。
- **流处理器（Flink / Kafka Streams）**维护**滚动/滑动窗口（tumbling/sliding windows）**（按分钟/小时），并把每个事件累加进其**状态存储（state store）**中的运行总数。输出是每个 (分钟, 维度) 一行的预聚合结果。
- **OLAP 存储（ClickHouse、Druid、Pinot）**以列式存储这些 rollup。查询"过去 24 小时营收"的仪表盘扫描约 1,440 行，而非数百万行——亚秒级。
- ClickHouse 中的**物化视图（Materialized views）**可以在 DB 内部做同样的 rollup（`AggregatingMergeTree`），如果你想要更少的活动部件。

## 面试视角

面试官考察你是**在写入时预聚合还是在读取时扫描**，以及你是否理解 **exactly-once**。好的回答会指出 Kafka + OLAP；出色的回答会解释**为什么迟到/重复事件会破坏总数**以及如何修复：幂等键、用于 exactly-once 的 Flink **checkpointing + 事务性 sink**，以及用于在有迟到到达时仍关闭窗口的**水位线（watermarks）**。一个常见陷阱是提议在 Postgres 上 `SELECT SUM()`——在每天数千笔时没问题，但在数百万笔时会崩溃。

## 权衡与故障

- **Lambda 与 Kappa。**Lambda 在流层（快但近似）旁边再跑一个批处理层（夜间 Spark 对齐真实来源）——准确但有两套代码库。**Kappa** 只使用流层，并**重放 Kafka** 来修复 bug——更简单、一套代码库，如今是常见的默认选择。
- **Exactly-once 不是免费的。**事务性 sink 增加 latency 和 throughput 成本；许多团队转而接受以 `txn_id` 为键的 **at-least-once + 幂等 upsert**。
- **迟到数据。**一笔延迟 2 小时结算的支付会在其窗口关闭之后到达。水位线 + 允许迟到（allowed-lateness）会重新打开窗口，或由夜间批处理作业修正昨天的数字。
- **多币种 / 退款**必须建模为带符号的事件，否则"营收"会漂移。
- **何时不该用：**每天几千笔交易根本不需要这些——一张由 cron 更新的 Postgres rollup 表，胜过一个你还得运维的 Kafka+Flink 集群。

架构

工作原理

面试视角

权衡与故障

相关问题