企业官网建设流程全解析

从选型到答辩，聊聊“django+Hadoop出行方式推荐系统”这类大数据毕设到底怎么做

每年到了毕设季，总有一批同学被“大数据”这三个字搞得又爱又怕。爱的是方向听着体面，怕的是不知道从哪下手。最近很多同学来问同一个项目——基于django+Hadoop的出行方式推荐系统，我发现大家对这个题目的理解普遍停留在“用框架凑个demo”的层面，这其实有点浪费。

先说结论：这个题目真正值钱的地方，不是“会用django写几个页面”，也不是“能在Linux上把Hadoop跑起来”，而是你能不能在答辩现场把“数据怎么流动”这件事讲清楚。一个能自圆其说的数据流转链路，比花里胡哨的前端界面值钱得多。

这个项目适合三类人：第一类是Web基础一般、但想往大数据方向靠拢的同学；第二类是已经定了推荐系统方向、想找一个具体应用场景落地的人；第三类是时间紧、任务重，想用一套稳妥方案把毕设扛下来的同学。不管你属于哪一类，这个选题的核心逻辑都是一样的：用Hadoop处理日志数据，产出统计结果，再由django把结果变成用户能看到的推荐页面。

这篇文章我就把这个项目的里里外外拆开讲一遍，从技术选型、系统架构、算法落地，到实际调试和答辩准备，尽量把那些容易踩坑的地方提前指出来。

1. 项目到底在做什么：出行方式推荐的核心逻辑

很多人第一次看到“出行方式推荐系统”这个题目，第一反应是“这不就是高德地图的路线规划吗”。这是最大的误会。地图软件的路线规划是实时计算最短路径，本质上是图论问题；而推荐系统解决的是“在多个可行的交通方式里，根据用户偏好和历史行为，帮用户挑出最合适的那一个”。这完全是两回事。

1.1 核心功能边界：推什么、不推什么

推荐系统推的是一组“可选项”，而不是一条“唯一最优路径”。

具体到这个项目里，候选集一般就是四种或五种常见方式：公交、地铁、骑行、步行、打车（也可以加入网约车、共享单车等）。对于每一种方式，系统要给出三个层面的信息：

• 基础属性：预计时间、预估费用、换乘次数、步行距离
• 个性化属性：这个用户在历史上对不同方式的接受程度、偏好倾向
• 情境属性：当前天气、时段（早晚高峰、夜间）、出发地目的地的地理特征

把这些信息汇总后，系统计算出一个综合得分，按得分排序输出Top-N推荐结果，并给出推荐理由，比如“根据您的历史偏好，本次推荐地铁方案，预计节省12分钟”。

这里有个边界需要注意：不要试图覆盖真实的实时路况和实时公交车位置。这一类数据需要大量三方接口，而且实时数据接入会让系统复杂度成倍上升。毕设项目里用仿真数据或离线统计数据来代替实时数据，是完全合理的做法，关键是要在文档里明确交代数据的时效性假设。

1.2 推荐与搜索、路线规划的本质区别

推荐系统的本质是“猜你喜欢”，它依赖的是历史交互数据。同一个用户，早上赶时间的时候系统推荐打车，周末出游的时候推荐地铁加步行，这不是因为路线变了，而是因为模型“记住”了这个用户在不同情境下的选择倾向。

搜索和路线规划解决的是“怎么从A到B最省事”，是确定性问题；推荐系统解决的是“根据这个人过去怎么选，现在他最可能接受哪种方式”，是不确定性问题。这个区别必须在开题报告和论文绪论里讲清楚，否则评委很容易问你“为什么不用Dijkstra直接算最短路径”，而你会被问住。

1.3 哪些功能必须做、哪些是加分项

为了保证系统完整性和工作量合理，我建议把功能分为三个梯队：

• 必做项：用户行为日志采集与存储、基于历史数据的离线分析、推荐结果页面展示、基于规则的推荐兜底
• 推荐项：基于协同过滤的个性化推荐、天气与时段影响因子、简单的用户偏好设置页
• 加分项：基于用户画像的偏好标签体系、推荐结果的解释（为什么推荐这个）、统计图表看板（用ECharts展示乘车时段分布等）

