这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据分析
场景
数据量增长后，产品部门需要数据分析。
Product Chat
周二 15:20
产
需求：
- 实时监控 API 调用量
- 统计用户增长趋势
- 分析 API 使用情况
- 生成数据报表
问题：
- MySQL 聚合查询太慢
- 数据量太大，统计困难
- 无法实时返回结果
解决方案
1. 实时统计系统
设计流程
1. 实时统计系统
- 步骤 1：完成日志落库、聚合任务或指标口径更新
- 步骤 2：准备采集字段、统计维度、存储位置和查询口径
- 步骤 3：采集日志、聚合指标或生成分析结果
- 步骤 4：校验报表结果、查询延迟和数据新鲜度
关注点：数据口径、查询延迟、存储成本和结果可信度。
2. 数据分析 API
设计流程
2. 数据分析 API
- 步骤 1：完成日志落库、聚合任务或指标口径更新
- 步骤 2：完成日志落库、聚合任务或指标口径更新
- 步骤 3：更新统计结果、查询索引或冷热数据位置
- 步骤 4：校验身份、密钥或权限
关注点：数据口径、查询延迟、存储成本和结果可信度。
3. 数据聚合任务
设计流程
3. 数据聚合任务
- 步骤 1：完成日志落库、聚合任务或指标口径更新
- 步骤 2：更新统计结果、查询索引或冷热数据位置
- 步骤 3：校验身份、密钥或权限
关注点：数据口径、查询延迟、存储成本和结果可信度。
练习
练习 1
产品经理想要“实时看每分钟 API 调用量”，但你发现完全实时的成本很高。你会怎么和他讨论这个需求？
参考答案 (3 个标签)
数据分析 实时性 成本权衡
先把“实时”问清楚。很多时候产品说实时，并不是要求每一条请求立刻进入报表，而是希望变化不要太滞后。
可以这样拆：
- 确认可接受延迟：是 1 秒、10 秒，还是 1 分钟内都可以。
- 确认使用场景：如果是运营看趋势，分钟级通常够用；如果是风控告警，可能要更快。
- 区分明细和指标：明细可以异步落库，指标可以先按分钟聚合。
- 先做低成本版本：从分钟级聚合开始，等确实需要秒级时再升级流式计算。
这类需求的关键不是炫技，而是用业务场景决定数据新鲜度，再用成本匹配方案。