大数据方向的毕业设计十个有九个卡在同一个地方选题虚空、数据不够、落不了地。代码跑通了导师问一句“这里面哪里用到大数据了”就哑火。今天分享的这个项目——“基于DjangoHadoop大数据的出行方式推荐系统”算是一个比较讨巧又扎实的解法。它不搞花哨的深度学习也不硬套大模型而是把Hadoop系的大数据离线处理能力和Django的Web服务能力做了完整串联最终交付的是一个能演示、能答辩、能跑出推荐结果的完整系统程序、文档、代码讲解、一条龙定制全都配齐。这篇文章我从技术选型到环境搭建再到推荐算法实现和答辩避坑一条线讲透准备照着做的朋友可以直接抄作业。1. 项目定位与系统架构设计思路栏目里经常有人说“大数据毕设找不到题”其实是把题想复杂了。大数据方向的毕设核心不是模型多高级而是正确处理“海量数据批处理结果展现”这条链。这个项目把场景落在“出行方式推荐”上既能用真实通勤场景解释清楚又能把天气、时间、道路拥堵、用户偏好等特征全部拉进来数据维度够丰富推荐结果也直观可见。这个选题的聪明之处在于它是一个“每个人都能看懂”的场景评委不用你解释业务背景答辩时省下一大堆力气去介绍模型指标之外的东西。系统架构上采用的是典型的“应用层数据层”分层设计这也是毕设最容易讲清楚的结构。前端展示用Django的模板引擎加BootstrapDjango负责路由、登录鉴权、推荐接口管理和后台管理MySQL用来存用户、出行记录、推荐结果这类结构化数据Hadoop这边负责重活HDFS存储历史行为日志MapReduce和Hive做离线统计和特征提取。当用户发起请求时Django先从Redis或MySQL取实时特征再从Hive预计算好的特征表里拉偏好数据最后把混合推荐结果返回给前端展示。选Django而不是Flask或SpringBoot原因很直接。Django自带Admin后台意味着天然有一个能演示的管理端界面毕设展示的时候你不用自己前端写一个后台直接就用自带的/admin就行Django的ORM和阿里云的pymysql兼容度高操作MySQL是顺滑的模板语法也简单原生支持异步视图配合Celery或websocket做数据推送也不费劲。选Hadoop做数据层的原因则在于这套系统永远只做离线批处理日志数据是攒出来的不需要秒级响应Hadoop的伪分布式部署在单机上运行完全够用MapReduce跑几百万条模拟日志也稳定。这里需要特别强调一下用Hadoop不是为了硬凑技术栈。出行行为日志是非常典型的“写多读少、后知分析”的数据HDFS的追加写模式和流式读取非常适合这类数据Hive做的是类SQL查询毕设中出现数据分析部分时SQL的方式是个人最好向导师解释的路径“我写了一个HiveQL统计用户的出行习惯”这句话对答辩组来说比“我用TensorFlow训练了一个模型”靠谱得多因为后者大概率会被追问细节。2. 核心功能拆解与推荐算法设计功能模块不需要多关键是要完整走通数据回路。这套系统的核心模块有三块用户登录和偏好设置模块、出行推荐模块、数据可视化看板模块。用户端完成最基本的注册、登录、个人偏好设置比如优先省钱还是优先省时推荐模块是核心用户输入起点、终点、出发时间系统比对交通方式库和实时特征库返回步行、骑行、公交、地铁、打车五种方式的排序结果可视化看板则是给导师展示大数据价值的点睛之笔展示历史出行趋势、分时段出行方式占比、热门区域热度图。2.1 推荐算法的分层设计推荐引擎这层我建议做成“规则评分协同过滤”的混合结构。规则评分是基础协同过滤是升级最后把两个分数加权融合。先说规则评分这个公式我在多种场景下试过最稳定的是多目标加权评分score w1 * 时间归一化得分 w2 * 费用归一化得分 w3 * 环保归一化得分 w4 * 舒适度得分时间得分怎么算每种出行方式都有预估时间T用T_max - T /T_max - T_min把时间映射到0到1区间耗时越短得分越高。费用得分同理金额取倒数再归一化。环保得分按碳排放量倒排步行骑行公交地铁打车。舒适度是用户偏好字段用户自己设定。权重w1到w4用经验值默认0.4、0.3、0.2、0.1这个是可调的答辩时可以重点讲“权重如何通过反馈数据迭代调整”。协同过滤部分用的是基于用户的最近邻方法。核心思路是一类出行场景比如经常在早高峰从A小区到B科技园的用户系统会把这类用户归为一个偏好群体群体里打车占比高那当前用户在这个时段也倾向于推荐打车。实现上用皮尔逊相关系数算用户相似度相似度大于0.6的用户当做邻居提取他们选择过但当前用户没选过的出行方式作为候选集再按出现频次加权。2.2 冷启动问题的处理毕设答辩必问的问题是“新用户没有历史数据怎么办”。规则评分模型正好能兜底因为它是特征驱动的不需要用户历史数据所以新用户也能得到推荐结果。等到用户产生足够行为记录后协同过滤的比重再逐渐增加。这里我建议在表设计里加一个user_status字段0代表新用户1代表正常用户推荐逻辑里根据状态切换两个模型的权重比例这样代码逻辑分叉点非常清晰也方便演示时解释。2.3 推荐质量怎么评价推荐系统不能光说推荐了得有评价指标。我在这套系统里实现了三个指标命中率、Top3准确率、用户满意率占比。命中率就是推荐结果里用户点选了哪个点选结果是不是在Top3里Top3准确率用“用户点击位置≤3”的次数除以总请求次数满意率可以做一个简单的隐形评分用户连续两次选择同一种出行方式记为正向反馈。这些指标最终展示在看板里用来证明推荐系统有效是加分项。3. 环境搭建与大数据组件部署实录这一步是大多数人栽跟头的地方。Hadoop伪分布式安装是全网教程最多、坑也最多的部分版本选不对后面的Hive配置会连环报错。我推荐的组合是JDK 1.8 Hadoop 3.3.x Hive 3.1.x MySQL 8.x Python 3.8 Django 4.2。这组版本搭配我跑过多次兼容性最省心。不建议盲目上Hadoop 3.4或JDK 17很多老教程不认报错信息会把你绕晕。3.1 Linux环境准备与免密登录建议直接用Ubuntu 20.04的虚拟机不要折腾Windows直接跑Hadoop。VMware网络选NAT模式给虚拟机固定内存建议4G起步不然Yarn起Container的时候会莫名其妙失败。先在/etc/hosts里把主机名配置好然后设置SSH免密登录这一步出问题后面所有操作都会拖慢节奏sudo apt update sudo apt install ssh pdsh -y ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost很多教程会跳过pdsh但实际上Hadoop 3.x在SSH远程执行脚本时依赖这个工具不装会在启动datanode时报“Could not locate executable null\bin\winutils.exe”或者连接超时。装完后Ssh到localhost能直接免密进去这个环节才算过。3.2 Hadoop核心配置文件与启动配置文件全部在$HADOOP_HOME/etc/hadoop目录下。核心的就三个core-site.xml、hdfs-site.xml、yarn-site.xml。配到最简即可别照搬网上复杂的多节点配置。我的模板是这样!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration !-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/usr/local/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/usr/local/hadoop/data/datanode/value /property /configuration伪分布式部署dfs.replication必须设为1设成3的话一个节点上会反复报块复制错误但实际上不影响运行只是日志会疯狂刷警告答辩演示时特别难看。配置完成后要先格式化NameNode再启动hdfs namenode -format start-dfs.sh start-yarn.sh jpsjps看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager五个进程都在集群就正常了。注意每次重启虚拟机后不用重新格式化NameNode很多人一看到进程宕了就去format结果是集群ID变了Datanode连不上Namenode反而制造出新问题。3.3 Hive安装与MySQL Metastore配置Hive装起来不复杂但默认Derby存元数据会让人崩溃特别是重启之后表结构全乱。一定要用MySQL做Metastore。在MySQL里建好hive库和hive用户然后改hive-site.xmlproperty namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://localhost:3306/hive?createDatabaseIfNotExisttrue/value /property property namejavax.jdo.option.ConnectionDriverName/name valuecom.mysql.cj.jdbc.Driver/value /property property namejavax.jdo.option.ConnectionUserName/name valuehive/value /property property namejavax.jdo.option.ConnectionPassword/name value123456/value /property记得把MySQL的JDBC驱动jar复制到hive的lib目录不然报ClassNotFound报到你怀疑人生。初始化Metastore用schematool -initSchema -dbType mysql之后启动hiveserver2就能用beeline连接了。3.4 Django项目初始化和数据库连接Django这边相对顺手Django 4.2配Python 3.8是安全组合。但要注意MySQL 8默认的caching_sha2_password认证插件和Django的MySQLdb旧版本不兼容解决办法是显式安装pymysql并在项目的__init__.py里做替换import pymysql pymysql.install_as_MySQLdb()同时注意settings.py里DATABASES的ENGINE用django.db.backends.mysqlHOST不要写localhost要写127.0.0.1否则有时候会绕道走socket连接报错。项目基础命令都熟django-admin startproject travel_recommend python manage.py startapp recommend python manage.py makemigrations python manage.py migrate python manage.py createsuperuser4. 数据管道与推荐服务编码路径环境拉通之后核心工作就剩两块怎么把数据喂进Hadoop怎么把推荐结果取出来显示。这两块一旦打通整个系统就能站起来。4.1 用模拟程序生成海量行为日志真实数据没有那就模拟但要模拟得像样。我写了一个Python脚本按真实通勤数据基础生成用户出行日志字段包括user_id、start_location、end_location、start_time、travel_type步行/骑行/公交/地铁/打车、duration、cost、weather、traffic_index。为了看起来真实工作时间段交通方式分布和休息日要不一样早晚高峰打车比例高晴天骑行比例高雨天几乎为0。脚本生成200万条左右的TSV日志文件写到本地再上传到HDFShdfs dfs -mkdir -p /data/travel hdfs dfs -put /home/ubuntu/logs/travel_log.tsv /data/travel/模拟数据这一步讲究的是“可解释”。导师喜欢问“数据量到底有多大”你可以直接出示日志生成脚本和HDFS的du命令结果证明数据不是造个10万条糊弄事而是已经对Hadoop产生真实压力了。建议生成至少100万条MapReduce跑起来才有盘算否则一个秒级任务讲故事没有说服力。4.2 Django端用户行为采集与实时落库用户端的行为采集不能指望Hadoop它只做离线的重活在线轻量记录得Django干。我在Django里写了一个middleware每次用户请求推荐接口时自动异步记录用户ID、路线、天气、时间戳插入MySQL的user_behavior表。这个表是实时的也是后续Hive离线分析的数据来源之一。用Redis做缓冲队列Django进程把行为数据写入Redis的list再由定时任务批量刷入MySQL能显著减轻数据库压力这个设计在答辩时常被追问实际上也很拿得出手。这种采集路径的好处是实时数据在MySQL里离线数据在HDFS里两条线互不干扰。月度合批时把MySQL全量导出成TSV替换HDFS上游数据完成一次日志归档这也是大数据流程中很经典的“离线数仓定期刷新”动作。4.3 Hive离线特征统计与结果回导Hive里建一张外部表指向HDFS日志路径然后跑分析SQL。我建议先做一张出行偏好宽表统计每个用户在“工作日早高峰/工作日非高峰/周末”三种场景下对每种出行方式的选择频次CREATE TABLE user_travel_pref AS SELECT user_id, time_slot, travel_type, count(*) AS cnt FROM travel_log GROUP BY user_id, time_slot, travel_type;跑完用sqoop或直接Hive导出到MySQL的user_pref表推荐服务就能用了。这里的核心点是要把结果导回MySQL而不是让Django去连Hive。让Web应用直连Hive是大忌响应慢、连接不稳定、对小白不友好。MySQL中间层隔离是成熟的工程套路也让推荐查询毫秒级响应。4.4 Django推荐接口的核心代码推荐接口是系统的门面代码逻辑务必清晰。整体流程取用户基本信息和最近行为记录组装特征规则模型算分协同过滤算分加权返回排序结果。核心示意def recommend(request): user request.user origin request.GET.get(origin) dest request.GET.get(dest) departure_time request.GET.get(time) # 1. 拉取实时特征 features get_features(origin, dest, departure_time) # 2. 规则模型打分 scores_rule rule_scoring(user, features) # 3. 协同过滤候选集 cf_candidates collaborative_filtering(user, time_slot) # 4. 加权融合 final_scores {} for mode, score in scores_rule.items(): cf_score cf_candidates.get(mode, 1) final_scores[mode] 0.7 * score 0.3 * cf_score # 5. 排序返回 sorted_modes sorted(final_scores.items(), keylambda x: x[1], reverseTrue) return JsonResponse({recommendations: [m for m, s in sorted_modes[:3]]})代码里的相似度函数、候选排序逻辑我都封装在单独模块里保持recommend视图的轻量也便于写单元测试。答辩演示时可以手动调权重可以看到推荐结果发生变化非常直观。5. 常见问题与答辩环节准备下面是几类最常见的问题也都是实际跑数据时才遇到的坑我按自己现场排障经验整理了速查表。现象原因解决方式NameNode启动后DataNode起不来重复format导致clusterID不一致在hdfs-site.xml指定新目录重格式化后删除data目录再启动Hive连不上MetastoreJDBC驱动缺失或MySQL账号权限不足检查lib下是否有mysql-connector-java.jarGRANT ALL给hive用户Yarn任务卡住不执行虚拟机内存不足容器无法分配给虚拟机4G以上内存yarn.nodemanager.resource.memory-mb调低到1GDjango连MySQL报authentication错误MySQL8认证插件和client不匹配用mysql_native_password重设密码或升级pymysqlMapReduce输出文件_part_0乱码没有设置UTF-8编码在XML配置里加mapreduce.output.fileoutputformat.compressfalse等配置推荐结果每次都一样没有读取用户行为特征检查协同过滤特征表是否已回导MySQL权重分配是否写死5.1 答辩追问准备为什么是Hadoop而不是Spark这个问题几乎必问回答的落脚点是“数据规模和处理模式”。Hadoop的MapReduce适合海量离线日志的批处理资源调度成熟稳定跑通整个生态的的过程本身就是学习价值所在而Spark虽然快但项目时间有限实时处理也不是本系统的核心需求。这样回答说实话且不露怯而且能反手把话题引到“离线数仓和实时数仓的区别”上导师会认为你有架构视野。5.2 答辩追问准备推荐效果如何验证直接说三件事日志回放离线测试、在线A/B小流量、用户满意度抽样。线下回放历史日志算命中率上线后对比“规则推荐”和“混合推荐”两个版本的点击率最后用调查问卷收集体验。不用讲得太大讲清楚三个机制即可。5.3 答辩追问准备数据量真的很大吗假装大数据和真的做了大数据是有区别的。在基于DjangoHadoop的出行推荐系统里通过生成200万条模拟日志配合HDFS多副本存储和Hive分区表查询展示真实的数据处理链路。同时还可以展示扩展思路多节点部署后HDFS容量可以线性扩展这是“大数据”与“大文件”的本质区别。我个人在实际项目中体会最深的一点是这个项目的成败不在于推荐模型是否聪明而在数据链路是否打通。很多同学的代码在单机上跑得通但是把数据流程改造成HDFSHiveMySQL三层以后就到处报错。只要把每一步的输入输出搞清楚难点也就迎刃而解了。另外给一个小建议看板页面上一定要加一个“数据流水线状态图”从日志上传、ETL任务、特征回导到推荐调用每一步点亮一个状态灯这个图在答辩时讲起来比任何架构图都有说服力实战下来效果极好。