如果你时间充足，把加分项做一两个就够了。我见过一些同学把精力全花在炫酷大屏上，反而把核心推荐逻辑做得稀烂，答辩时一问“你推荐结果怎么算出来的”就卡壳。本末倒置是毕设的大忌。

2. 选型背后的账：为什么这个组合最省力

很多同学一上来就问“django和Hadoop是不是不太搭”。说实话，从纯工程角度看，这个组合确实不是最优解——用Spark做分布式计算、用Spring Boot做后端、用Vue做前端，整体会更“先进”。但毕设不是工业项目，选型的逻辑不是“最好”，而是“最能讲出东西且不容易翻车”。

2.1 django的价值：快速出活、结构清晰、好写论文

django这个框架的好处是“一条龙服务”。它自带ORM、自带Admin后台、自带模板引擎，同时配好MySQL或SQLite就能开发。对于毕设来说，最大的好处有三个：

• MTV架构非常规整，论文里画系统结构图特别方便，评审看着熟悉，一眼能看懂
• Admin后台自动生成，你可以把数据管理页直接做成系统后台展示，省掉大量重复工作
• 表单、分页、登录注册这些功能有现成组件，能帮你在两周内把前台框架搭完

我之前帮一个同学调试过项目，他花了一整个月写页面和样式，最后留给推荐算法的时间只有三天，核心代码还是从开题时抄的一段协同过滤。这就是典型的时间分配失误。在毕设里，页面做到“能用、不丑、逻辑清楚”就够了，千万别跟前端较劲。

2.2 Hadoop的角色：存储和离线计算的“面子”与“里子”

在真实的大数据系统里，Hadoop是一个庞大的生态：HDFS负责分布式存储，YARN负责资源调度，MapReduce或Spark负责计算，Hive可以把SQL翻译成分布式任务。但在毕设项目里，你需要的核心能力只有两个：

• 用HDFS存储用户行为日志文件
• 用MapReduce（或Hive）对日志做离线统计，例如统计每个用户对每种交通方式的使用次数、平均评分、活跃时段等

这里有一个很现实的问题：如果模拟数据只有几千条，直接存MySQL就行，为什么非要用HDFS？这个问题答辩必问。回答逻辑有两层：第一层是“数据量级对系统架构的决策引导”，当数据量达到PB级别时，单机数据库无法承载，分布式存储和计算是必然选择；第二层是“本系统采用离线批处理架构，Hadoop负责周期性统计，django负责在线实时推荐，两者职责分离”。你只要把这两层说清楚，评委基本不会再为难你。

2.3 为什么不选Spark、为什么不用微服务

有同学问能不能把Hadoop换成Spark，当然可以，而且Spark在性能和易用性上确实更好。但这里有个现实考量：用Hadoop意味着你的技术栈是经典的“HDFS+MapReduce”，参考资料多，网上教程多，有问题好排查；而Spark如果配置不好，光环境折腾就能耗掉你半个月。

微服务架构在毕设里更不建议碰。把django拆成多个服务，再用Docker部署，表面看很唬人，但一旦环境出问题，你连“快速回滚到能跑通的状态”都做不到。毕设的目标是“稳妥地展示完整能力”，而不是“展示架构上的炫技”。

3. 系统架构与数据流转：把“大数据”落到地上

很多同学的文档里写“本项目采用大数据技术架构”，结果图一画完自己都心虚，因为根本不知道数据从哪里来、到哪里去。其实系统架构这件事，说得直白点就是一条数据流水线，你把流水线上的每一站讲清楚，架构图自然就活了。

3.1 分层架构设计：每一层干什么、为什么这么分

我用的是四层结构，这个分层在论文里很好解释：

