简介基于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 fhttps://www.example.com/api/jobs?page{page}size50 try: r requests.get(url, headersHEADERS, timeout10) r.raise_for_status() return r.json() except requests.HTTPError as e: print(fpage {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_asciiFalse) \n) def main(max_pages120): with open(jobs.jsonl, w, encodingutf-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(fpage {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_pathdedup.txt): seen set() try: with open(dedup_path, r, encodingutf-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 做 ETLMapper 读 JSON Lines 并解析成 JavaBeanReducer 做去重输出 TSV。我实际更推荐把清洗逻辑放在 Mapper 里因为这样整个链路就统一在 Hadoop 体系里演示的时候不需要额外开解释器进程。3.2 理解 Mapper 和 Reducer 的边界哪些事在 Map 做哪些在 Reduce 做写 MR 之前先搞清楚分组逻辑Map 阶段处理每一行输入产出 key-value 对Reduce 阶段接收同一个 key 的所有 value 列表做聚合。招聘分析里最典型的任务是「统计各城市 Java 岗位的平局薪资」此时 key 是 cityvalue 是薪资数值Reducer 计算 sum 和 count。值得注意的事情是凡是能提前过滤的数据尽量在 Mapper 里过滤掉比如只保留职位名称包含 Java 的岗位这能大幅减少 shuffle 的数据量。Reducer 里只做聚合不要再做复杂的字符串处理因为同一 key 的 value 可能分布在很长的一段数据里处理逻辑越简洁整个 job 跑得越快。3.3 Hadoop Streaming 跑 Python MapReduce代码结构与参数说明用 Java 写 MR 还要编译打包开发效率低。Hadoop 提供了 Streaming 机制允许用任意可执行程序充当 Mapper 和 ReducerPython 脚本配合 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这是期望行为。如果希望同一城市的数据分配到同一个 reducerkey 就要用city本身value 里带上前缀标记Reducer 内部再按标记分桶。下面是一个输出技能词频的 Reducer 扩展思路技能字段在清洗时已经被逗号分隔Mapper 里按逗号拆开后逐个输出Reducer 里做标准 wordcount。3.5 MR 结果落地从 HDFS 输出目录导出到 MySQLMR 跑完的结果在 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-infile1 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 keyReducer 计算城市平均薪资salary_min/maxcity薪资 sum / count学历占比educationeducationcount技能频次skillsskillcount经验区间分布experienceexperiencecount4. 可视化层从统计表到可交互的面试官友好界面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(host0.0.0.0, port5000, debugFalse)这个接口层做的事情就是「查表-序列化-返回」逻辑简单但承担整个可视化系统的数据管道出口。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 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 valuefile:///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-mb8192 yarn.scheduler.maximum-allocation-mb4096 mapreduce.map.memory.mb1024 mapreduce.reduce.memory.mb2048本地 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 分析层感知不到采集层的变化。本文还有配套的精品资源点击获取