企业官网建设流程全解析

最近被好几个毕设和课设的同学问到同一类项目：基于 Django + Hadoop 的招聘岗位信息推荐系统。说白了这个题目就是把爬虫、分布式存储、离线计算、推荐算法、Web展示串成一条完整链路。我前前后后帮人调过几套，踩过不少坑，也把代码、论文、答辩PPT整理成了完整的资料包。今天把这些经验一次性写清楚，从方案选型到推荐算法再到答辩准备，希望正在做这个题目的朋友能少走弯路。

这套系统到底解决什么问题，说白了就是：用户打开网站，填好自己的方向或者历史行为，系统把匹配的岗位推给用户，而不是让用户大海捞针。技术上核心是三块：Hadoop做离线数据存储与计算，Django做Web业务和推荐结果展示，推荐算法负责把“用户”和“岗位”之间最合适的关系算出来。下面我按照实际开发流程拆开讲。

1. 项目定位与整体方案选型——为什么是 Django + Hadoop + 推荐系统

1.1 招聘推荐系统到底在解决什么问题

先理解需求。传统招聘网站用户找岗位靠的是关键词搜索，搜索本质上是用户主动表达意图，但如果用户自己都不知道什么岗位适合自己，或者简历信息不完善，搜索效率就会很低。推荐系统解决的是“被动发现”的问题：根据用户基本信息、浏览记录、投递行为，猜测用户可能感兴趣的职位，并主动展示在首页或推荐栏。

做毕设的时候不能只说“我做了个推荐系统”，要把问题拆细。我一般建议分成四个子问题：

• 用户行为数据怎么采集，包括注册时填写的期望岗位、城市、技能，以及登录后的浏览、收藏、投递行为。
• 岗位数据怎么来，常见做法是爬取公开招聘网站的岗位信息，或者手动构造一批样例数据，考虑到答辩稳定性，我更推荐爬取部分真实数据加上人工构造的关键岗位数据混合使用。
• 推荐结果怎么算，这是核心，也就是用什么算法、如何训练、如何给每个用户生成 TopN 推荐列表。
• 推荐结果怎么展示，Django 中如何实现前端页面、如何分页、如何呈现推荐理由。

把这四个问题回答清楚，论文的绪论和系统分析部分就有东西写了。

1.2 技术选型背后的取舍：Django、Hadoop、MySQL 各司其职

我见过有人把 Hadoop 用得特别勉强，比如只在系统里用 HDFS 存了一个测试文件，然后借口说“分布式系统已经部署”。这样答辩老师一问就穿帮。正确的做法是让 Hadoop 在系统里扮演真正不可替代的角色。

我的方案是这样的：

• Python 3 + Django 作为 Web 框架，负责用户管理、岗位展示、行为采集、推荐结果接口。
• Hadoop HDFS 用于存储爬取到的原始日志和岗位快照数据，体现大数据存储能力。
• Hive 做离线 ETL，把散乱的数据清洗成结构化推荐表，这算 MapReduce 的一种简化使用方式。
• MySQL 存储最终的岗位数据、用户信息、行为记录和离线推荐结果。
• 推荐算法实现，我建议用 Spark 或者直接写 MapReduce。如果是课设，MapReduce 手写 TopN 推荐更直观，但代码量较大；如果是毕设且时间充足，可以用 Spark 的 MLlib 协同过滤，但是环境配置复杂。折中方案是：用 Python 离线脚本读取 MySQL 数据，用 pandas 和 scikit-learn 实现协同过滤，然后导回 MySQL。不过标题里写了 Hadoop，如果完全不用 Hadoop 会显得名不副实，所以至少要让 HDFS + Hive 参与 ETL 流程。

为什么选 Django 而不是 Flask？因为 Django 自带 Admin 后台、ORM、认证系统、模板引擎，这些在毕业设计中能省大量时间。尤其是 Django Admin，可以直接用来管理岗位数据和用户数据，答辩演示时非常出彩。

至于 MySQL 和 Hive 的双写，很多人不理解。HDFS 和 Hive 是给“大数据处理”看的，MySQL 是给 Web 实时访问用的。离线计算完的结果写到 MySQL 推荐表中，线上 Django 读 MySQL，这是最务实的设计。如果你非要说自己用 Django 直连 Hive 查询，那性能会让你怀疑人生，而且答辩现场很可能因为 Hive 的查询延迟而翻车。

