Bilibili Analyzer 的服务与数据模块划分
按数据流拆分采集、存储、计算、洞察和展示模块，减少服务之间的职责重叠。
架构数据工程FastAPI
解决的问题
Bilibili Analyzer 同时处理公开数据采集、快照存储、指标计算、趋势判断和前端展示。把这些工作放进同一个服务会让数据模型、任务调度和接口责任相互影响，因此按数据流拆分模块。
模块职责
系统分为采集、存储、计算、洞察和展示五层，上一层的结果是下一层的输入：
- 采集层：从公开接口读取视频、分区、互动和发布时间等基础信息。
- 存储层：保存视频主表和时间序列快照。
- 指标层：计算热度分、增长率、互动密度和爆发指数。
- 洞察层：处理关键词、关联规则、曲线聚类和推荐评估。
- 展示层：把榜单、趋势图、视频详情和分析入口组织到前端。
采集任务失败时，前端仍可以读取已经入库的数据；调整热度分的计算方式时，只改指标层，不需要连页面一起重写。
数据模型的边界
videos 表保存视频标题、UP 主、分区、发布时间和最新指标，回答“视频现在是什么状态”。snapshots 表按采集时间保存同一视频的指标快照，回答“视频是怎样变化到现在的”。
只有主表时，系统只能按当前指标生成排行榜。快照表补上时间维度后，增长速度、生命周期阶段、曲线形状和爆发趋势才有依据。
服务层边界
路由层只处理请求参数和响应格式，分析逻辑放在独立服务中：
- ranking service：榜单和排序。
- scoring service：热度分和爆发指数。
- insight service：关键词、关联规则和内容组合。
- recommendation service：相似视频和选题参考。
接口字段因此保持稳定；榜单、评分、洞察和推荐模块也可以分别测试和替换。
接口和展示的边界
数据产品按查看路径组织，而不是一次展示所有指标：先给全局概览，再给趋势或异常入口，最后进入单个视频和解释面板。前端只消费整理好的接口数据，不重新计算热度或趋势。