想用Django做一个能落地的推荐系统又想把大数据生态里的Hadoop融入进去让项目既有Web展示又有离线计算支撑“Django基于大数据Hadoop的职业方向推荐系统”是个很典型的毕业设计方向。这个题目好处在于技术栈宽、贴近就业场景、可展示的内容多。缺点也很明显网上资料要么只讲Hadoop要么只讲Django很少能帮你把整条链路串起来。我做完这个项目之后复盘了一下发现真正卡壳的地方不是算法而是环境、数据流和前后端连调。这篇文章我就按自己的实际搭建过程把从Hadoop环境准备、数据处理、算法实现到Django模块开发的完整思路写出来顺便把踩过的坑一起列上。1. 项目整体构思与技术选型1.1 这个系统到底在解决什么问题毕设做推荐系统第一步不是写代码而是把问题定义清楚。职业方向推荐系统本质上是一个信息过滤问题学生或求职者进入系统后系统根据他的专业背景、技能标签、行为偏好结合外部招聘数据岗位数量、薪资、技能要求、行业趋势给出个性化职位或职业方向推荐。为什么强调“职业方向”而不是单纯“职位推荐”因为真实场景里用户往往不知道自己该投什么岗位。比如一个学信息管理的学生他可能既适合数据分析岗也适合产品运营岗。这就需要系统不仅要匹配用户填写的求职意向还要通过大数据分析岗位间的技能相似度挖掘出用户没意识到但适合他的方向。我在设计时把推荐目标拆成两个层次第一层是基于用户简历和基础信息的“硬匹配”比如专业、学历、期望城市第二层是基于用户行为数据的“软匹配”包括浏览过的职位、收藏过的岗位、投递过的公司以及搜索关键词。前者保证推荐结果不跑偏后者用来做个性化排序。论文里我会把这两个层次写成“约束过滤协同过滤”的两阶段算法答辩时也能讲得清楚。1.2 为什么是Django加Hadoop这套组合这套组合看起来奇怪实际上各司其职。Hadoop负责离线数据层Django负责在线业务层。招聘数据往往是半结构化的文本量级可以做到几万条甚至几十万条用HDFS存储能模拟真实的大数据存储方式用MapReduce做离线清洗和统计也合适。Django则负责把统计结果和推荐结果变成可视化的Web应用提供用户登录、行为记录、推荐列表、后台管理等完整功能。选Django而不是Flask核心原因是开发效率。Django自带Admin后台、ORM、用户认证和CSRF防护这些在毕设里能省大量时间。尤其是Admin后台我只需要注册模型就能直接进入数据管理界面非常适合答辩前临时调整数据。Flask虽然灵活但用户系统、表单、分页都要自己搭反而拖慢进度。Hadoop这块有些同学会担心本地电脑跑不动。其实毕设完全不需要搭多节点集群伪分布式模式已经够用。伪分布式的意思是每个Hadoop进程都以独立Java进程运行在同一台机器上HDFS、MapReduce、YARN都完整保留只是DataNode、NodeManager都只有一份。我的8G内存笔记本跑起来没压力只要把堆内存调低一点就行。如果后续想提升技术层次可以把Spark引进来做替代后面第5章我会专门聊扩展方案。1.3 系统架构与数据流转我习惯用一张层次图来梳理整个系统的数据流写论文和画架构图都方便。第一层是数据采集层。我当时用的是爬虫爬某招聘网站的公开岗位信息也准备了一份手工整理的Excel数据。数据字段包括职位名称、公司、城市、薪资区间、学历要求、经验要求、技能标签、行业分类。考虑到爬虫不稳定我建议你在毕设里写明“数据来源为公开招聘网站结构化数据”不要依赖线上爬虫实时抓取。第二层是数据存储层。原始CSV文件上传到HDFS清洗后的结构化数据落回MySQL。这里有个关键点MySQL里建了三张核心表分别是岗位表、技能表、用户行为表。岗位表存职位基本信息技能表做岗位和技能的关联用户行为表记录浏览、收藏和投递动作。第三层是计算层。MapReduce做三件事过滤脏数据、统计各行业的岗位需求数量、提取高频技能词。统计结果输出成CSV文件再用Python脚本导入MySQL。推荐算法也开始在这里跑离线部分把计算结果和用户向量关联起来。第四层是应用层。Django读取MySQL数据通过视图函数渲染到前端页面使用ECharts展示技能需求排行、薪资分布统计、行业趋势图推荐结果列表通过协同过滤接口获取。整个过程就是“HDFS存原始数据、MapReduce洗数据、MySQL存业务数据、Django做展示推荐”。1.4 推荐算法选型单靠协同过滤不够推荐系统里面最常用的算法是协同过滤但放在职业推荐场景里纯协同过滤会遇到严重的数据稀疏问题。新用户刚注册时没有行为记录系统完全不知道该推什么这就是冷启动问题。我在项目里用的是混合策略用户行为数据大于阈值时走协同过滤小于阈值时走基于内容的推荐。基于内容推荐的核心是计算用户简历技能向量和岗位技能向量的余弦相似度。比如用户简历里写了Python、Hadoop、SQL岗位A要求Hadoop、Spark、Scala岗位B要求Java、Spring、MySQL那么用户和岗位A的相似度显然更高。具体实现时我会把技能标签做成one-hot编码向量然后在Django后端用Python写一个相似度计算函数。数据量不大时直接用pandas读全表循环算就行没必要上专门的推荐框架。如果希望答辩时更有亮点可以提一句“在线计算进入瓶颈后可引入预先计算矩阵”但毕设演示阶段实时计算完全够用。2. Hadoop环境搭建与数据处理2.1 毕设选伪分布式还是完全分布式很多同学纠结要不要买三台云服务器搭完全分布式。我的建议是别在这上面浪费预算伪分布式足够毕业设计。完全分布式的意义在于体现多节点并行计算和容错但论文里写出设计方案就行实际运行用伪分布式完全没问题。Hadoop本身是Java写的伪分布式模式下进程包括NameNode元数据管理、DataNode数据块存储、ResourceManager资源管理、NodeManager节点计算一套流程跑下来和集群模式没有区别。操作系统建议用Ubuntu 20.04或者CentOS 7安装JDK和Hadoop时统一使用稳定版本。我当时Hadoop用的3.3.4JDK用的1.8。注意Hadoop 3.x要求JDK 8及以上但下载时别贪新版本3.3.4这个系列比较稳定。2.2 安装步骤与核心配置安装过程本身不复杂核心在配置文件上。先把Hadoop解压到/opt/hadoop然后修改环境变量export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin接着改五个配置文件。第一个是core-site.xml设置HDFS的访问地址和临时目录configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configuration第二个是hdfs-site.xml伪分布式只有一个DataNode副本数必须设成1否则会一直报副本不足的警告configuration property namedfs.replication/name value1/value /property /configuration第三个是mapred-site.xml指定使用YARN框架configuration property namemapreduce.framework.name/name valueyarn/value /property /configuration第四个是yarn-site.xml配置ResourceManager地址configuration property nameyarn.resourcemanager.hostname/name valuelocalhost/value /property /configuration配置完以后先格式化NameNode再启动进程hadoop namenode -format start-dfs.sh start-yarn.sh格式化这一步特别强调只在第一次启动前执行。如果中途出了问题执行了第二次很容易出现NameNode和DataNode的clusterID不一致导致DataNode起不来。解决办法是删除tmp目录和data目录里的内容重新格式化再启动。每次改配置文件前我都会备份一份免得改乱了回不去。2.3 用MapReduce做数据清洗与统计数据清洗是推荐系统里最能体现“大数据”味道的环节。原始招聘数据里会有很多重复项、空字段、薪资格式混乱等问题。比如“10k-15k”“10K-15K”“8千-1万”这种写法不统一。我的MapReduce程序主要做三件事去掉缺失核心字段的记录把薪资统一成最低薪资和最高薪资两个整数提取岗位对应的城市和技能标签。写MapReduce最直观的方式是用Java但Django项目里Python使用更顺。这里可以提一个细节Hadoop Streaming支持用Python编写Mapper和Reducer不需要编译成Jar包。我建议你在毕设里先用Java写一个标准MapReduce因为论文里比较好描述实际运行的时候用Streaming也行。一个统计不同城市岗位数量的Mapper大致长这样#!/usr/bin/env python3 import sys for line in sys.stdin: line line.strip() fields line.split(\t) if len(fields) 5 and fields[3] ! 城市: # 输出城市名和次数1 print(fields[3] \t1)Reducer汇总#!/usr/bin/env python3 import sys current_city None current_count 0 for line in sys.stdin: city, count line.strip().split(\t) if current_city city: current_count int(count) else: if current_city: print(current_city \t str(current_count)) current_city city current_count int(count) if current_city: print(current_city \t str(current_count))跑完之后把结果从HDFS导出到本地hadoop fs -cat /output/city_count/part-00000 city_count.csv最好是输出为CSV或者直接输出到MySQL里方便Django后续读取。这里还有一个很好的加分做法把所有清洗后的岗位数据转存成一份clean_jobs.csv再通过Python脚本导入MySQL这样HDFS的原始数据和MySQL的业务数据之间就形成了清晰的层次关系。2.4 数据导入MySQLHDFS并不能替代MySQL作为业务数据库。HDFS擅长存储大规模文件但Django的ORM直接查HDFS几乎不可能。所以我的做法是HDFS只负责存储原始数据和MapReduce的中间结果MySQL存最终的清洗数据和推荐结果。导入脚本用Python的pymysql就可以重点是把CSV里的字段映射到Django模型上。这里有一个坑Django模型字段名和CSV表头名不一致导入时容易张冠李戴。我的做法是先读CSV文件头打印出来确认列顺序再写导入语句。批量导入时可以用bulk_create速度能快不少。3. Django后端与推荐算法实现3.1 Django项目初始化与数据模型Django项目结构我建议这样创建django-admin startproject career_project cd career_project python manage.py startapp recommend在settings.py里配置MySQL连接然后重点设计模型。职业推荐系统核心模型有四张表UserProfile用户的基本信息包括学历、专业、期望城市、技能列表技能列表可以用逗号分隔字符串保存。JobPosition岗位信息字段包括职位名称、公司、城市、薪资下限、薪资上限、学历要求、技能标签。UserBehavior用户行为字段包括用户ID、岗位ID、行为类型浏览、收藏、投递、时间戳。RecommendationResult离线推荐结果表每天定时刷新这样在线查询时性能好也方便展示。写模型时要注意一个细节技能标签字段用TextField保存JSON数组查询时虽然不太好直接做关系型过滤但推荐算法跑混淆矩阵时很方便。如果想兼顾查询效率再单独建一张JobSkill关联表一个Skill对应多个JobPosition。我一开始直接用CharField存逗号分隔后来做推荐列表时发现要反复切割字符串果断改成了JSON字段加关联表代码干净很多。3.2 用户行为采集与埋点推荐系统最怕没有数据。职业推荐系统的用户行为分为三类浏览职位详情、收藏职位、投递简历。我通过前端Ajax请求在Django视图里记录行为。比如用户进入职位详情页时前端会发送一个POST请求到/record_behavior/视图函数读取用户ID和职位ID插入一条浏览记录。这里有个容易忽略的问题同一个用户反复浏览同一个职位会导致行为矩阵冗余且权重不均衡。我的处理策略是如果用户对同一职位的行为已经存在就更新时间戳并增加权重如果不存在才新增记录。收藏和投递行为的权重比浏览高数值上我给的参考值是浏览1分、收藏3分、投递5分。这样在用户-职位评分矩阵里同一个用户对同一个岗位只有一个综合评分避免算法被重复浏览记录干扰。3.3 协同过滤算法的Python实现推荐算法的核心是构建用户-职位评分矩阵。我用pandas读用户行为表然后做pivot_table转成行是用户、列是职位的矩阵空值填0。基于用户的协同过滤需要计算用户间相似度常用的是余弦相似度。实现代码很简单import math import pandas as pd def cosine_similarity(vec1, vec2): if len(vec1) ! len(vec2): return 0 dot sum(a * b for a, b in zip(vec1, vec2)) norm1 math.sqrt(sum(a * a for a in vec1)) norm2 math.sqrt(sum(b * b for b in vec2)) if norm1 0 or norm2 0: return 0 return dot / (norm1 * norm2) behavior pd.read_sql_query(SELECT user_id, job_id, score FROM user_behavior, conn) matrix behavior.pivot_table(indexuser_id, columnsjob_id, valuesscore).fillna(0)算出相似用户之后找到目标用户最相似的K个用户再把这K个用户喜欢过但目标用户没看过的职位按相似度加权排序取前N个作为推荐结果def recommend(target_user, matrix, K10, N20): target_vector matrix.loc[target_user].values scores [] for user, row in matrix.iterrows(): if user target_user: continue sim cosine_similarity(target_vector, row.values) if sim 0: scores.append((user, sim)) scores.sort(keylambda x: x[1], reverseTrue) top_k scores[:K] job_scores {} for user, sim in top_k: user_rated matrix.loc[user] for job_id, rating in user_rated.items(): if rating 0 and matrix.loc[target_user, job_id] 0: job_scores[job_id] job_scores.get(job_id, 0) sim * rating ranked sorted(job_scores.items(), keylambda x: x[1], reverseTrue)[:N] return ranked这套代码跑下来性能不差几千个用户、几千个岗位完全没问题。冷启动用户在行为矩阵里没有记录matrix.loc[target_user]会直接报错所以要加一个判断。如果用户没有行为数据就调用内容推荐函数根据简历技能向量去匹配岗位技能向量。内容推荐部分用同样思路不过对象从用户换成岗位。把岗位技能标签拆出来和用户技能做集合交集交集越多相似度越高。这种基于内容的方法实现最稳定也是我压箱底的兜底方案。3.4 Django查询执行与删除对象Django的ORM平时用起来顺手但很多同学容易踩到懒加载和N1查询的坑。删除对象也常见但要分清楚delete()和filter().delete()的区别。删除单条记录job JobPosition.objects.get(idjob_id) job.delete()批量删除多条记录UserBehavior.objects.filter(user_idtarget_user).delete()查询推荐结果时注意性能尽量用select_related和annotatefrom django.db.models import Count from recommend.models import JobPosition hot_jobs JobPosition.objects.annotate( behavior_countCount(behavior) ).filter(behavior_count__gte10).order_by(-behavior_count)[:20]这里我吃过亏一开始直接用外键关联去循环取数结果页面渲染要半天。后来改成values()和annotate聚合速度提升明显。如果你在答辩演示时发现页面卡顿第一反应就该是ORM查询出了问题而不是去优化模板。3.5 WebSocket推送实时推荐结果Django原生的请求响应模型是“前端发请求、后端返回结果”但推荐结果如果依赖后台离线计算用户在页面上等着会很尴尬。我引入Django Channels做了WebSocket推送后台MapReduce或算法模块跑完后通过WebSocket主动推送“推荐结果已更新”的消息前端收到消息后自动刷新推荐列表。Channels的核心是把ASGI替代WSGI然后配置路由# asgi.py from channels.routing import ProtocolTypeRouter, URLRouter from django.urls import path from recommend.consumers import RecommendConsumer application ProtocolTypeRouter({ http: django_asgi_app, websocket: URLRouter([ path(ws/recommend/, RecommendConsumer.as_asgi()), ]), })Consumer里的websocket_receive处理逻辑不复杂关键是在recommend()函数里同步更新数据库。WebSocket的主要价值是提升演示效果展示“系统后端会自动更新推荐”而不是让用户一直点刷新。4. 常见问题排查与避坑记录4.1 Hadoop配置与运行问题我遇到最多的一个坑是DataNode启动失败。发生原因要么是NameNode多次格式化导致clusterID不一致要么是端口冲突。排查方法先执行jps看进程列表如果DataNode不在列表里去Hadoop日志目录找datanode.log。如果是clusterID问题最简单的操作是删除tmp目录下所有数据重新格式化再启动。另一个经典坑是“HDFS访问时提示Connection refused”。很多人会先怀疑防火墙实际大概率是NameNode进程没起来。检查顺序应该是先jps再hdfs dfsadmin -report看文件系统状态最后才去查防火墙。内存不足也常见。Hadoop默认堆内存有时候会占掉系统大部分内存我建议修改hadoop-env.sh里的HADOOP_HEAPSIZE设置为1G左右。这样笔记本上还能同时跑Django和MySQL。4.2 数据清洗与编码问题MapReduce跑出来的结果要么中文乱码要么字段错位。中文乱码绝大多数是编码问题。Linux环境下默认UTF-8Windows导出CSV经常是GBK上传到HDFS后处理时会乱。解决办法是统一在数据导入阶段用Python转成UTF-8编码再上传不要直接把Excel另存的CSV丢上去。字段错位的问题是CSV中有字段本身包含逗号比如职位名称“大数据开发工程师离线方向”如果里面没有逗号倒没事但技能标签是列表时字段里会出现逗号。最简单的处理方式是用制表符\t作为分隔符或者用Python的csv.reader做好解析再生成清洗后的文件。4.3 推荐效果差和冷启动怎么救协同过滤推荐效果差很大程度是行为数据太少。我的经验是不要等到系统做完了再去造数据应该在开发阶段就用脚本模拟一批用户行为。比如生成50个测试用户每个用户对10-20个职位产生行为这样算法才有展示空间。模拟数据要尽量符合真实场景比如一个学Python的同学浏览的岗位也应该是数据开发、后端开发而不是机械设计。冷启动解决方案前面已经说过就是用内容推荐兜底。这个方案论文里必须写答辩时老师非常喜欢问“如果用户刚注册没有任何行为系统怎么推荐”。每次被问到这个问题我都会把内容推荐代码拿出来讲一遍效果很好。外键查询慢的坑前面也提了主要是select_related和prefetch_related。另外MySQL服务器的max_connections有时候默认太小Django并发查询高了会报错“Too many connections”这时候改一下MySQL配置就行。5. 项目扩展方向参考5.1 从Hadoop到Spark升级路线如果论文答辩想再提一个层次可以考虑用Spark做替代或者补充。Hadoop的MapReduce适合离线批处理但需要迭代计算的推荐算法在MapReduce上效率不高。Spark RDD和DataFrame支持内存计算跑协同过滤的ALS算法非常合适。如果你有时间在Hadoop之外再装一个Spark用pyspark读取HDFS数据跑一遍ALS推荐把结果存回MySQL整条链路就会很完整。Spark安装不复杂解压后配置spark-env.sh指向Hadoop路径就行。最后写论文的时候把这部分写成“系统基于Hadoop实现数据清洗、基于Spark实现推荐算法形成混合计算架构”这个技术点是加分的。5.2 大数据架构的四层模型写论文时评委很看重对大数据体系的理解。我参考了网约车大数据项目里常见的分层思路把职业推荐系统也抽象成四层数据采集层、数据存储层、数据计算层、数据应用层。数据采集层对应爬虫和用户行为日志存储层对应HDFS加MySQL计算层对应MapReduce和推荐算法应用层对应Django页面和可视化。每层之间的接口我都定义得很清楚。HDFS和MySQL之间的数据传递用Python脚本完成Django从MySQL读数据前端ECharts从Django API拿JSON数据。这样每个组件职责单一论文里画层次图也非常清晰。这套四层结构基本是所有大数据项目通用的搞懂一次其他类似项目都能套用。5.3 把系统扩展成多源数据接入平台做完职业推荐系统之后我意识到这套架构可以很容易迁移到其他方向。比如网约车大数据分析项目把职业岗位数据源换成网约车订单数据用MapReduce清洗订单、统计热区再用Django展示订单趋势图完全是一个套路。所以如果你以后要做类似的毕设比如交通信息分析、电商用户行为分析直接在这一套框架上换数据源和算法逻辑就行。多源接入的思路也可以体现在职业推荐系统本身。我的系统除了招聘网站数据还接入了学校就业办提供的Excel数据。Excel里是往届毕业生的就业去向这份数据能提供“专业-职业”的映射关系。我在系统里加了一个管理功能允许管理员上传这种Excel文件自动解析后导入数据库再在推荐算法里增加一个专业匹配的权重项。5.4 答辩演示的细节准备每次答辩前建议把系统从零到一完整跑一遍。重点是Hadoop集群启动后用hdfs dfs -ls展示文件列表然后用Django页面演示搜索职位和推荐功能。演示时最好提前准备好固定账号导入一批模拟行为数据保证首次访问就能看到推荐结果。另外准备好一张大图把整个数据流转流程画出来从原始CSV、HDFS、MapReduce、MySQL、Django到前端图表。老师顺着这张图问你顺着图答基本不会跑偏。如果老师问推荐系统为什么推荐这个职位你就拿出技能相似度的计算逻辑讲一遍这个实操细节比背概念好用得多。我个人做下来最大的感受是推荐系统的技术难点不是算法模型多深而是数据链路长、环节多任何一个环节断掉整条系统就趴窝。所以做的时候要时刻把握“先跑通、再调优”的节奏先把Hadoop到Django的最小闭环跑通回头再细化算法和页面效果。希望这篇整理能帮正在做同类项目的同学少走几次弯路。