1.3 整体架构与数据流向

整个系统架构可以用一条数据流来概括：

• 数据采集端定时爬取招聘网站的岗位描述、薪资、公司、城市、经验要求。
• 爬取结果先写到 HDFS 的 /recsys/raw/job_info 目录下，同时写到 MySQL 的 job 表，保证两个存储都有数据。
• 使用 Hive 对 HDFS 原始数据做清洗、去重、字段标准化，然后通过 sqoop 或者直接 insert 将清洗结果回写到 MySQL 的 job_clean 表。
• 用户浏览、收藏、投递等行为，Django 实时记录到 MySQL 的 user_behavior 表，同时异步写入 HDFS 日志目录，供离线阶段做全量分析。
• 推荐模块每天凌晨跑一次离线任务，读取 MySQL 中的行为数据和岗位数据，计算用户兴趣相似度或岗位相似度，生成每个用户的 TopN 推荐列表，写入 recommend_result 表。
• Django 前端首页读取 recommend_result 表，渲染出个性化推荐页面；如果用户是新用户没有行为数据，则用基于简历标签的内容推荐兜底。

这套数据闭环写进论文就是很好的“系统总体设计”章节，思路清晰，每一层都有明确职责。

2. 数据准备与离线处理：让 Hadoop 真正干活

2.1 岗位数据从哪来：爬虫与数据标注细节

数据是整个推荐系统的燃料。做这类毕设最常见的坑是数据量太小。有些同学只手工造几十条岗位数据，协同过滤根本算不出相似度。我的建议是：至少准备 2000 条以上岗位记录、500 个以上注册用户、10 万条以上的模拟行为日志。这样才能让推荐算法看起来在“工作”。

数据来源有两个层面。

第一层是真实爬虫。我用 Scrapy 写了一个爬虫，抓取常见招聘网站上公开的岗位列表页和详情页，解析内容包括岗位名称、公司名称、薪资下限、薪资上限、城市、经验要求、学历要求、技能标签、职位描述。这里要特别注意，只抓公开可见的网页数据，且需要控制抓取频率，毕竟课设项目不是商业爬虫，没必要搞高并发。

第二层是模拟数据。真实网站反爬比较严重，光靠爬虫可能凑不够量。我写了一个生成器，基于行业、职位、技能词库，随机组合出岗位，并且模拟生成用户行为序列，比如某个用户看了“Java开发工程师”后浏览了“Spring Boot开发”等职位。这种方式在毕设中非常常见，只要在论文里如实说明“部分数据来自系统模拟生成”，不算造假，反而展示了你对数据残缺的应对能力。

岗位字段设计对推荐效果影响很大。我设计的岗位表包含以下字段：

• job_id、job_name、company_name
• salary_min、salary_max、salary_avg
• city、education_requirement、experience_requirement
• skill_tags（逗号分隔）、job_description
• industry、release_date

skill_tags 是推荐系统最重要的字段，因为后续根据标签做内容匹配和相似度计算都靠它。爬虫阶段一定要把岗位描述里反复出现的高频词提取出来，作为技能标签。

2.2 数据清洗与 ETL：写 MapReduce 还是直接 Hive

把原始数据存到 HDFS 之后，不能直接拿来算推荐，因为原始数据很脏。常见问题有：

• 岗位名称不一致，比如“Java开发工程师”和“Java工程师”其实是一个岗位。
• 薪资表示混乱，有的按“15薪”写，有的按“3-5万/月”写，需要统一成月薪区间。
• 技能标签里包含停用词，比如“责任心强”“团队合作”也算技能，但这些对推荐没有区分度。
• 大量重复抓取导致同一岗位多条记录。

清洗策略上，我建议用 Hive 写 HQL 脚本处理，相比手写 MapReduce 要效率高很多，而且可以在论文里说“使用 Hive 完成大数据的离线 ETL”。Hive 的本质就是把 SQL 翻译成 MapReduce 作业，答辩时老师问你具体怎么跑分布式，你可以解释 Hive 底层的执行引擎是 MapReduce/Tez，学到的知识还是分布式计算那一套。

