枚蓝最近把一个体育赛事直播推荐系统从零到一完整跑通了。技术选型用了Hadoop+Spark+Hive这套经典的大数据组合，最终交付的是包含离线数仓、协同过滤推荐和Web展示的完整项目。很多人一听到“推荐系统”就觉得算法很复杂，但在这类大数据毕业设计或入门级项目里，真正决定成败的反而不是算法，而是你对数据的处理链路是否清晰：日志从哪来、存在哪、怎么算、结果怎么被读取。
这篇文章适合两类人：一类是正在做大数据方向毕业设计，打算把Hadoop、Spark、Hive串成一套真实系统的人；另一类是刚入行数据平台，想了解离线数仓与推荐系统怎么配合工作的新人。我会以这套体育赛事直播推荐系统为例，把项目从业务拆解、数仓建设、Spark计算到踩坑调优的完整过程写出来，全部是可复现的方案。
1. 体育直播推荐到底在推荐什么？先拆业务再谈技术
1.1 体育直播推荐和普通视频推荐的本质差异
我在做这个项目之前，对“推荐系统”的认知主要停留在电商场景：用户看了A商品，系统推B商品，核心逻辑是“你可能喜欢什么”。但体育直播和电商、短视频的推荐逻辑差异很大，这些差异直接决定了技术方案怎么做。
体育直播最大的特点是强时效性。一场英超比赛一旦结束，这场直播的回放价值会断崖式下降。用户打开App时，最需要的是“现在正在直播的、我可能感兴趣的热门场次”，而不是一堆历史比赛。所以推荐系统不能只按历史行为匹配偏好，还必须把“赛事状态”和“当前热度”作为重要特征。
其次是粉丝凝聚性。体育用户通常有明确的球队主队：喜欢湖人的人大概率会看湖人比赛，支持曼联的人不会错过曼联焦点战。这种“内容标签”比电商场景更清晰，适合做基于内容的召回。但另一方面，体育赛事数量有限，尤其是冷门联赛，数据稀疏问题非常严重，很多用户可能只看过一两次比赛，纯协同过滤会拿不到足够样本。
第三点，也是我在项目答辩时反复提到的：体育直播的转化目标不是“购买”，而是“观看时长”和“回访率”。这意味着推荐效果不能只看点击率，还要关注用户是否真的点进直播间并停留。但为了降低项目复杂度，我没有一开始就引入实时观看时长统计，而是先按“点击、收藏、分享”这类行为做了加权评分。
如果把业务需求翻译成技术问题，可以概括成三件事：
- 知道用户关注什么球队、喜欢什么赛事类型。
- 知道哪些比赛正在直播、哪些比赛热度最高。
- 把“用户偏好”和“赛事内容”匹配起来，产出TopN推荐列表。
这三件事分别对应了用户画像建模、赛事热度统计和推荐结果生成，也是后面Hive数仓和Spark计算的主线。
1.2 从原始日志到“可计算特征”的转化链路
业务需求拆清楚之后，我会习惯性画一条数据流转链：日志采集 -> 数据落地 -> 数据清洗 -> 特征加工 -> 推荐计算 -> 结果存储 -> Web展示。这条链路看起来简单，但每一步都有取舍。
在这个项目里，原始日志来自前端埋点。用户进入直播间、离开直播间、点击关注球队、点赞、分享、评论，都会生成一条JSON格式的行为日志。这些日志不能直接用于推荐，原因有两个：一是字段杂乱且有脏数据；二是日志是“事件流”，不是“用户画像”，必须经过聚合计算才能变成可用的特征。
举个例子，用户A在一天内看了3场NBA比赛，其中看了湖人45分钟、快船20分钟、勇士5分钟。原始日志记录的是6条“进入直播间”和“离开直播间”事件。我关心的特征是“用户A对湖人、快船、勇士的兴趣权重”，这需要把多天多条日志按球队维度做聚合。
聚合之后，一张用户兴趣表就出来了。再关联赛事表，拿到球队名称、联赛类型、比赛时间，推荐候选集就有了雏形。整个转化链路可以概括为：
行为日志 -> 数仓分层存储 -> 用户画像宽表 / 赛事标签表 -> 召回候选集 -> 排序 -> 推荐结果表。
骨架搭完之后，剩下的就是填肉：具体用什么框架处理每一段，为什么这样选。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Hadoop、Spark、Hive三件套的分工边界与选型依据
2.1 为什么不是直接用MySQL，而是HDFS+Hive？
做毕设或者入门项目，最容易犯的错误是“为了用大数据而用大数据”。体育直播推荐系统的数据量真的有到必须上Hadoop的程度吗？说实话，如果只是几千个用户的数据，单机MySQL完全够用。但这类项目的意义在于让你完整走一遍大数据处理流程，而且如果数据源模拟到每天千万级日志，MySQL就会开始吃紧。
我在项目里模拟了两个月的数据：每天产生约2000万条用户行为日志，按JSON原样落盘后单日约15GB，压缩成Snappy之后大约8GB。这个量级对单机MySQL来说，写入和查询都会非常吃力。更关键的是，推荐计算需要用户维度、赛事维度、时间维度做大量聚合，SQL联表查询在千万级表上效率很低。
HDFS+Hive在这个场景下的优势并不是“快”，而是“稳”和“省”。HDFS把数据分散存储在多节点上，Hive则在文件系统上建立一张张逻辑表。你不必一开始就追求毫秒级响应，先把几十亿行历史数据稳妥地存下来、可离线分析，这才是数仓的定位。
我的选型依据很简单：
| 需求 | 选型 | 理由 |
|---|---|---|
| 海量日志存储 | HDFS | 分布式存储，扩容方便，不支持随机读写但适合顺序读 |
| 离线数据分析 | Hive | SQL化开发，适合复杂聚合和分层建模 |
| 复杂特征计算 | Spark | 内存计算，写复杂逻辑比Hive SQL更灵活 |
| 在线推荐结果 | MySQL/Redis | 只需要存最终TopN列表，单机足够 |
| 搜索 | Elasticsearch | 本项目暂时不需要，后续扩展可考虑 |
所以这套系统的数据流是：日志先落到HDFS，Hive负责数仓建模和分析，Spark负责推荐算法，最终结果回写到MySQL，Web端直接读MySQL展示。
2.2 Spark在数据链路里到底负责哪一段？
有人问：Hive本身也能写SQL做统计和召回，为什么还要用Spark？这确实是我在项目里反复权衡的问题。答案是：Hive适合处理“结构化明确”的聚合分析，但推荐算法里有几个环节用Hive SQL写会非常别扭。
比如协同过滤里的物