“招聘”和“租房”放在一起做大数据分析乍看像两个不相关的方向凑成了一个毕设题目。但认真做完之后我觉得这个组合其实是近几年大数据毕业设计里少见的“好题”——它不要求你发明什么新算法却逼着你把数据采集、清洗、存储、分析、可视化这条链路完整走一遍最后还能产出一个普通用户看得懂、用得上的产品。这篇就围绕我实际完成这个系统的过程讲讲选题逻辑、技术选型、爬虫细节、清洗策略、分析指标设计、可视化落地以及最后答辩时老师真正关心的问题希望能给正在做类似题目的朋友一个参考。1. 这个题目的核心不是“大”而是“组合”1.1 招聘和租房为什么要放一起分析我最初看到这个题目的时候第一个念头也是“这俩也能结合”直到我去想毕业生找工作的完整场景才明白这个组合有多合理。一个应届生或者跳槽的人确定去哪个城市的哪家公司之后紧接着要面对的问题就是住哪儿、房租占工资多大比例。招聘数据告诉你“这个城市平均给到多少薪资”租房数据告诉你“这个城市平均租金水平”两者联合起来才能回答“在这里工作生活成本是否可承受”。所以这套系统的目标用户画像非常清晰即将毕业、对城市选择没有概念的学生以及准备跨城求职、想提前估算生活成本的职场人。它不是给HR用的也不是给中介用的而是给“找工作的人”用的。想明白这一点后续所有功能设计才不会跑偏。1.2 功能定位可视化不只是“画一堆好看的图”很多人做可视化毕设容易陷入一个误区——把柱状图、饼图、折线图、地图全堆在页面上看起来很丰富但完全没有回答用户的问题。我做这个系统时给自己定了三条原则每个图表必须能回答一类具体问题例如“哪个城市的开发岗薪资最高”或者“哪个区域租金最便宜”。招聘和租房的分析结果必须有一个模块实现“交叉比较”这是题目最大的差异化亮点。页面结构按“城市总览 → 行业岗位分析 → 租房区域分析 → 招聘租房联合分析”来组织逻辑上是一个用户从选城市到选区域再到评估生活成本的递进过程。1.3 毕设里的“大数据”到底要多大数据量这是答辩时几乎必被问的问题。说实话本科毕设很难做到真正意义上的海量数据我的做法是招聘数据采集约30万条、租房数据约10万条总量40万条左右。这个量级用单机MySQL加索引完全可以处理但我仍然引入了Hadoop HDFS做文件存储、Spark做离线清洗和统计分析目的不是“为了大数据而大数据”而是让整个处理链路具备“数据量再扩大十倍也能平移扩展”的能力。分布式框架在这个项目里解决的问题不是单机跑不动而是让学生掌握一整套大规模数据处理的工程方法。2. 技术选型每一层为什么选它这套系统的技术栈可以拆成四层来看层次选型主要职责选择理由数据采集Python requests Scrapy抓取招聘和租房公开页面数据生态成熟爬虫写起来快JSON解析方便数据存储HDFS MySQLHDFS存原始日志/文件MySQL存清洗后的结构化结果体现大数据架构分工MySQL方便Web端查询数据处理SparkSpark SQL Pandas数据清洗、字段解析、指标计算、聚合统计Spark处理分布式计算Pandas做单机探索性分析互补可视化与展示Flask ECharts后端提供JSON接口前端渲染交互图表Flask轻量快速ECharts在中文地图、交互性上比Tableau更适合嵌入Web系统2.1 存储层为什么要做HDFS和MySQL双轨真正的大数据系统里原始数据和报表数据通常不放在同一个地方。我的做法是爬虫抓下来的原始JSON和HTML片段先落到HDFS上相当于数据仓库的ODS层原始数据层随后用Spark读HDFS里的原始数据做清洗和解析把结果写入MySQLMySQL里只保存已经结构化好的薪资、区域、期望值等具体字段。这样做的好处是原始数据可回溯——如果清洗规则写错了不需要重新爬虫直接从HDFS重新跑一遍Spark任务就行。对于答辩来说这也是一套可以清晰讲出来的数据架构。2.2 Spark和Pandas的分工Pandas适合在项目初期做数据探索例如我在开始写正式清洗代码前会先读一小部分数据用Pandas看一眼薪资字段有哪几种格式、租房面积有哪些异常值这个过程很快适合画设计清洗规则。但到了正式清洗和统计阶段我会改用Spark——因为数据量达到几十万条以后虽然Pandas也能跑但Spark能让我把清洗流程写成可重复执行的脚本输入是HDFS路径输出是MySQL表通过类似“生产环境”的方式落地。而且用Spark SQL写聚合查询比Pandas链式操作更直观也更容易被答辩老师理解。2.3 Flask ECharts为什么是毕设最优解可视化部分我见过有人用Power BI、Tableau甚至有人把Excel截图贴到Word里交差。但作为一个Web系统最好还是前端框架配合可编程图表库。Flask的好处是简单——不需要学Vue、React那套工程化体系后端Python写接口前端页面用Jinja2模板加原生JavaScript就能搭出完整交互。ECharts则是百度开源的可视化库中文社区资料极多地图、散点图、热力图的开箱效果都很好而且它的配置项结构非常直白稍微看几个示例就能改出自己想要的效果。3. 爬虫实战数据源选择与采集细节3.1 招聘数据抓什么、怎么设计字段我选择了拉勾和BOSS直聘作为主要来源一个是面向互联网行业的垂直平台一个是覆盖面广的综合平台。每条职位数据设计如下字段position_id 职位唯一ID city 城市 position_name 职位名称 company_name 公司名称 industry 公司所在行业 salary_min 最低月薪解析后 salary_max 最高月薪解析后 salary_avg 平均月薪解析后 experience 经验要求应届/1-3年/3-5年/5-10年 education 学历要求大专/本科/硕士/博士 welfare 福利关键词弹性工作、六险一金等 publish_time 发布日期薪资字段是典型的脏数据来源。拉勾的原始薪资文案是“8k-15k·13薪”“25k-50k·16薪”这类格式除了解析出最低和最高月薪还要单独提取“月薪系数”字段。我的做法是新增一个salary_months列默认12如果文本末尾带“·14薪”则取出14最终的年薪估算、月均薪资计算都用salary_avg乘salary_months来算避免直接拿最低工资乘以12导致偏低。3.2 租房数据抓什么、怎么设计字段租房数据我选择链家和贝壳因为它们的房源字段相对规范。字段设计如下house_id city district 行政区/板块 zone 商圈 community 小区名称 rent 月租金元 area 面积㎡ layout 户型2室1厅等 orientation 朝向南/北/南北等 floor 楼层低/中/高 decoration 装修情况 publish_time 发布时间这里有一个字段设计上的小坑面积字段在原始页面上是“58㎡”或者说“58平”如果直接存字符串后续做单位租金元/㎡计算就非常麻烦。清洗时统一转为float类型。朝向字段则需要做多标签标准化例如“南 北”“南北”“南/北”都统一为“南北”。3.3 爬虫合规与频率控制爬公开页面做学术研究是常见做法但要注意几点一是尽量遵守目标网站的robots协议只抓取公开列表页和详情页不碰需要登录才能访问的后台数据二是控制请求频率我采用随机延迟25秒并设置同一IP的最大并发数为1避免对目标服务器造成压力三是采集数据仅用于毕业设计学习研究不公开发布原始数据不做商业用途。这些点不仅是为了安全也会是答辩时老师关注的“数据来源的合规性”。3.4 一个简化的采集示例招聘岗位列表页的采集逻辑其实不复杂核心就三步构造请求、解析HTML、提取字段。我用requests加BeautifulSoup做一个简化示例import requests from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Referer: https://www.example.com/ } def fetch_job_list(city_code, page1): url https://www.example.com/jobs params {city: city_code, page: page} resp requests.get(url, headersheaders, paramsparams, timeout15) resp.encoding resp.apparent_encoding # 避免中文乱码 return BeautifulSoup(resp.text, html.parser) # 提取每条职位的核心信息 soup fetch_job_list(北京, page1) for item in soup.select(.job-item): title item.select_one(.job-title).text.strip() salary item.select_one(.job-salary).text.strip() location item.select_one(.job-location).text.strip() # ... 继续提取然后写入待清洗文件3.5 断点续爬防止中途断网前功尽弃爬虫跑几个小时断掉是家常便饭。我的解决方案是维护一个已抓取ID集合存到本地Redis或一个简单的txt文件里每次抓详情页前先查一下这个ID是否已经抓过抓成功再更新集合。这样即使中间断掉重新运行脚本也会跳过已完成的部分不需要从头再来。另一个经验是每抓500条就把当前批次写入HDFS一个独立文件形成多个小文件方便后面Spark并行读。4. 数据清洗整个项目最花时间的环节4.1 招聘数据清洗的五类脏数据清洗粒度决定分析质量我总结了招聘数据最常见的几类问题薪资格式不统一。“面议”、数字、范围薪都有处理策略是面议置为空值在分析时单独作为“未知”分类不直接丢弃。同一城市不同写法。“北京”、“北京市”、“朝阳区”出现在城市字段里需要按城市字典表做映射统一到“市”一级。经验要求字段类型混杂。“经验不限”、“应届生”、“1-3年”、“3-5年”、“5-10年”等等统一映射成“不限/应届/1-3/3-5/5-10/10年以上”六档。公司规模字段缺失。这个字段可选缺失率很高后期分析只用现有值。发布时间解析。“3天前发布”、“2024-05-12”需要统一转换成标准日期。我用一个专门函数处理相对时间避免直接存字符串。4.2 薪资字段的解析函数这是最核心的清洗逻辑我写了一个函数专门处理薪资文本import re def parse_salary(text): if not text or 面议 in text: return None # 匹配形如 8k-15k 或 8千-1.5万 match re.search(r([\d.])[kK千万]?\s*[-到]\s*([\d.])[kK千万], text) if match: low float(match.group(1)) high float(match.group(2)) if 万 in text: low, high low * 10000, high * 10000 else: low, high low * 1000, high * 1000 avg (low high) / 2 months 12 month_match re.search(r(\d)[薪]?, text) if month_match and 薪 in text: months int(month_match.group(1)) return {salary_min: low, salary_max: high, salary_avg: avg, salary_months: months} return None注意这里的月份的解析逻辑其实要更小心因为“13薪”这种写法匹配到的会是文本中倒数第二个数字而不是开头的第一个数字。我实际用的正则会先分割文本分别从薪资范围和月薪标记两部分提取避免把“8k-15k”中的“15”误当成“15薪”。这种细节如果不处理最后分析结果会明显偏离真实水平。4.3 租房数据清洗的标准化租房数据相比招聘数据更“好洗”但也容易出现面积字段“58㎡”去除单位转浮点朝向文字标准化租金必须转为纯数字去掉“元/月”等单位户型统一为“X室X厅X卫”缺失的厅或卫用0填充楼层“高楼层/共18层”解析出层数便于分析高层和低层的租金差异小区名、商圈名使用统一字典防止同一个小区多写法。4.4 数据质量检查不能只看清洗完的结果清洗不是跑一次就结束的。我在清洗后加了一个质量检查脚本用几条规则校验输出合理性薪资分析的数值占比是否超过95%、每城市记录数是否接近预期、租金有没有明显超出合理范围的异常值例如租金为0或超过10万。同时随机抽5%数据人工跑一遍比对确保解析函数没有系统性偏差。质量检查这块内容在答辩时特别加分因为它体现了“工程上对结果负责”的意识。5. 分析指标招聘与租房的交叉点才是亮点5.1 单域分析先说清楚招聘或租房各自的规律这个部分我做了三类指标招聘侧各城市岗位需求量Top10、各行业平均薪资对比、薪资随工作经验的变化曲线、学历要求分布、热门岗位的城市薪资地图。租房侧各城市或各区域的平均月租金、每平方米单位租金、不同户型租金分布、租金随距离市中心距离的变化趋势。用Spark SQL做聚合计算GROUP BY cityAVG(salary_avg)COUNT(position_id)。核心其实就是一个GROUP BY但需要把结果按城市维度存到一张统计结果表可视化时直接查这张表即可。5.2 联合分析招聘租房压力指数这是系统最有价值的部分。我定义了一个核心指标租房压力指数 月均租金 / 月均薪资。某城市某区域平均月租金6000元而该城市招聘岗位平均薪资11000元压力指数54.5%意味着月薪一半以上要花在房租上。这个指数对求职者来说远比单独看平均薪资有参考价值。为了让联合分析更细我把岗位和企业按所在商圈做关联招聘数据里解析出公司所在区域很多招聘页面会有办公地址租房数据里解析出房源所在区域再用区域名做JOIN就能得出“某个商圈附近岗位的平均薪资”和“这个商圈的平均租金”两个数。计算两者比值便能在城市地图上以区域为单位画出“薪资租金比”的分布。最终的效果是用户在地图上看到的不只是一个一个冰冷的柱状图而是一眼能发现哪些区域性价比高、哪些区域薪资竞争力比较弱。5.3 一个典型的Spark SQL分析示例计算各城市平均薪资和岗位数量的核心SQLSELECT city, COUNT(position_id) AS job_count, ROUND(AVG(salary_avg), 2) AS avg_salary, ROUND(PERCENTILE_CAST(salary_avg, 0.5), 2) AS median_salary FROM cleaned_jobs GROUP BY city ORDER BY job_count DESC;这里我特意多算了一个中位数。原因是薪资平均很容易被少数高薪职位拉高中位数更能体现实用性。在答辩时能主动说出“平均数与中位数差异意味着该城市薪资分布是否两极分化”会给老师很强的专业感。5.4 分析结论的解释图表背后的故事在系统里每类图表下我都写了一段简短的“解读文案”。例如城市薪资地图下方会显示“北京平均薪资约13.8k中位数12k说明高端岗位拉动均值明显租房均价约6800元/月压力指数约49%”。这样的设计让系统看起来像一个能“输出结论”的产品而不是单纯的报表工具。6. 可视化的落地过程从统计结果到交互页面6.1 图表选型与页面结构最终页面按照从宏观到微观的顺序布局图表模块图表类型回答的问题城市岗位分布中国地图 散点岗位集中在哪些城市城市薪资对比柱状图 中位数线哪些城市给得高、是否两极分化行业薪资分布箱线图各行业薪资分位数和离群情况岗位经验薪资曲线折线图经验要求与薪资的递增关系城市租金水平地图 气泡哪些城市租金高区域租金热力热力图城市内部哪些板块租金贵招聘租房联合分析散点气泡图薪资与房租的相关关系“性价比”地图地理坐标气泡哪些区域性价比最高6.2 Flask后端如何把数据交给图表后端很简单做几个JSON接口例如返回各城市平均薪资app.route(/api/city_salary) def city_salary(): rows db.query(SELECT city, job_count, avg_salary FROM stat_city_salary) result [{city: r[city], value: r[avg_salary], job_count: r[job_count]} for r in rows] return jsonify(result)前端用fetch拿到JSON再把数据塞进ECharts的option配置里。地图需要城市和经纬度做映射ECharts自带的geo坐标里已经有城市级数据我只需要把城市名和数值对应上。对于区域级热力图则需要自己准备商圈中心点经纬度这里我用的是公开的地理编码接口把商圈名称转为经纬度数据预存好。6.3 一个笛卡尔坐标系下“招聘-租房联合气泡图”的配置要点联合分析最出效果的就是下面这种图横轴是城市平均月薪纵轴是城市平均月租金每个气泡代表一个城市气泡大小代表岗位量。如果大多数城市的气泡分布在对角线附近意味着“薪水高的地方房租也高”用户就能直观理解城市之间的生活成本关系。option { tooltip: { trigger: item, formatter: function (params) { return params.name br平均月薪 params.value[0] 元 br平均月租 params.value[1] 元 br租房压力指数 (params.value[1] / params.value[0] * 100).toFixed(1) %; } }, xAxis: { name: 平均月薪(元) }, yAxis: { name: 平均月租金(元) }, series: [{ type: scatter, data: citiesData, // [{name:北京, value:[13800, 6800, 8500]}, ...] symbolSize: function (val) { return Math.sqrt(val[2] / 10); // 气泡大小映射岗位量 } }] };6.4 交互设计筛选联动和数据下钻单纯的展示页在答辩时容易被问“你的系统交互性体现在哪”。我做了三个交互点一是顶部城市选择器选择某个城市后下方所有模块联动更新为该城市数据二是图表之间点击联动例如点击地图上的某个城市下方行业分布图自动切换三是下钻功能城市页点击进入“区域分析”二级页面展示该城市各商圈租金和薪资数据。这套交互逻辑并不复杂核心是通过URL参数传递城市名后端根据参数返回对应数据前端在同一套模板里根据URL参数初始化不同图表。6.5 前端性能大数据量下怎么保证不卡40万条数据肯定不能全部推给前端。我的策略是在清洗时就做好预聚合接口返回的都是已经GROUP BY过的统计结果每条记录数控制在几百行以内。普通图表组件一次接收几百条数据完全没问题。如果要对所有岗位做词云例如技能要求Top50也只取Top N而不是全量。这种“先聚合、后传输”的思路和我后面在答辩时讲的“分治”思想是一致的——大数据的精髓就在于不要让原始数据到处乱跑。7. 踩坑记录与答辩经验过来人的几点提醒7.1 爬虫阶段最意外的坑不是被封而是页面结构没找到刚开始写租房爬虫时我以为最大的风险是IP被封。实际上更难受的是某些平台页面是动态渲染的requests拿到的HTML里根本没有房源数据。我的解决办法是先用Chrome开发者工具看接口请求直接请求后端JSON接口这样返回的数据结构还更规整。这也算是一个通用经验优先找接口而不是解析HTML。7.2 中文编码问题爬虫阶段遇到的中文乱码基本都是页面声明的编码和实际内容不一致造成的。统一处理方案是先用apparent_encoding探测再强制指定UTF-8编码写入数据文件。写入MySQL时也要先用set names utf8mb4执行一下否则emoji字符字段会报错。7.3 地图工具里的经纬度偏移制作城市地图时我最初直接拿商圈地名匹配geo坐标发现部分区域在图上的位置偏了一小段。后来才知道国内地图服务商大多使用GCJ-02坐标系而ECharts内置地图也用的这套坐标系所以我这边用高德接口返回的经纬度直接适配没有太大偏差但如果混用了WGS-84的数据就会看到明显偏移。解决方案是保持数据源和展示地图坐标系一致不混用。7.4 采集数据的时效性是真实痛点招聘和租房数据是强时效性数据我的系统抓的是某个时间断面的数据但答辩老师可能会问“你这系统现在还能看到最新数据吗”。我的对策是做了一个很轻量的增量更新脚本每天跑一次抓取前24小时新增的职位和房源。虽然毕业答辩用不太上但完整的设计逻辑讲出来能让系统从“一次性分析工具”变成“可持续运行平台”。7.5 答辩必问的几个问题以及可以参考的回答思路根据我的经验和身边同学的情况整理了几个高频问题Q140万条数据算大数据吗回答思路强调大数据的核心不在于数据绝对量大而在于“单机处理困难、需要分治策略、需要分布式框架配合”。40万条数据放在单机确实能跑但我使用Spark的目的是让处理框架具备扩展性换到几千万条数据时只需增加集群资源不需要改代码。这也是大数据方法论的价值。Q2你的清洗规则怎么确定的回答思路先抽样看数据分布总结出常见模式和异常情况再写规则函数逐条解析最后用质量检查脚本验证字段覆盖率和数值合理性。举例说薪资字段的“8k-15k·13薪”解析过程。Q3招聘和租房两个系统为什么要合并回答思路单独看招聘只能回答薪资水平单独看租房只能回答居住成本合并后才有“租房压力指数”这类真正对求职者有指导意义的指标。这也是整个项目的亮点。Q4ECharts数据量大时为什么卡怎么优化回答思路把聚合下沉到Spark SQL或MySQL前端只接受几百行的统计结果用分页或按需加载代替一次性全量渲染压缩传输数据。Q5系统能上线给真实用户用吗回答思路坦诚说明主要限制是数据源的合规性和采集频率但整个系统架构已经具备上线基础。如果要做正式产品增加数据源授权、部署定时任务即可。最后一点个人体会做这个毕业设计的最大收获其实不是学会了Spark或者ECharts而是学会把一个“看起来很大”的题目拆成一条能落地的流水线先搞清楚用户要什么再决定采集什么数据再设计清洗规则再做聚合计算最后用图表把结论讲清楚。每一步单独看都不难难的是把它们串成一个整体。如果你也选了这类大数据可视化题目我建议把所有精力先花在“数据能不能支撑你要做的分析”上数据扎实了分析才有说服力可视化才不是空壳。还有个实操小技巧录一个不超过五分钟的演示视频从启动爬虫到页面交互完整走一遍答辩时放给老师看比自己对着截图干讲效果好很多。祝你的毕设顺利。