我举一个典型的脱敏清洗脚本片段：

CREATE TABLE dwd_job_clean AS SELECT job_id, regexp_replace(job_name, '[\\s\\u3000]+', '') AS job_name, company_name, CAST(split(salary, '-')[0] AS INT) AS salary_min, CAST(regexp_extract(split(salary, '-')[1], '\\d+', 0) AS INT) AS salary_max, city, CASE education WHEN '本科' THEN 1 WHEN '硕士' THEN 2 WHEN '大专' THEN 3 ELSE 0 END AS edu_level, experience_requirement, skill_tags, industry FROM ods_job_raw WHERE job_id IS NOT NULL AND job_name != '' DISTRIBUTE BY city;

这个脚本里 DISTRIBUTE BY city 是一个分布式语义点，可以根据城市分区，后续 Join 时降低数据倾斜。清洗后的 dwd 层数据存到 HDFS 的 Hive 仓库目录，同时也通过 Sqoop 导出到 MySQL 的 job_clean 表。

这里我要特别强调：不要试图在 Django 里直接调用 Hive。Hive 执行延迟太高，线上页面经不起你这么玩。正确姿势是 Hive 算完，结果落 MySQL，Django 只查 MySQL。这个思路体现在论文里就是“离线计算与在线查询分离”，算得上一个亮点。

2.3 伪分布式环境下的存储设计：HDFS + Hive 分层表

很多同学是在自己电脑上搭 Hadoop 伪分布式环境，内存可能只有 8G 或 16G。这个环境不用追求高可用，也不建议配 HA，伪分布式够用就好。

HDFS 目录设计要有层次，我建议这样：

• /recsys/ods/job_raw：原始爬虫数据
• /recsys/ods/behavior_log：用户行为日志
• /recsys/dwd/job_clean：清洗后的岗位数据
• /recsys/dws/user_profile：用户画像汇总
• /recsys/ads/recommend_result：推荐结果

在 Hive 中建立对应的外表和内表。ODS 层建外表，数据文件放到 HDFS 指定目录，DWD 层写 HQL 清洗后由 Hive 管理存储。这样做的好处是，论文中能画出清晰的分层架构图，而且每一层的数据血缘是清晰的。

配置文件方面，如果你手动配 Hadoop，需要注意这几个文件：

• core-site.xml：配置 fs.defaultFS 为 hdfs://localhost:9000
• hdfs-site.xml：设置 dfs.replication=1，伪分布式必须设为 1，否则会一直报副本数不足
• mapred-site.xml：配置 yarn 作为 MapReduce 框架
• yarn-site.xml：内存分配要调小，比如 mapreduce.map.memory.mb 和 yarn.nodemanager.resource.memory-mb 设置成 1024MB 左右，否则在低配电脑上容易异常退出

Hive 还需要提前初始化元数据库，默认 derby 即可，如果想体验真实项目感可以配 MySQL 作为 Hive 元数据库，但这部分环境复杂度较高，如果时间紧凑不太建议折腾。我在实际部署中遇到过 guava 依赖包冲突，用新版 Hadoop 配 Hive 时经常报版本不兼容，解决方式是删除 Hive 的 guava 旧版，拷贝 Hadoop 中的新版进去，这种细节非常影响心态，配环境前要做好心理准备。

3. 推荐算法实现：协同过滤只有三步

3.1 为什么选协同过滤而不是深度学习

面对推荐系统这个题目，很多小白张口就是“深度学习模型”“神经网络”之类的词汇。但你得想清楚，这是个毕业设计，不是打 Kaggle 竞赛，数据量很有限，而且没有充分的商品侧特征，深度学习很难有好的效果，反而给自己的实现和答辩制造困难。做传统推荐算法更稳妥、更容易讲清楚。

我最推荐的组合是：基于物品的协同过滤（ItemCF） + 基于内容的推荐（Content-Based） 双通道兜底。原因如下：

• ItemCF 只需要用户-岗位行为矩阵，不需要复杂特征，容易用 Python 实现，也容易画流程解释。
• ItemCF 的解释性好，推荐结果可以给用户看“相似岗位推荐”，答辩时说服力强。
• 内容推荐用于冷启动，在用户没有行为数据时，根据用户填写的技能标签和期望职位，用 Jaccard 相似度匹配岗位。