• 数据采集层：通过django埋点，记录用户每一次行为（搜索出行方案、点击查看某种方式、最终选择某种方式），生成结构化日志
• 数据存储层：MySQL用于存储用户信息、POI（地点）信息、推荐结果快照；HDFS用于存储原始日志文件，按日期分目录，作为离线分析的输入
• 计算层：编写MapReduce任务（也可用Hive），定期对日志进行统计分析，产出用户行为统计表、时段特征表、天气影响系数表，结果写回MySQL
• 应用层：django读取MySQL中的统计数据，结合在线计算规则，完成推荐排序，渲染页面并把结果返回给用户

这个分层的好处是“角色清晰”。每个组件只干一件事，出问题好排查，写论文好描述，答辩时问“某个环节挂了怎么办”你也好回答——离线层挂了不影响在线推荐，只是推荐质量会下降，这是典型的Lambda架构思想，只要沾一点边就能讲出东西。

3.2 核心数据表设计：推荐系统的地基

数据表是整个项目里最早开工、后期最难改的部分。我把核心表梳理一下，你直接照着建就行：

• 用户表：用户ID、昵称、注册时间、常驻城市
• POI地点表：地点ID、名称、经度、纬度、区域类型（住宅区/商业区/学校/景区等）
• 出行日志表：日志ID、用户ID、起点ID、终点ID、选择的交通方式、耗时、费用、天气、时段、时间戳
• 交通方式属性表：方式ID、名称、平均速度、基准费用、舒适度评分、是否受天气影响
• 用户-方式统计表：用户ID、方式ID、使用次数、平均评分、最近一次使用时间
• 推荐结果表：请求ID、用户ID、起点、终点、推荐方式排序、生成时间

其中出行日志表是核心中的数据，协同过滤算法的输入全靠它。设计时要注意冗余字段，比如“天气”“时段”冗余在日志表里，这是故意的，因为后续计算不想再回表关联查询。

3.3 数据流转的完整时序：从一次点击说起

我习惯用一个具体场景来讲数据流，这样答辩时表述特别有画面感：

假设一个用户早上八点半打开系统，从“某小区”出发去“某科技园”，系统返回了打车、地铁两种推荐，用户选了地铁。这个过程产生一条日志，包含用户ID、起点、终点、最终选择方式、系统推荐顺序、天气、时段等信息。这条日志实时写入MySQL的出行日志表，同时在后台异步追加到当天日期的HDFS日志文件中。每天凌晨，一个定时任务触发MapReduce作业，扫描前一天的日志，更新用户行为统计表，计算各时段各方式的使用占比，并修正天气影响系数。次日用户再次打开系统时，django先从MySQL读取这些统计结果，再根据当前请求的起点和终点，在线计算每种方式的得分，返回Top-N推荐列表。

这个过程一讲清楚，你论文里的“系统时序图”和“模块交互图”都有素材了，而且每一层为什么存在、为什么这么放都合情合理。

4. 推荐算法落地：不能只写一个协同过滤

推荐算法是整个系统的灵魂，也是最容易被评委追问的地方。很多同学交上来的系统只写了一个协同过滤的轮子，然后吭哧吭哧调参，数据一换效果就翻车。这类项目到答辩时通常很尴尬，因为评委一句“你为什么不用Item-Based而用User-Based”就能问住你。

4.1 整体策略：离线统计与在线规则的组合拳

我在给你的方案里采用一个组合策略：离线协同过滤加在线规则加权。两者不是替代关系，而是兜底关系。

离线层基于Hadoop产出的统计数据，训练一个简单的协同过滤模型，得到“用户-交通方式”的偏好矩阵。对于历史行为丰富的用户，这个模型能给出个性化推荐。但是对于新用户或者行为稀疏的用户，协同过滤几乎失效，这时候在线规则就顶上来了。在线规则不需要模型，它根据当前情境计算得分：比如早上八点到九点，系统判断是早高峰，打车的时间优势明显下降，骑行方案可能被更多打分；如果是下雨天，骑行和步行的得分直接乘以一个低权重。

这样设计的好处是：任何情况下系统都有推荐结果，不会出现“该用户无历史数据，推荐失败”这种尴尬局面。对于毕设来说，系统的鲁棒性比算法的纯度更重要。

4.2 协同过滤的简化实现：矩阵、相似度、Top-N

