2. 需求分析与架构设计：核心业务指标定义与数据流架构

说实话，很多团队做实时指标平台，一上来就撸代码。结果呢？做了三个月发现指标口径对不上，数据延迟扛不住，架构推倒重来。我见过不止一次了。

这一章，咱们先把地基打牢。核心就三件事：指标定义清楚、数据流画明白、技术选型不纠结。

2.1 核心业务指标定义：PV / UV / GMV

先别急着写代码。你想想看，业务方要的「实时」，到底是多少秒？指标口径是什么？

我习惯把指标分成三类：

• PV（Page View）：页面被请求的次数。每次刷新都算一次。
• UV（Unique Visitor）：独立访客数。按设备ID或用户ID去重。
• GMV（Gross Merchandise Volume）：成交总额。注意，是下单金额，不是支付金额。

我在项目中遇到过最坑的事：PV 和 UV 的窗口大小没统一。实时用 5 秒窗口，离线用 1 小时窗口，结果 UV 差了 30%。后来我们强制规定：所有实时指标窗口大小必须与离线一致，除非业务方明确接受差异。

指标	定义	去重维度	窗口建议	常见坑
PV	页面请求次数	无	1 分钟	爬虫流量未过滤
UV	独立访客数	设备ID / 用户ID	5 分钟	跨端去重丢失
GMV	下单金额	订单ID	1 分钟	退款订单未剔除

2.2 数据流架构设计：从埋点到展示

指标定义好了，接下来画数据流。说白了就是：数据从哪来，经过哪些处理，最后到哪去。

我一般画三层：

1. 采集层：客户端埋点、服务端日志、消息队列。
2. 计算层：实时流处理、离线批处理。
3. 存储与展示层：OLAP 引擎、API 网关、前端看板。

下面这张图，是我在多个项目中沉淀下来的标准架构。你直接拿去用，基本不会出大问题。

2.3 技术选型对比：Lambda vs Kappa

架构画完了，接下来选技术栈。这里有个经典选择题：Lambda 架构还是 Kappa 架构？

我直接说结论：

• Lambda 架构：实时 + 离线两条链路。适合对数据准确性要求极高、且实时和离线口径必须完全一致的场景。
• Kappa 架构：只用实时流处理，离线结果通过重放实时数据得到。适合对实时性要求高、且能接受一定延迟的场景。

你想想看，Lambda 架构维护成本高，两条链路要写两套代码。但 Kappa 架构对消息队列的存储和重放能力要求很高。

对比维度	Lambda 架构	Kappa 架构
代码维护	两套代码（实时 + 离线）	一套代码（实时）
数据一致性	高（离线兜底）	中（依赖重放）
实时性	秒级	秒级
存储成本	高（两份数据）	低（一份数据）
适用场景	金融、电商对账	监控、推荐、广告

2.4 模块划分：把架构拆成可落地的单元

架构选型定了，接下来拆模块。我习惯按职责划分：

• 数据接入模块：负责从 Kafka 消费数据，做简单的格式校验和清洗。
• 实时计算模块：负责 PV/UV/GMV 的实时聚合，窗口计算。
• 离线计算模块：负责小时级/天级的数据重算和修复。
• 存储模块：负责将计算结果写入 OLAP 引擎和缓存。
• 查询与展示模块：负责对外提供 API 和前端看板。

每个模块独立部署，通过消息队列或 RPC 通信。这样后期扩容、升级、故障隔离都方便。