那基于用户的协同过滤（UserCF）要不要用？我建议把 UserCF 也实现出来，但作为辅助通道。因为 UserCF 在大规模用户下计算密集，且对新用户不友好。论文写作时可以把两种协同过滤对比，说明你如何权衡取舍，这是一个很加分的分析点。

3.2 相似度计算与 TopN 推荐逻辑

基于物品的协同过滤逻辑是这样的：

• 构建用户-岗位打分矩阵，打分手动定义：浏览记 1 分，收藏记 3 分，投递记 5 分。这个分值不是随便拍的，要控制收藏行为权重高于浏览，但不能高于投递，否则用户只看不投却影响推荐，不符合业务逻辑。
• 计算岗位之间的相似度。这里我用余弦相似度，因为岗位向量是稀疏的，余弦适合处理高维稀疏向量。

举个例子，岗位 A 的技能标签是 [Java, Spring, MySQL]，岗位 B 是 [Java, Spring, Redis]，岗位 C 是 [Python, Django, SQL]。把技能空间展开，每个岗位映射成一个向量，A 和 B 的余弦相似度远高于 A 和 C，所以推荐系统会认为 A 和 B 更接近。

实际操作中，我不建议直接对全量岗位做两两相似度计算，那样复杂度是 O(n^2)。先做倒排索引：从行为数据里找用户同时交互过的岗位对，只对“共现”的岗位对计算相似度，这也是 ItemCF 的标准优化方式。然后预计算每个岗位最相似的 K 个岗位，K 一般取 10 或 20。这一步可以每天晚上定时跑，也可以每次触发全量离线计算。

得到岗位相似度矩阵后，推荐逻辑就是：用户最近有行为记录的那些岗位，分别找出各自最相似的若干岗位，按相似度加权汇总，排除用户已经浏览过的岗位，排序生成最终 TopN 列表。公式不复杂，重点把权重和分母算对，避免重复推荐。

3.3 离线推荐结果如何写回 MySQL

离线计算跑完后，结果要落到 MySQL，Django 才能高效读取。我定义了一张推荐结果表：