具体到代码层面，我建议你用最经典的User-Based协同过滤，原因是数据结构好解释，工作量可控。

构建用户-方式评分矩阵，行是用户，列是交通方式，取值是“标准化后的使用频次”。计算用户之间的相似度，用余弦相似度公式：

假设用户A对四种方式的评分向量是[5, 3, 0, 2]，用户B是[4, 0, 0, 2]，那么余弦相似度就是两个向量的点积除以各自模长的乘积，这里计算结果约为0.85，说明A和B偏好比较接近。有了相似用户集合后，预测目标用户对某种方式S的评分，就是对相似用户关于S的评分做加权平均，权重就是相似度。最后把得分最高的几个方式作为推荐结果输出。

这里有个细节要提醒：如果直接使用原始评分矩阵，数据会非常稀疏。你在做数据模拟的时候，要让每个用户至少对两三种方式有过行为，否则矩阵里全是0，相似度算出来全是0，推荐就废了。模拟数据时把“每种方式至少被每个活跃用户用过一次”作为一个约束条件，这样跑出来的效果不至于太难看。

4.3 加权评分模型：把多维信息揉进一个分数里

用户最终看到的是排序，但排序的依据是一个综合加权得分。我项目里用的公式长这样：

最终得分 = w1×时间得分 + w2×费用得分 + w3×舒适度得分 + w4×历史偏好得分

其中时间得分由“起点到终点的预估时间”取倒数再归一化得到，费用得分同理，舒适度得分来源于交通方式属性表，历史偏好得分来自离线协同过滤的预测评分。权重w1到w4是经验值，初始可以分别取0.4、0.3、0.2、0.1，然后根据效果微调。这里的一个关键技巧是：把不同量纲的分数都归一化到0到1之间，否则费用分值域一大就会吞掉其他因子的影响。

天气和时段怎么融入？我采用“修正系数”的方式，不参与权重分配，而是直接作用到某些方式上：下雨天骑行得分乘以0.3，步行乘以0.6，打车乘以1.1；早高峰公交和地铁乘以0.95，打车乘以1.05。这样做的好处是逻辑透明，论文里可以直接画一张修正系数表，答辩时一目了然。

4.4 冷启动与新用户的兜底策略

冷启动是推荐系统里绕不开的问题，也是评委最爱问的。你的答案是：推荐系统分为冷启动和正常两个阶段。新用户没有任何历史行为，协同过滤无法工作，系统直接采用“情境规则推荐”——完全由当前天气、时段、距离区间决定推荐结果。

具体规则可以这样写：距离小于2公里，优先推荐步行，其次是骑行；距离在2到5公里，优先骑行或公交；距离大于5公里，优先地铁或打车。夜间时段（22点到第二天5点），骑行和步行的风险系数升高，直接降权。这些规则写死在django的服务层，用Python代码就能实现，不依赖模型文件。

这套策略不仅解决了冷启动问题，还能在协同过滤效果不佳的时候作为安全网存在。我在实际调试中，经常把规则推荐的权重调高到0.5以上跑出“可接受”的推荐结果，再用协同过滤小步迭代优化。顺序对了，效果自然就来了。

5. 实操全过程：从环境搭建到论文插图

前面讲的是“设计”，这一节讲“实现”。我尽量按真实操作的时间线来写，中间会穿插一些容易卡壳的细节，你可以直接照着做，省掉踩坑的时间。

5.1 环境准备：Hadoop伪分布式与django开发环境

如果你不是计算机专业出身，或者平时不碰Linux，Hadoop的安装是第一个门槛。我的建议是装Hadoop的伪分布式模式，不要一上来就搞集群。所谓伪分布式，就是一台机器上同时跑NameNode、DataNode、ResourceManager、NodeManager四个进程，分布式的能力没少，但配置和排障的复杂度低很多。

关键配置有三处：JAVA_HOME要配到hadoop-env.sh里，core-site.xml设置fs.defaultFS为hdfs://localhost:9000，hdfs-site.xml设置副本数为1。启动后用jps命令查看进程是不是都活着，然后跑一下自带的WordCount示例确认环境没问题，再开始写业务代码。

