简介：基于Python爬虫与MapReduce分析的招聘信息大数据可视化系统，是一份高分毕业设计整套资料，面向软件工程、计算机科学、人工智能等专业的学生，解决招聘信息采集、分布式分析及可视化展示的综合问题。资源内含完整系统源码、部署文档和全部数据资料，代码已通过mac、Windows10/11、Linux环境运行验证，可直接用于毕设、课设或项目二次开发。压缩包共207个文件，包含Python脚本、HTML/CSS/JS前端页面、JSON与SQLite数据文件，以及图表展示所用的图片、字体和样式资源，包体仅17.13MB，结构清晰便于定位。同时提供演示动画和音频，可辅助理解系统交互流程。已有334人学习下载，适合需要快速上手招聘大数据项目、学习爬虫与MapReduce结合思路的开发者。
1. 招聘信息大数据可视化，为什么是爬虫加 MapReduce 的组合
一个需要交源码和部署文档的招聘信息可视化系统，表面上只是把岗位数据抓下来画几张图，但真正卡住人的地方从来不是画图，而是数据量上来之后的清洗和聚合。我在本地用 requests 爬一个招聘站，大概两个小时能拿到三四万条岗位记录，每条记录里混着城市、学历、经验、薪资字符串、技能标签这些字段，拿 Excel 打开是能看的，但要按城市和岗位维度统计平均薪资、统计技能共现次数，单机 Python 直接把内存吃掉大半。
这时候 MapReduce 的价值就出来了：它不要求你把全量数据一次性装进内存，而是把「映射——分组——归约」拆成分布式任务，跑在 HDFS 上的数据按 key 分发给多个节点处理。你写的分析代码是同一份，但可以从小数据量的单机 debug 平滑切到集群跑全量数据。这篇文章就围绕这套方案的完整落地来讲：爬虫怎么写不容易被封、数据如何切分成适合 MR 的格式、Mapper 和 Reducer 里做哪些聚合、最后怎样把 MR 输出接到 ECharts。适合正在做毕业设计或者想搭建一个完整数据链路的开发者，不管你是不是把 Hadoop 装在 Windows 上，这套流程都能跟着走通。
2. 招聘数据采集层：用 Python 把半结构化岗位数据落成可分析的格式
2.1 数据源选型与爬虫策略：先定字段再定站点
招聘信息的理想数据源不是那种需要复杂登录认证的大型招聘平台，反而是一些垂直招聘站或者公司官网的招聘接口更好处理。选择标准有三个：列表页有清晰的分页参数、详情页字段稳定、不强制 JS 渲染。很多站点实际提供的是 JSON 接口，直接返回岗位名称、薪资范围、城市、经验要求、学历要求、技能标签这些结构化字段，这比从 HTML 里抠数据省太多功夫。
确定站点后，第一步是列字段清单。我做这套系统时定义了九个核心字段：job_title、city、salary_min、salary_max、experience、education、company_name、industry、skills。其中 salary 在原始数据里经常是「15-25K·14薪」这种写法，必须拆成数字才能做统计。这个字段清单同时决定了后面建 Hive 表或 HDFS 目录的结构，所以最开始就要想清楚，不然后面改字段要重跑整个链路。
2.2 requests 加 BeautifulSoup 的最小可用爬虫
先给一个不依赖 Scrapy、纯 requests 就能跑通的采集代码，抓完直接落成 JSON Lines 格式，每行一条记录，方便后面上传到 HDFS。
import requests import json import time from bs4 import BeautifulSoup HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36", "Referer": "https://www.example.com/jobs", } def fetch_list(page): """拉取第 page 页的职位列表，返回原始 JSON""" url = f"https://www.example.com/api/jobs?page={page}&size=50" try: r = requests.get(url, headers=HEADERS, timeout=10) r.raise_for_status() return r.json() except requests.HTTPError as e: print(f"page {page} failed: {e}") return None def parse_and_save(items, out_fp): """把单页 items 做字段清洗，写为 JSON Lines""" for item in items: salary_text = item.get("salary", "0-0") parts = salary_text.replace("K", "").replace("k", "").split("-") salary_min = int(parts[0]) if len(parts) == 2 else 0 salary_max = int(parts[1]) if len(parts) == 2 else 0 record = { "job_title": item.get("name", "").strip(), "city": item.get("city", "").strip(), "salary_min": salary_min, "salary_max": salary_max, "experience": item.get("experience", "").strip(), "education": item.get("education", "").strip(), "company_name": item.get("company", "").strip(), "industry": item.get("industry", "").strip(), "skills": [s.strip() for s in item.get("skills", "").split(",") if s.strip()], } out_fp.write(json.dumps(record, ensure_ascii=False) + "\n") def main(max_pages=120): with open("jobs.jsonl", "w", encoding="utf-8") as out_fp: for page in range(1, max_pages + 1): data = fetch_list(page) if data is None or not data.get("list"): break parse_and_save(data["list"], out_fp) print(f"page {page} done, total fields: {len(data['list'])}") time.sleep(1) # 基础限速 if __name__ == "__main__": main()这段代码做了三件关键事情：一是把 salary_text 拆成 salary_min 和 salary_max 两个整数，这在后面 MR 统计平均薪资时可以直接做算术；二是用 JSON Lines 而不是 JSON 数组输出，好处是即使采集中断，已经写入的文件行还能用，不需要解析整个数组；三是每次请求间隔 1 秒，这种基础限速加上随机 User-Agent 已经能绕过大部分简单反爬。
2.3 增量采集与去重：不重不漏的关键在指纹
全量抓一遍之后，招聘数据是会每天新增的，重新抓全站代价太大。我一般在采集逻辑里加一个「增量去重」层：对每条记录的 job_title 加 company_name 加 city 拼成一个字符串，做 MD5 得到指纹，写入一个 dedup.txt 文件。每轮采集开始前把指纹集合加载进内存，新抓到的记录如果指纹已存在就跳过。
import hashlib def make_fingerprint(record): raw = f"{record['job_title']}|{record['company_name']}|{record['city']}" return hashlib.md5(raw.encode("utf-8")).hexdigest() def update_dedup(dedup_path="dedup.txt"): seen = set() try: with open(dedup_path, "r", encoding="utf-8") as f: for line in f: seen.add(line.strip()) except FileNotFoundError: pass return seen要注意的是，指纹字段选得越少误删率越高，选得越多去重效果越差。job_title 加 company_name 加 city 这套组合对招聘数据来说基本够用，同一家公司同一个岗位在同一个城市短时间内不会重复发布。如果遇到岗位真的重复但薪资不同，可以把 salary_min 也并进指纹里。
提示：不要用 requests 直接抓需要复杂验证码的站点，验证码破解属于高风险且极易失效的方向。选择数据源时优先找公开 JSON 接口，其次再考虑 HTML 解析。
2.4 数据落地检查表：进 HDFS 前的最后一道关
爬虫跑完，在把 jobs.jsonl 上传到 HDFS 之前，建议做三个检查。第一个是行数统计，wc -l jobs.jsonl确认拿到了预期量级的数据；第二个是字段完整性抽查，用 jq 或者 Python 随机读几百行，确认 city 和 salary 字段没有大面积缺失；第三个是编码检查，招聘数据里中文居多，确保文件是 UTF-8 无 BOM，否则后面 Hive 建表查出来全是乱码。
我习惯同时把 MySQL 备一份原始数据，因为 HDFS 上的数据删了不好追，MySQL 里留一份方便随时查明细。所谓「全部数据资料」在交付时，数据文件、去重文件和建表语句最好按 date 分区存好，评审老师大概率会问「数据哪来的」「更新机制是什么」，这两问能答清楚项目就成功了一半。
3. MapReduce 分析链路：从原始记录到统计指标
3.1 从爬虫到 HDFS：为什么不能直接把 JSON 扔进 Hive
爬虫产出的每个字段数量不一致，一条记录的 skills 可能是 3 个，另一条可能是 8 个，这种嵌套 JSON 结构直接放进 Hive 二位数表会很难查。正规做法是做一层清洗转换，把嵌套结构拍平。比如 skills 字段展开成一行一个技能，job_title 转成岗位大类（Java、Python、前端、算法），最后写成一个只有五到六个字段的宽表，每行一条记录，字段用制表符分隔。
hdfs dfs -mkdir -p /user/hadoop/jobs/raw hdfs dfs -put jobs.jsonl /user/hadoop/jobs/raw/jobs.jsonl hdfs dfs -ls /user/hadoop/jobs/raw这一步的本质是把「采集格式」转成「分析格式」。在真实集群环境里转换用 Spark 的 DataFrame 更省事，但如果毕业设计指定了用 MapReduce，那就写一个 MR 做 ETL：Mapper 读 JSON Lines 并解析成 JavaBean，Reducer 做去重，输出 TSV。我实际更推荐把清洗逻辑放在 Mapper 里，因为这样整个链路就统一在 Hadoop 体系里，演示的时候不需要额外开解释器进程。
3.2 理解 Mapper 和 Reducer 的边界：哪些事在 Map 做，哪些在 Reduce 做
写 MR 之前先搞清楚分组逻辑：Map 阶段处理每一行输入，产出 key-value 对；Reduce 阶段接收同一个 key 的所有 value 列表，做聚合。招聘分析里最典型的任务是「统计各城市 Java 岗位的平局薪资」，此时 key 是 city，value 是薪资数值，Reducer 计算 sum 和 count。
值得注意的事情是，凡是能提前过滤的数据尽量在 Mapper 里过滤掉，比如只保留职位名称包含 Java 的岗位，这能大幅减少 shuffle 的数据量。Reducer 里只做聚合，不要再做复杂的字符串处理，因为同一 key 的 value 可能分布在很长的一段数据里，处理逻辑越简洁，整个 job 跑得越快。
3.3 Hadoop Streaming 跑 Python MapReduce：代码结构与参数说明
用 Java 写 MR 还要编译打包，开发效率低。Hadoop 提供了 Streaming 机制，允许用任意可执行程序充当 Mapper 和 Reducer，Python 脚本配合 stdin/stdout 就能跑 MR。这也是这套系统里最省事的一环。
#!/usr/bin/env python3 import sys def parse_line(line): fields = line.strip().split("\t") if len(fields) < 6: return None job_title, city, salary_min, salary_max, experience, education = fields[:6] return job_title, city, salary_min, salary_max for line in sys.stdin: parsed = parse_line(line) if not parsed: continue job_title, city, salary_min, salary_max = parsed if "Java" not in job_title: continue avg = (int(salary_min) + int(salary_max)) / 2.0 print(f"{city}\t{avg}")上面的 Mapper 脚本按制表符切分字段，过滤出职位名包含 Java 的记录，输出「城市 / 平均薪资」键值对。注意这里的 avg 是用 min 和 max 的平均近似实际薪资，招聘网站普遍不给精确到个位的数字，这个近似在全量统计层面是够用的。
对应 Reducer 脚本：
#!/usr/bin/env python3 import sys current_city = None current_sum = 0.0 current_count = 0 for line in sys.stdin: line = line.strip() if not line: continue city, salary = line.split("\t") salary = float(salary) if current_city != city: if current_city is not None: print(f"{current_city}\t{current_sum / current_count:.2f}\t{current_count}") current_city = city current_sum = 0.0 current_count = 0 current_sum += salary current_count += 1 if current_city is not None: print(f"{current_city}\t{current_sum / current_count:.2f}\t{current_count}")Reducer 按城市累积薪资总和与岗位数，最后输出城市、平均薪资、岗位数三个字段。运行该 MR 需要有可执行权限，提交命令如下：
hadoop jar $HADOOP_HOME/contrib/streaming/hadoop-streaming-*.jar \ -files mapper.py,reducer.py \ -input /user/hadoop/jobs/raw/jobs.jsonl \ -output /user/hadoop/jobs/avg_salary \ -mapper "python3 mapper.py" \ -reducer "python3 reducer.py" \ -numReduceTasks 3-files会把本地脚本分发到各个节点，-numReduceTasks 3的意思是用 3 个 reducer 并行汇总，这样可以生成 3 个分片结果文件。第一次调试建议保持 1 个 reducer，输出在单个文件中更容易排查问题。
3.4 多个指标一口气算完：多输出与组合键的使用
招聘系统的可视化页面通常不止一张图。城市薪资分布、学历要求占比、技能词频、经验年限区间这四张图就对应四类统计任务。每张图跑一次 MR 浪费资源，更常见的做法是「一次 MR 出多组统计」，方法是 Mapper 输出组合键，同一个任务标记不同的键前缀。
例如 Mapper 里输出三组：city_salary前缀、education前缀、skill前缀，Reducer 根据前缀进入不同的统计分支。但需要注意 Hadoop 默认的 shuffle 是按完整 key 分组的，组合键会造成不同前缀的数据被分到不同 reducer，这是期望行为。如果希望同一城市的数据分配到同一个 reducer，key 就要用city本身，value 里带上前缀标记，Reducer 内部再按标记分桶。下面是一个输出技能词频的 Reducer 扩展思路：技能字段在清洗时已经被逗号分隔，Mapper 里按逗号拆开后逐个输出，Reducer 里做标准 wordcount。
3.5 MR 结果落地：从 HDFS 输出目录导出到 MySQL
MR 跑完的结果在 HDFS 的 /user/hadoop/jobs/avg_salary 目录下，以 part-00000 这类分片文件形式存在。可视化后端不能直接读 HDFS，一般会把结果导出到 MySQL 的表里。导出方式不用写额外的 Java 程序，用 sqoop 或者直接hdfs dfs -cat重定向成 CSV 再导入。
hdfs dfs -cat /user/hadoop/jobs/avg_salary/part-* > avg_salary.tsv mysql -uroot -p --local-infile=1 jobs_analysis -e \ "LOAD DATA LOCAL INFILE 'avg_salary.tsv' INTO TABLE stats_city_salary FIELDS TERMINATED BY '\t' (city, avg_salary, job_count)"导完之后在 MySQL 里建几个宽表：stats_city_salary、stats_education、stats_skill_freq、stats_experience，每张表都带 update_time 字段，方便可视化端知道自己展示的数据是什么时候跑的。这里要特别注意表的字符集设置成 utf8mb4，不然后端查询中文城市名会乱码。
| 指标 | 原始字段 | Mapper key | Reducer 计算 |
|---|---|---|---|
| 城市平均薪资 | salary_min/max | city | 薪资 sum / count |
| 学历占比 | education | education | count |
| 技能频次 | skills | skill | count |
| 经验区间分布 | experience | experience | count |
4. 可视化层：从统计表到可交互的面试官友好界面
4.1 数据接口设计：Flask 后端把 MySQL 结果转成 JSON
可视化端的技术选型不需要很重。常见的搭法是用 Flask 提供 REST 接口，后端读 MySQL 里的 stats 表，转成 JSON 返回给前端，前端用 ECharts 渲染。如果不想写后端，也可以让 MR 结果直接生成静态 JSON 文件，HTML 页面用 fetch 读取本地 JSON。毕业设计答辩时后一种方式更省事，但不太像工程化项目。
我这里给出一个 Flask 接口的核心代码，同时兼顾「城市薪资地图」和「技能词云」两个接口。
from flask import Flask, jsonify import pymysql app = Flask(__name__) DB_CONFIG = { "host": "localhost", "user": "root", "password": "123456", "database": "jobs_analysis", "charset": "utf8mb4", "cursorclass": pymysql.cursors.DictCursor, } def query(sql): conn = pymysql.connect(**DB_CONFIG) try: with conn.cursor() as cur: cur.execute(sql) return cur.fetchall() finally: conn.close() @app.route("/api/city_salary") def city_salary(): rows = query( "SELECT city, avg_salary, job_count " "FROM stats_city_salary ORDER BY avg_salary DESC LIMIT 20" ) return jsonify({"code": 0, "data": rows}) @app.route("/api/skill_freq") def skill_freq(): rows = query( "SELECT skill, freq FROM stats_skill_freq ORDER BY freq DESC LIMIT 50" ) return jsonify({"code": 0, "data": rows}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=False)这个接口层做的事情就是「查表-序列化-返回」，逻辑简单但承担整个可视化系统的数据管道出口。DictCursor让每行数据直接成为 JSON 对象，省去手动拼字段。启动服务后可以用curl http://localhost:5000/api/city_salary验证返回结构是否正常。
4.2 ECharts 图表映射：哪张图对应哪个 MR 统计
ECharts 是这些图表的渲染核心，每一张图都对应前文 MR 统计的一个输出。城市平均薪资适合用地图加柱状图联动，技能频次适合词云，学历要求适合饼图，经验限制正态分布状用柱状图表现力更好。下面给出一个加载地图和柱状图的 ECharts 片段。
fetch("/api/city_salary") .then(resp => resp.json()) .then(res => { const cities = res.data.map(d => d.city); const salaries = res.data.map(d => d.avg_salary); const chart = echarts.init(document.getElementById("salaryChart")); chart.setOption({ title: { text: "各城市 Java 岗位平均薪资" }, tooltip: {}, xAxis: { type: "category", data: cities, axisLabel: { rotate: 30 } }, yAxis: { type: "value", name: "平均薪资(K)" }, series: [{ type: "bar", data: salaries, itemStyle: { color: "#3398db" } }] }); });组件初始化的核心在setOption里传入 data 与坐标轴字段。需要提醒的是 ECharts 的地图组件需要额外引入中国地图 GeoJSON 数据，网络上能找到开源的地图 JSON 文件，但如果部署环境不能外网加载，就得把地图文件一起打包进静态目录。毕业设计环境往往不定，我建议优先用 bar 图或饼图，地图数据缺失是现场演示最常见的翻车点。
4.3 筛选下钻：让「可视化」不只是一张静态图
可视化系统的加分项是支持用户交互筛选。具体做法是前端选择城市，后端 SQL 带上城市条件重新统计该城市下不同岗位的薪资分布。
@app.route("/api/city_detail") def city_detail(): city = request.args.get("city", "") rows = query( "SELECT job_title, AVG(avg_salary) as s, COUNT(*) as cnt " "FROM stats_detail " "WHERE city=%s GROUP BY job_title ORDER BY s DESC LIMIT 10", (city,) ) return jsonify(rows)这里直接拼接参数容易产生 SQL 注入，pymysql的%s占位符是参数化查询的标准写法。前端在下钻触发时带?city=上海这样的参数，用户每点一次城市地图上的区域，右侧柱状图就刷一招新的岗位排名数据。这种下钻体验在答辩时加分很明显，因为它证明你懂的不仅是画图，而是完整的数据流转。
5. 部署文档拆解与调优收尾
5.1 伪分布式部署的最小可行配置
毕业设计演示一般给一台 16GB 内存的笔记本，这时候不需要真实的三节点集群，Hadoop 伪分布式模式就够了。部署的核心步骤是配置四个文件：core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml。
<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration> <!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///home/hadoop/data/name</value> </property> </configuration>复制因子设为 1 是因为单机伪分布式只有一份数据，设成 3 会熬出「块副本不足」的健康警告，虽然不阻塞任务但会让你的 MR 任务启动速度明显变慢。NameNode 目录和 DataNode 目录务必不要放在 /tmp 下，Linux 重启后 /tmp 会被清空，届时你的元数据全部丢失。
5.2 三个必须提前打过的坑：端口冲突权限与内存
跑这套系统时的高频踩坑集中在三处。第一，9000 端口被占用，启动start-dfs.sh时提示端口 in use，先lsof -i:9000查占用进程；第二，hdfs dfs -put报权限拒绝，因为 Hadoop 默认用户是 hadoop，上传前hdfs dfs -chmod -R 777 /user/hadoop放宽权限；第三，YARN 内存溢出，MR 任务跑一半 Container 被杀，原因是默认容器内存低于任务需求。
yarn.nodemanager.resource.memory-mb=8192 yarn.scheduler.maximum-allocation-mb=4096 mapreduce.map.memory.mb=1024 mapreduce.reduce.memory.mb=2048本地 16GB 内存的机器按这组参数设置，稳定性和速度比默认配置好很多。重点说一下mapreduce.map.memory.mb和 Reduce 的区别：Map 节点只是读取数据做过滤和拆字段，内存占用小；Reduce 要承载同一 key 的多条记录，聚合长列表时需要更多内存。两个参数值不同是正常的，统一大小反而浪费资源。
5.3 数据链路完整验证：一条命令确认每一层都通了
最后收尾时，我给你一个可靠的验证顺序：先验证 HDFS 数据量，再跑一遍 MR，再查 MySQL 行数，最后看页面接口。
hdfs dfs -du -s hdfs://localhost:9000/user/hadoop/jobs/raw hadoop jar $HADOOP_HOME/contrib/streaming/hadoop-streaming-*.jar \ -files mapper.py,reducer.py -input /user/hadoop/jobs/raw \ -output /user/hadoop/jobs/avg_salary_verify \ -mapper "python3 mapper.py" -reducer "python3 reducer.py" mysql -uroot -p -e "SELECT COUNT(*) FROM jobs_analysis.stats_city_salary;" curl http://localhost:5000/api/city_salary | python3 -m json.tool | head -20这四步分别验证「数据进来了」「计算跑通了」「结果入库了」「页面有数据了」。在交付部署文档时把这四步写成 check_list，评审老师照着跑一遍就能复现整个系统，这比写一千字架构说明更有说服力。如果你在爬虫层增加了代理池或者把 Scrapy 换成分布式爬虫，验证链路的思路是一样的：只要最终落到 HDFS 的文件行数和字段没问题，后面的 MapReduce 分析层感知不到采集层的变化。
本文还有配套的精品资源，点击获取