CREATE TABLE recommend_result ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, job_id INT NOT NULL, score FLOAT NOT NULL, reason VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uq_user_job (user_id, job_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

reason 字段很关键，比如“因为您浏览了 Java开发工程师，所以推荐相似岗位”。这能让前端展示推荐理由，答辩评委看到这个细节会觉得你做得很用心。

写入策略是每天凌晨通过 crontab 或者 Django Command 执行离线推荐脚本，先清空昨天该用户的推荐结果，再写入今天的新结果。注意不要全表 DELETE，除非你想让线上用户瞬间没有推荐可看。正确做法是分类删除，只删除今天参与推荐的用户的历史结果。

4. Django 后端与前端展示：把推荐跑起来

4.1 Django 项目结构与核心模块拆分

Django 项目建议采用多 app 结构，而不是把所有逻辑堆在 models.py 里。我习惯这样分：

• users_app：用户注册、登录、个人信息管理、简历技能标签维护
• jobs_app：岗位分类、岗位搜索、岗位详情展示
• behaviors_app：浏览/收藏/投递行为采集接口
• recommend_app：推荐结果接口、离线指令脚本、算法工具函数
• dashboard_app：数据可视化大屏，用 ECharts 展示岗位数量、城市分布、薪资分布等统计信息

多 app 的好处是职责单一，论文中系统设计章节可以直接对应每个 app 写子模块，答辩老师问“功能如何划分”时你能清晰回答。

Django settings 里需要配置 MySQL 连接、缓存、日志。如果一个项目里既有 HDFS 又有 MySQL 又要跑推荐算法，我建议把算法相关代码和 Django 业务代码分离。用 Django manage.py command 方式封装离线任务，比如：

# recommend_app/management/commands/run_recommend.py from django.core.management.base import BaseCommand class Command(BaseCommand): help = 'Run offline recommendation task' def handle(self, *args, **options): # 读取行为数据、训练模型、生成推荐结果 pass

这样执行python manage.py run_recommend就能触发推荐任务，既能在服务器上手动执行，也能挂到 crontab 里做周期调度。

4.2 用户行为采集接口与岗位搜索模块

推荐系统的质量很大程度上取决于行为数据，所以行为采集接口要设计得规范。我用的接口格式是 REST 风格的 JSON：

POST /api/behavior/ { "user_id": 123, "job_id": 456, "type": "view" }

type 有 view、favorite、apply 三种，后端接收到请求后写入 MySQL 行为表，同时向本地日志文件追加一条记录，日志文件再同步到 HDFS。实现上我要提醒一个坑：不要在 Django 主线程里写 HDFS，因为网络 I/O 会拖慢接口响应。异步方案是把日志先写到本地文件，再用一个独立脚本定期用 Hadoop distcp 或 HDFS Shell 上传到 /recsys/ods/behavior_log 目录。这就是“异步解耦”的工程实践，写进论文很加分。

岗位搜索模块不是推荐系统的核心，但是前端体验的重要组成部分。Django ORM 做搜索查询时，要注意模糊查询的性能问题。例如：

jobs = JobClean.objects.filter( Q(job_name__icontains=keyword) | Q(skill_tags__icontains=keyword) | Q(company_name__icontains=keyword) ).order_by('-salary_avg')

数据量小的时候这么写没问题，但如果岗位数据超过几万条，需要进行全文索引。毕设场景下，几千条数据加索引就够用。我实际测试过，Django ORM 在数据量小于 5 万时性能并不差，重点要记得给 job_name、city、skill_tags 加 MySQL 索引，否则一个查询可能卡半天。

4.3 推荐结果接口：从 MySQL 读取还是实时计算

再次强调，线上推荐接口不要实时跑算法。正确做法是直接读取 recommend_result 表，然后分页返回。Django View 代码大致是：

def get_recommendations(request, user_id): page = int(request.GET.get('page', 1)) page_size = int(request.GET.get('page_size', 10)) offset = (page - 1) * page_size results = RecommendResult.objects.filter(user_id=user_id)\ .select_related('job')\ .order_by('-score')[offset:offset + page_size] data = [{ 'job_id': r.job_id, 'job_name': r.job.job_name, 'company': r.job.company_name, 'salary': f"{r.job.salary_min}k-{r.job.salary_max}k", 'city': r.job.city, 'reason': r.reason, 'score': round(r.score, 4) } for r in results] return JsonResponse({'code': 0, 'data': data})

前端页面推荐列表上可以展示“相似岗位”“推荐理由”等，后端的 reason 字段就是干这个的。新用户没有 recommend_result 记录时，走内容推荐接口，根据用户简历技能标签找匹配岗位，直接实时算也是可以的，因为只涉及一次标签匹配，毫秒级返回。

Django 模板部分可以使用 Bootstrap + 前端模板语言渲染，也可以做前后端分离。如果是为了答辩演示稳定，我更推荐模板渲染，减少接口联调风险。数据可视化大屏用 ECharts 放到 dashboard 页面，演示时展示像“岗位需求 Top10 技能词云”、“城市岗位薪资分布”这类统计图，视觉效果比纯列表好很多。

5. 系统测试、部署与性能优化

5.1 测试用例怎么设计才不被答辩老师挑刺

很多毕设项目没有测试章节，被论文评阅老师点名批评。作为一个完整的系统，至少要包含单元测试和功能测试。测试不一定写几百条，但要覆盖核心链路。

Django 的测试比较简单，在 app 下建 tests.py 就能跑。我设计了几类用例：

• 注册登录流程测试：用户能不能正常注册，密码是否加密存储。
• 行为采集接口测试：POST 行为后，数据库中是否新增记录，日志文件是否追加。
• 搜索功能测试：传入关键词能否返回正确岗位列表。
• 推荐接口测试：有推荐结果的用户返回 TopN 列表，无推荐结果时返回空列表或内容推荐结果。
• 爬虫解析测试：拿一条样例 HTML 解析出正确的岗位字段。

测试数据使用 Django 自带 test 数据库，不会污染真实数据。把测试结果截图放进论文，比空空泛泛写“系统稳定可靠”有说服力得多。

5.2 伪分布式部署踩坑实录

每套 Hadoop + Django 的项目，部署阶段总会遇到一些环境怪问题。我把自己踩过的几个高频坑放在这里，希望你别再走一遍。

首先是 Hadoop 启动后 DataNode 连不上。最常见原因是格式化前没删除 HDFS 的 tmp 目录，导致重新格式化后 NameNode 的 clusterID 和 DataNode 不一致。解决方法是彻底停止集群，删除 tmp 目录和 logs 里的缓存，然后重新格式化 NameNode。如果你不知道 tmp 目录在哪，一般是 /usr/local/hadoop/tmp 或 /opt/hadoop/tmp，看 core-site.xml 里配置的 hadoop.tmp.dir。

第二个坑是 Hive 运行 HQL 时内存不够，Java heap space 或者 Physical memory usage 超限。伪分布式环境下，每个 Map 任务默认内存较大，多个任务同时跑可能占满本机内存。解决方法是调整 YARN 的内存配置，建议在 yarn-site.xml 中设置：

<property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>512</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>1024</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>2048</value> </property> <property> <name>mapreduce.map.memory.mb</name> <value>512</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>512</value> </property>

这个配置只适合配置了 8G 内存的开发机，如果你的电脑配置更低，还要再往下调。虽然项目要求大数据，但伪分布式环境最关键的是“跑通”，而不是追求吞吐。

第三个坑是 Django 连接 MySQL 报错Can't connect to MySQL server (10061)。大部分原因是 MySQL 服务没启动，或者用户名密码没配对，但还有一个比较隐蔽的原因是 MySQL 8 默认 caching_sha2_password 认证插件与 Django 2.x 不兼容。建议用 Django 3.2 以上版本，或者安装 mysqlclient 库并确保版本匹配。

5.3 性能优化三板斧

毕设项目不用谈特别深度的性能优化，但你需要能回答“如果数据量增大，系统怎么扩展”这个问题，至少懂三招：

第一招，MySQL 加索引和分页优化。不要写复杂的 SQL 嵌套查询，尤其是推荐结果查询，务必使用索引字段过滤，避免全表扫描。分页超过 100 页后用游标分页代替 OFFSET，虽然毕设数据量不会触发，但写进论文能展现深度。

第二招，离线计算和在线查询分离。把推荐计算从用户访问链路中剥离，离线预计算，在线只做缓存读取。这是整个项目最核心的性能优化。我在论文中专门画了时间对比图，展示实时计算接口响应时间 800ms 以上，而离线预计算 + MySQL 查询只有 30ms 左右，一眼就能看出设计优势。

第三招，结果缓存与增量更新。离线任务不必每天把全量所有用户全部重新算，可以只更新有新增行为的用户和新增的岗位。具体实现是在行为表中记录 last_modified 时间，只拉取最近三天产生新行为的用户，批量计算后合并到推荐结果表。这个策略虽然实现起来略微复杂，但答辩时如果敢说“增量推荐”，层次明显比“全量刷表”高一个级别。

6. 论文与答辩资料准备经验

6.1 精品论文结构怎么安排，图表怎么画

标题里带了“精品论文”，这说明论文质量对整体分数影响很大。按照学校常见的模板，论文结构大概七章：

• 绪论：讲招聘行业背景、推荐系统研究意义、国内外现状、论文组织结构。
• 相关技术介绍：Django、Hadoop、Hive、推荐算法概述。
• 系统需求分析：功能性需求（注册、登录、浏览、搜索、推荐、管理）和非功能性需求（性能、安全、可用性）。
• 系统设计：总体架构图、功能模块图、数据库 ER 图、推荐算法流程设计。
• 系统实现：分模块贴关键代码和截图，注意代码不要整篇贴，只贴核心逻辑。
• 系统测试：测试环境、测试用例、测试结果、性能测试分析。
• 总结与展望：总结完成工作，分析不足和后续扩展方向。

图表是论文的门面。我最推荐的画图工具是 draw.io，免费且能导出高清图片。至少要画这些图：

• 系统总体架构图：展示浏览器、Django、MySQL、HDFS、Hive 之间的数据流向。
• 系统功能模块图：用树形结构画出用户、岗位、行为、推荐、管理五大模块。
• 推荐算法流程图：用户行为矩阵、相似度计算、TopN 生成、结果入库，按流程画。
• E-R 图：用户表、岗位表、行为表、推荐结果表之间的关系。
• 部署架构图：展示 Hadoop 伪分布式、MySQL、Django 在同一台机器上的部署结构，也可以画成虚拟机轮子图。

画图时注意线条干净、字体统一，不要用太花哨的颜色。论文评阅老师一眼扫过去，结构图越专业，印象分越好。

6.2 答辩 PPT 的重点与讲稿思路

答辩时间通常只有 5 到 10 分钟， PPT 页数控制在 12 到 15 页。不要每一页都是文字，以图为主、关键结论为辅。我建议按这个顺序做：

• 封面页：题目、姓名、学号、指导教师。
• 目录页。
• 项目背景与研究意义：一两句话带过，不用展开。
• 技术栈与开发环境：Django 3.x、Hadoop 3.x、Hive、MySQL、Python 3。
• 系统架构图：这是全场重点，停留 30 秒，解释数据流走向。
• 核心功能展示：注册登录、岗位搜索、岗位详情、推荐列表、后台管理，每个功能放一张截图。
• 推荐算法设计与效果展示：先展示用户行为矩阵，再展示相似度公式，最后展示推荐结果列表，需要把算法讲透。
• 数据库设计：展示几张核心表的 E-R 图即可。
• 测试结果截图：报出接口响应时间等关键数据。
• 创新点与难点：比如离线与在线分离、ItemCF 倒排索引优化、内容推荐冷启动。
• 总结与展望。

答辩讲稿要提前准备，核心逻辑是：我做了什么 -> 怎么做的 -> 遇到了什么问题 -> 怎么解决 -> 最终效果如何。讲的时候不要说套话，比如“通过本次设计提高了我的动手能力”这种话老师听烦了。不如具体一点：“我在配置 Hadoop 伪分布式环境时发现 YARN 内存默认参数过大，导致多次内存溢出，我通过调整内存配置成功解决”，这样有细节，有说服力。

6.3 源码、README、数据库脚本如何整理成完整资料包

资料包不只是代码，还包括能让人快速部署的说明文档。每次交上去，我都会检查这些文件是否齐全：

• 项目源码目录，排除虚拟环境、数据库文件、爬虫缓存。
• requirements.txt 或 pipenv 文件，写清楚依赖版本。
• README.md，包含环境准备、Hadoop/Hive 部署步骤、Django 启动步骤、离线推荐任务执行方法。
• SQL 脚本，包含建库建表语句、初始岗位数据和测试用户。
• 爬虫脚本源码和采集样例。
• 论文 Word 版和 PDF 版。
• 答辩 PPT 原文件。
• 系统演示录屏，防止现场设备出问题。

README 中要注意别漏了 Hadoop 的启动指令。我常用的启动顺序是：

start-dfs.sh start-yarn.sh hive --service metastore & python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000

同时还要写一行“准备 HDFS 目录”的命令：

hdfs dfs -mkdir -p /recsys/ods /recsys/dwd /recsys/dws /recsys/ads

这些操作对课程设计来讲已经是相当完整了。

另外，源码中建议把数据库连接密码等敏感信息放到.env或config.ini里，并在 README 说明如何替换。答辩老师需要复现项目的时候，按照 README 一步一步操作能跑通，好感度会大幅提升。很多同学资料里连个说明都没有，老师当然会认为项目是网上随便抄的。

最后再说一句关于推荐系统迭代方向。如果你后续想扩展，可以在内容推荐中加入中文分词和 TF-IDF，对岗位描述和用户简历做更细粒度的匹配；或者用 ECharts 加一个可视化管理大屏，动态展示实时行为流。这些都是随着项目深入可以自然扩展的方向，但核心思路不变：数据要闭环，离线与在线要分工清晰，推荐逻辑要能自圆其说。

这套项目我实际做过几个版本，最大的感受是：不要把精力全花在环境搭建和调参上，先把最简单的闭环跑通，再逐步优化。很多人卡在 Hadoop 环境上十天半个月，其实只要按上面说的内存配置调整好，很快就能启动，后面真正拉分的是推荐算法的清晰度和论文图表的美观度。希望这份经验能帮你少走弯路，顺利交出一套能说服评委的招聘岗位推荐系统。