django部分就简单多了，建议Python 3.8或3.9配django 3.2 LTS版本，同时安装mysqlclient连接MySQL。这里有个坑：mysqlclient在Windows上编译容易报错，你可以用本机远程连Linux上的MySQL，或者直接用系统自带的SQLite把原型先跑通，后面再切MySQL。

5.2 模拟数据：让系统“像真的”

毕设项目最需要的模拟数据有两种：用户行为日志和交通方式属性数据。

用Python的Faker库生成用户和地点，再用一个随机决策模型生成出行日志。注意这个“随机决策模型”不是完全随机，而是加一点概率倾向：比如某用户有60%概率选地铁，那你生成的日志里地铁占比就会高，这样协同过滤才能学到偏好。每种方式的使用概率要让它在不同用户之间有差异化，否则所有用户的行为都一模一样，模型训练出来等于没训练。

一天的模拟数据建议生成五千到两万条，不需要太多。数据量过万后，HDFS上看起来就“有点意思”了，跑MapReduce统计任务时也有一点大数据的观感。运行结束后，用hdfs dfs -cat查看一下日志文件，截图存证，这个截图放到论文里比任何描述都有说服力。

5.3 MapReduce作业编写：统计用户的“方式偏好频次”

对于协同过滤的输入矩阵，核心统计指标是每个用户对每种交通方式的使用次数。这个用MapReduce写其实很简单：Map阶段读出行日志，输出以用户ID和方式ID拼接的字符串为key，以1为value；Reduce阶段对同key的值求和，输出用户ID、方式ID、次数。

MapReduce的好处是写起来死板，不太容易出错，而且能用“分布式计算”这个点在文档里大书特书。我见过一个更偷懒的方案是用Hive的SQL直接实现同样的统计，如果你对Hive更顺手，建议用Hive，因为后期你要按时段、按天气做各种维度统计时，SQL的效率远高于反复调MapReduce代码。

统计结果写回MySQL。为了减少复杂度，你可以让MapReduce输出到HDFS上，再用Python脚本把结果文件读到MySQL里。这个“数据从HDFS到MySQL”的ETL过程，在论文里也算一个完整环节，表述空间很大。

5.4 django集成与推荐页面实现

django这侧的核心工作有三个：读取统计数据、计算综合得分、渲染推荐页面。

首先建立recommend/views.py里的主逻辑函数，传入请求中的起点、终点、用户ID。函数内部先从MySQL的用户统计表读取该用户对每种方式的历史偏好分；再从交通方式属性表读取方式属性；最后根据天气、时段读取修正系数，统一算出最终得分，排序后返回页面。

前端页面我建议做一个简单的提交表单：选择起点、终点，系统跳转到结果页，展示三个推荐卡片，每个卡片上标明方式名称、预计时间、费用、推荐理由。推荐理由这种小细节很拉好感，比如“根据近期行为，您更倾向于公交出行”，这说明你的系统确实用了“历史数据”，而不是纯随机推荐。

代码结构上建议把推荐计算逻辑独立成一个服务层文件（比如recommend_service.py），views层只负责调度和渲染，这样论文里的模块化设计和代码分层更好画。我见过不少同学的视图函数里堆了两三百行业务逻辑，答辩时被问“这个函数在做什么”都得现场捋一遍，太被动。

5.5 联调与运行：看着丑没关系，关键是全流程通

把Hadoop的日志处理流程和django的推荐流程连起来之后，第一次跑通会很有成就感，但联调阶段也是问题高发期。核心的联调路径是：先手动跑一遍数据生成脚本，再执行MapReduce（或Hive任务），把结果写入MySQL，然后访问django页面，看推荐结果是否符合预期。

一个容易踩的坑是，MySQL表里的字符集如果不是utf8mb4，中文地点名称写入时会变成乱码，排查起来很费劲。建表时就统一加上DEFAULT CHARSET=utf8mb4，能省半天时间。

联调通过后，记得把每一步的截图整理好：HDFS文件列表截图、YARN上任务运行历史截图、MapReduce输出结果截图、django页面截图、MySQL数据表截图。这些图拼在一起，就是论文“系统实现与测试”那一章的全部内容，而且是真实运行截图，比什么“系统界面演示”都硬核。

6. 调试、排障与答辩：细节决定你最后是“优”还是“良”

别小看这个部分，我见过太多代码写好了、但最后输在细节上的同学。有些问题看起来不起眼，实际上特别影响观感和答辩体验。

6.1 高频问题与排查速查表

我把实操里容易遇到的几类问题整理成了一张速查表，你碰到了可以对着查：

这里要特别提醒一个点：不要试图在答辩前临时换大版本。比如你django已经用3.2写好了，就不要为了“显得新”去升到4.x；Hadoop环境调通了也不要手欠格式化和重装。毕设的项目交付讲究“稳定跑通”，而不是“版本最新”。

6.2 答辩前必须想明白的五个问题

下面的问题我基本没见评委跳过，而且很多人都答不好。提前把答案想好，比背稿子管用：

问题一：你的数据量多大？为什么需要Hadoop？答案参考：上线初期模拟数据为万级，但系统针对的是PB级日志场景，HDFS的横向扩展能力是单机数据库不具备的；同时离线批处理架构保证了在线查询性能不受数据规模增长影响。

问题二：协同过滤和规则推荐哪个效果更好？答案是“在不同场景下各有优势”。规则推荐稳定可解释，冷启动友好；协同过滤个性化强，但依赖历史数据密度。本系统采用两者融合策略，以规则兜底、以协同过滤提升精度。

问题三：如果未来要支持实时推荐，架构怎么改？标准答法：引入消息队列和流式计算引擎，比如用Kafka接日志、用Flink或Spark Streaming算出实时偏好，再把结果放到Redis缓存中供在线服务读取。这一句就能体现你系统设计的可扩展性。

问题四：推荐结果如何评价好坏？这个要准备一个小实验：把历史日志按时间切分为训练集和测试集，用训练集模拟推荐，对比测试集中的真实选择，计算Top-1或Top-3的准确率与覆盖率。数字不重要，但你做了离线评测这件事本身就加分。

问题五：你在这个项目里贡献最多、自己最满意的模块是哪个？这种看似送分的问题，很多人答成了流水账。你要挑一个具体点，比如“用户行为日志的设计”，讲清楚为什么要把天气和时段冗余到日志表里，让评委感受到你真正理解数据设计。

6.3 时间管理与论文节奏：别把最硬的骨头留到最后

最后说一下时间安排。我帮同学规划过很多次节点，发现最合理的节奏是：前两周做需求分析和原型设计，第二到第三周把模拟数据和Hadoop环境跑通，第四到第五周做推荐算法的离线计算和django集成，第六周做页面优化、联调和测试，最后十天的窗口完全留给论文排版和答辩PPT。如果前期在环境上卡住了，宁可降低数据模拟的复杂度，也要保住联调时间。

论文写作也有技巧。开题背景里别写大段“随着大数据技术的发展”这种空话，直接写清楚“本项目要解决的是多交通方式选择场景下的人性化推荐问题”，评委一看就知道你有干活。测试章节不要只贴代码，把“模拟数据规模、训练测试集划分、准确率机器学习初值对比、推荐响应时间”列成表格，比写多少页文字都有说服力。

我自己的体会是，这类毕设项目它难不在技术深度，而在于“把每块技术怎么衔接”讲明白。Hadoop、MapReduce、协同过滤、django，每一个单独拿出来都是成熟知识，但你能不能把它们串成一个闭环系统，才是评委真正关心的。你只要顺着数据流转这条线把每一步做实，答辩时底气就足。

最后分享一个实用小技巧：在本地开发时把django的日志级别调成DEBUG，然后在“处理日志→执行推荐→渲染页面”三个位置各打印一条日志。联调的时候看日志就能确认数据到底走到了哪一步，这个习惯能帮你解决90%的“数据没过来”问题。调试通过后再把日志级别调回INFO，干净清爽地交付系统。