1. 从一次崩溃的秋招开始为什么我要做就业可视化系统去年秋招我在招聘网站上筛了整整一下午计算机专业岗位页面翻了几十页脑子却越来越乱。有的岗位要求Java有的要求Python一线城市薪资看起来高可投递量也大得吓人培训机构说AI缺口百万招聘网站里的算法岗却没有想象中多。那一刻我突然意识到计算机专业学生做求职决策靠的全是碎片信息。与其继续盲人摸象不如自己动手搭一套基于可视化系统的计算机专业就业形势分析平台把公开岗位数据抓下来、洗干净、算成指标用图表把需求、薪资、技能和城市分布一次性摊开。这个项目我从数据采集一路做到可视化仪表盘这篇文章就是完整复盘写给同样纠结方向和城市的同学也写给想用数据研究就业市场的同行。1.1 传统信息获取方式的死穴先说说我为什么要自己造轮子。市面上的就业信息渠道不少但真正用起来每个都有明显短板。招聘平台本质是搜索引擎它只能回答现在有哪些岗位在招回答不了市场上整体需要多少人北京后端薪资中位数是多少哪类岗位三个月内放量最大。你翻了几十页岗位列表脑子里依然是一堆孤立职位的集合做不了任何聚合判断。经验贴和论坛分享则是另一个极端。上面大量充斥着三本逆袭大厂零基础转码上岸的故事看着热血但存在天然的幸存者偏差写出来的大多是赢家沉默的是大多数。招聘JD反而是求职市场里最诚实的一手数据——企业用真金白银挂出岗位写明技能和薪资不会为了激励你而粉饰自己。与其看一百篇经验贴不如统计一千条真实岗位信息。高校就业质量报告也值得一提。学校发布的毕业生去向和薪资抽样数据确实有统计价值但通常一年才出一期统计口径五花八门发布时已经滞后了半年到一年。对于我这个月该投哪里这种问题它基本帮不上忙。所以我把实时招聘数据当成主数据源就业报告只作为辅助参考。1.2 给可视化系统定的五个分析维度动手写代码之前我先花了两天时间列问题清单反复问自己这个系统到底要回答什么最后收敛成五个维度它们决定了后续所有字段设计、清洗逻辑和图表选型。第一个是地区维度。计算机岗位的地域集中度极高北京、上海、深圳、杭州是传统四强但产业迁移和城市政策让成都、武汉、南京、西安的机会明显变多。我需要知道岗位密度在地图上的真实分布而不是凭印象猜。第二个是岗位类型维度。计算机专业毕业不等于只能当程序员同一专业的人会流向后端、前端、算法、数据分析、运维、测试等不同方向。不做岗位归类屏幕上就是几千条无法对比的岗位名。第三个是技能要求维度。JD里写出来的技术栈就是市场官方需求清单统计这些词的频次能看清每个方向真正的核心技能池。比如后端岗位的JD反复出现Java、Spring、MySQL这个信号比课程大纲可靠得多。第四个是薪资、学历、经验组合维度。只看平均月薪没有任何意义算法岗平均薪资高但硕士比例也高需要把薪资放进学历、经验、城市三个坐标系里去理解。第五个是时间维度。招聘市场有明显的季节波动金三银四、金九银十不是玄学岗位热度会随月份变化。我需要看到岗位量随时间怎么走才能判断现在进场是不是好时机。这五个维度就是需求基线。很多人在做数据项目时一上来就开爬虫、做词云做到一半发现根本没有明确要回答的问题这是最常见的跑偏方式。1.3 系统服务的对象和使用场景第一个版本做完后我拿给室友和学弟看发现他们开口问的几乎都是同一个问题北京和成都的后端岗位薪资到底差多少这让我重新定义了用户画像。第一类是正在投递简历的应届生或转码者他们需要快速了解目标城市的岗位量、薪资中位数和岗位技能要求用来决定简历怎么改、投递顺序怎么排。第二类是还没确定方向的大二大三学生他们可以用词云和桑基图反推如果我现在开始学Go一年后能不能用上。第三类是高校就业指导人员或者做培训课程的人他们需要把宏观就业数据做成可视化素材。使用场景直接影响交互设计。我自己做分析时习惯写脚本查数据库但给别人看时必须有筛选器和钻取操作。比如点击地图上的城市下方的招聘明细表和薪资图要联动刷新这种需求我在后面第四章会细讲。2. 招聘数据采集与清洗这个环节决定了可视化的可信度有人说做可视化项目80%的时间都在洗数据我自己做完后觉得比例只高不低。这个系统的价值建立在数据可信度之上图表再漂亮底层数据是脏的结论就是垃圾。2.1 数据源选择与爬取底线我的数据源以拉勾网和BOSS直聘的公开页面为主另外补充了学校就业指导中心发布的就业质量报告。选这两个平台是因为岗位描述结构相对完整技能关键词在正文里出现的比例高而且已经按城市、经验、薪资做了初步分类后续标准化省事不少。这里必须说清一条底线我只采集公开可访问的页面不登录、不绕过任何访问限制控制爬取频率为每个页面间隔8秒以上遵守网站的robots协议并且只保留岗位文本数据不采集任何个人联系方式。做聚合统计分析不涉及用户隐私。合法合规是这个项目的生命线数据量少一点没关系来源不能有问题。首轮我采集了约1.2万条岗位记录覆盖12个主要城市、8个岗位大类时间跨度约一年。对于个人项目来说这个量级足够支撑趋势分析。城市之间对比时我会把样本量低于50的城市合并到其他分组避免某个城市只有二三十条数据就强行下结论。2.2 数据结构设计一份岗位样本该有哪些字段原始数据不能直接分析我先把它存进SQLite的jobs表。字段设计完全是从五个分析维度反推出来的不想要的字段一律不存省得后面再做二次清洗。字段名样例说明job_titleJava开发工程师岗位原始名称job_categorybackend归一化后的岗位大类city北京统一到地级市名称salary_low / salary_high15000 / 25000月薪区间元salary_unit_typemonthly月薪/年薪标记degree本科学历要求experience_year_min / max1 / 3经验年限区间skill_listjava,spring,mysql从JD正文提取的技能列表post_date2024-05-12发布日期company_size500-2000人公司规模区间source_urlhttps://...用于去重和回溯dedup_key8f3a2c...去重哈希字段之所以把薪资拆成low和high是为了区间统计和箱线图计算。SQLite单文件、零配置、随手能查这个体量完全够用抓的数据真到几十万条再考虑PostgreSQL也不迟。2.3 清洗规则实战薪资、城市、技术栈提取洗数据是最琐碎的部分我挑几个典型case说。薪资字段最常见的原始值是15K-25K·14薪还有月薪15-25K15k~25k年薪30-50万。我的处理逻辑是先按·或空格把区间和补充信息切开出现14薪15薪时把月薪区间换算成年薪中位数存储统一单位时年薪30-50万先转成月薪区间再入库面议单独标记为缺失值不参与均值计算。import pandas as pd import re def parse_salary(s): if not s or 面议 in s: return None, None s s.replace(·, ).replace(~, -).replace(—, -) if 年薪 in s: nums re.findall(r\d(?:\.\d)?, s) if len(nums) 2: return float(nums[0]) * 10000 / 12, float(nums[1]) * 10000 / 12 nums re.findall(r\d(?:\.\d)?, s) if len(nums) 2: return float(nums[0]) * 1000, float(nums[1]) * 1000 return None, None城市字段看似简单实际最乱北京北京市Beijing北京·朝阳区都要归一化到北京。我维护了一张城市别名映射表无法映射且样本中出现次数少于5次的一律归为其他。技能提取是整个清洗链路里最关键的一步。JD里不会有人把技能用逗号隔好而是写在熟悉Spring Boot、MySQL和Redis这种自然语言里。我维护了约300个技术关键词的词典覆盖语言、框架、中间件、数据库、云原生、AI等类别用匹配加最小分词从JD正文里抽取。有一个冲突需要特别处理不能用java作为关键词否则会把JavaScript误判成Java。词表规则里匹配到javascript或node.js时不算java只有独立词java才计入。2.4 需求热度指数的计算逻辑直接用岗位数量做趋势图有个问题一周前发的岗位和半年前发的岗位被算成同一条远期僵尸岗位会把趋势拉平。我引入需求热度指数核心思路是发布时间越近岗位活跃度越高。计算方式分三步。对每条岗位记录算时间衰减权重w exp(-(today - post_date)/tau)tau取90天。热度指数H sum(w_i * size_weight_i)其中size_weight按公司规模设定50人以下0.8、50到500人1.0、500人以上1.3、2000人以上1.5。这样近期的、来自大厂的岗位对热度贡献更高更接近真实市场需求变化。公司规模加权的理由很直接大厂一个岗位JD背后往往对应更大的招聘量虽然JD不会写招50人但公司规模可以作为需求规模的近似代理变量。这个指标不完美但比单纯计数更有参考价值至少能过滤掉大量已经失效的旧岗位干扰。3. 技术选型与系统架构我用什么把数据变成仪表盘做之前我在用BI工具快速搞定还是自己写代码之间犹豫了一段时间。我把三条路线都试了一遍下面是我的真实体验。3.1 三种路线的取舍方案优点缺点适合的人Power BI / Tableau图表丰富、拖拽建模、上手快高级交互受限模板容易千篇一律数据刷新配置麻烦不想写代码、只做一次性报告Python Flask ECharts前后端完全可控图表表现力最强适合放简历作品集开发量大要写前端页面有Web经验、最终要正式部署展示Streamlit pyecharts几十行代码出交互界面复用ECharts能力开发效率极高自定义排版受限但做数据看板完全够用数据分析师、想要快速出成果的人我最终选了Streamlit pyecharts的组合。原因很实际我的核心目标是验证就业可视化分析这个思路不是练Web开发。Streamlit的筛选控件能自动生成左侧面板和我的五个分析维度天然匹配。如果你做这个项目是为了展示前端能力那就选FlaskECharts自己控制布局细节。3.2 落地架构与数据流整个系统数据流是单向的我把它分成四层采集层Python脚本 requests BeautifulSoup定时抓取公开岗位页面解析后写入SQLite存储层SQLite单文件数据库包含jobs原始岗位表、skill_dict技能词典表、region_mapping城市映射表分析层pandas读取SQLite计算岗位分类、热度指数、薪资分位数和技能频次结果以DataFrame缓存展示层Streamlit应用调用pyecharts生成图表组合成仪表盘。这套架构的好处是每个环节都能独立替换。比如某天发现页面HTML结构变了只需要重写采集层的解析函数想换MySQL只改数据库连接部分。分层清晰后后期迭代省心很多。数据更新节奏我定为每月跑一次全量采集同时把发布时间超过180天的岗位标记为过期避免库里堆积陈旧数据。实际跑一次大约40分钟挂机执行就行。为了不让页面加载卡顿我在后端对每个城市、岗位大类、月份做了预聚合图表渲染时直接取聚合结果而不是实时扫全表。3.3 交互式仪表盘的关键设计筛选与钻取仪表盘不是图表的堆叠它需要一条清晰的使用动线。我的页面结构是这样组织的顶部是三个KPI卡片在库岗位数、平均岗位热度、技能关键词覆盖数一进来就有全局概念。左栏是筛选器城市多选、岗位大类多选、发布时间范围滑块。中间主区域从上到下依次是需求热力地图、岗位类型分布柱状图、技能词云、薪资箱线图和时间趋势折线。交互上最重要的设计是点击钻取当用户点击地图上的省份时页面读取当前视角下该省份的岗位子集下方所有图表联动刷新到该省份。在Streamlit里实现这个效果并不复杂用st.session_state记录点击事件再把筛选条件作为全局状态传给每个图表。为了联动不卡我提前按城市和省份预聚合了指标每次点击只过滤聚合结果不实时扫原始表。3.4 部署自己用和分享出去的区别如果只是自己用本地跑一下streamlit run app.py就完事了。但要分享给室友和老师就涉及两类情况。一类是校园网内临时分享。我直接用了Streamlit的局域网访问模式启动时设置--server.address和--server.port8501同一个WiFi下就能打开。另一类是长期在线访问我后来把项目打包成Docker镜像部署在一台云服务器上用nginx做反向代理。这里提醒一句Streamlit的WebSocket连接在nginx反代时一定要配置Upgrade请求头否则页面会不断重连这个问题我折腾了半天。部署层面还加了一个定时任务每天凌晨3点由cron触发采集脚本更新完数据库后刷新缓存。这样别人每次打开看到的都是最近的数据不需要手动点击更新。4. 每张图表对应一个决策问题可视化设计思路拆解做可视化最忌讳因为好看所以放上去。我在项目里给自己定了一条硬规定任何一张图必须能回答一个具体的求职决策问题答不上来就删掉。4.1 需求热力地图去哪个城市投简历第一张图是全量岗位的城市热力地图。我用pyecharts的Map类型以城市为粒度用颜色从浅蓝到深红表示岗位热度指数。这里藏着一个可视化陷阱如果直接按岗位数量映射颜色上海和银川之间的差距可能超过100倍绝大多数城市都被压成浅色地图完全失去分层能力。我的处理方法是把热度指数取对数之后再映射色阶并在图例上注明颜色经过对数变换。这样才能同时看清头部城市和腰部城市的差异。这张地图回答的问题非常直接图上一线城市的颜色深得发红新一线处于第二梯队机会明显少一些但竞争也没那么惨烈。对于要不要去北上广深这种纠结光看颜色分布就能建立初步判断。4.2 技能词云与岗位流向图我该学什么技术第二组图是技能词云和岗位流向桑基图。词云用JD里抽取出的技能词频控制字号大小词频越高字越大。这里有个关键操作词频统计必须按岗位大类分组再展示。比如后端岗位技能词云和算法岗位技能词云是两张完全不同的图否则Java和Python这种头部词会把小众方向的特征彻底淹没。桑基图的思路更适合回答方向选择问题左侧节点是岗位大类右侧节点是技能关键词连线宽度表示这类岗位对这项技能的需求量。从这张图上能一眼看出后端岗位的流量集中在Java、Spring、MySQL算法岗位往Python、PyTorch、TensorFlow汇聚。纠结学什么的时候沿着感兴趣的岗位往上走看看它身上挂着哪些技能再判断自己愿不愿意学、能不能学会。4.3 薪资-学历-经验组合图我大概值多少钱薪资是所有人最关心的指标但只画一个全岗位平均薪资的柱状图信息量太少。我更推荐分组箱线图横轴是岗位大类纵轴是月薪每组按学历经验拆成几个箱体。箱线图的优势在于能同时呈现中位数、四分位距和离群点。面试几家拿到的Offer差距往往很大箱体的宽度就代表这个岗位薪资的波动幅度。比如算法岗的中位数明显高于后端但箱体也长说明同样是算法岗不同公司给的差异非常大。我还做了一张雷达图来做岗位画像对比维度包括需求量、薪资中位数、学历门槛、经验门槛和技能广度。雷达图在画之前必须做min-max归一化否则薪资这种数值大的维度会完全支配图形形状。算法岗的雷达图在学历门槛和薪资两项上凸出需求量却相对低前端岗在需求量上凸出薪资中位数中等这种形状差异比文字描述直观得多。4.4 时间趋势折线现在入场还来得及吗最后一组是时间维度。我把每月岗位热度指数画成折线再叠一条30天移动平均线来平滑季节性波动。金三银四和金九银十会在这张图上形成两个明显的峰值暑假前后则是低谷。这张图对我的实际决策帮助最大秋招开始前一个月投递简历回复率明显高于暑假盲投阶段因为岗位释放量和活跃度正在爬坡。更进一步的视角是把时间趋势和岗位大类叠在一起观察不同方向的需求节奏差异。后端岗位全年都相对平稳算法岗的岗位量则在春招时明显放量。这类信息可以直接用来设计求职时间表而单看某个时点的静态数据做不到。5. 从可视化结果里读出来的几条趋势数据抓完、图表上线之后我终于可以退后一步像看陌生人项目一样审视这套系统。以下结论均基于我个人采集的公开岗位样本覆盖约1.2万条记录、时间跨度近一年仅供求职策略参考不构成精确的行业统计。5.1 岗位结构与薪资画像从岗位分布柱状图看后端开发岗位的需求占比最高样本里约占26%到30%前端开发紧随其后约18%到22%测试与运维合计约14%到16%数据分析约5%算法岗约8%到10%其他方向包括安全、嵌入式、产品技术等约15%。薪资箱线图的结论更有意思。算法岗月薪中位数最高但学历门槛也最硬硕士及以上学历在算法岗位JD里出现的比例明显高于其他方向。后端和前端的中位数比较接近但前端的四分位距更宽头部互联网公司和中小外包之间的薪资差距被拉得很开。运维和安全岗位的起步薪资略低但需求相对稳定经验积累后薪资爬坡更平滑。5.2 城市梯度差异一线、新一线与二线怎么选热力地图上最显眼的是北京、上海、深圳、杭州四城合起来占了样本里60%左右岗位。广州和成都处于第二梯队武汉、南京、西安、苏州紧随其后。这个分布不意外但说明一个道理只看房价和通勤时间忽略岗位密度很容易做出不匹配市场的选择。新一线城市的薪资虽然比一线低15%到20%但扣除房租后的可支配收入差距明显缩小。尤其是后端和测试方向成都、武汉的薪资已经和广州差距不大生活成本却低得多。我做系统时加了一个薪资-房租比衍生指标把平均租金数据和薪资中位数放一起作为城市决策的辅助参考。这个指标不高深但很实用能直接回答我去这个城市到底能剩下多少钱。5.3 技术栈变迁JD高频词告诉我们什么技能词云按季度分别生成后对比能看到几条明显变化。Java、Spring、MySQL始终是后端岗位的高频词属于求职安全牌。Python的频次仍在上升但要求已经从会写变成会写并且会用框架。Go和云原生技术栈比如Docker、Kubernetes出现频次逐季度上升。数据库方向上Redis、Elasticsearch、消息队列Kafka这类中间件被列出的比例越来越高。技术栈对比给我的实际启发是选一个主技术栈深入没有过时分布式和云原生相关的通用能力正在成为中高级岗位的共同要求。对在校生来说与其纠结Java还是Python不如先选定主语言再补中间件和工程化能力这些词在JD里跨岗位反复出现说明它们是市场公认的硬通货。5.4 把结论转成投递策略有了这些结论我的投递策略完全变成数据驱动。首先是岗位选择优先挑岗位需求热度与自身技能重合度超过70%的方向。其次是城市组合一线投大厂、新一线投成长期公司这种配比能提高面试邀约率。再次是时间把握把投递集中期和岗位热度峰值对齐提前一个月开始投正好撞上岗位释放窗口。简历上的技术栈也根据技能词云做了调整去掉低频词把高频词按岗位需求重新排序。这套流程跑下来虽然不能保证Offer但至少不会在方向选择上拍脑袋。6. 项目落地中踩过的坑和后续优化方向这个项目前后做了快两个月踩坑比写功能花的时间还多我把最典型的几个分享出来帮后来者少走弯路。6.1 数据层面的坑第一坑是僵尸岗位。有些JD发布日期超过半年还挂在平台可能是企业一直没删也可能是关掉又重发。不过滤时间的话这类岗位会把需求热度拉高误导趋势判断。我最后把发布时间超过180天的记录全部标记为失效统计和图表里默认不展示。第二坑是重复招聘。同一家大厂的后端岗位会有几十条类似JD分属不同部门拿企业名岗位名去重会被误算成几十个岗位。解决方式是把去重键设计成岗位名称规范化值城市技能列表哈希发布月份的组合这样既能识别同一部门在不同月份的补招又不误杀不同团队的独立招聘。第三坑是面议薪资。样本里薪资面议的比例一度高达20%高级岗位尤其常见。如果直接忽略薪资分析会产生系统性偏差因为高级岗位恰恰更容易面议。我的处理方式是保留记录但不参与均价计算同时在仪表盘里增加面议占比指标提醒看数据的人知道薪资中位数存在低估风险。6.2 可视化层面的坑词云最大的问题是业务词干扰。负责熟悉了解优先这些词频极高但没有决策价值不洗掉的话整个词云会被它们占满。我建了一张停用词表并且把技能词典提取放在统计之前确保词云里只出现技术关键词。雷达图的量纲问题也很典型。薪资中位数是元级别需求量是几百上千的计数学历门槛只有1到3的等级直接画雷达图的话薪资维度会完全支配图形形状。所有维度必须先归一化还要注意归一化方法如果某个维度的最小值不是0min-max归一化后它会在雷达图中心附近凹陷造成视觉误导。更保险的方式是让最小值映射到0.1保留底座。热力地图的颜色分级问题我前面提过再强调一遍直接线性映射时绝大多数城市会被压成同一色阶等于没做。取对数、分位数分段、自定义颜色区间都可以关键是图例上写清楚不能让读者被视觉欺骗。6.3 从展示到预测的下一步当前系统仍然以描述历史为主下一步我想升级成预测未来。方向有三个第一用时间序列模型对下个季度各岗位需求热度做预测把未来三个月哪种岗位会放量直接画出来第二基于岗位技能和薪资特征训练一个简单的薪资区间预测模型输入城市方向学历经验返回一个预估薪资区间这对学生设定目标特别有用第三把公共技术事件、开源项目动态、重点公司招聘动向的文本信号接入系统尝试从事件层面预判后续招聘变化。我还有一个想法是把简历解析接进来。把个人简历解析成技能列表和岗位需求热度做匹配度评分相当于把就业市场分析和个体求职直接打通。这个功能对求职者的价值会比单纯看仪表盘更大。做完这个项目回头看最大的收获不是图表多好看而是我开始用数据思维想就业这件事。过去我总在要不要转算法去北京还是杭州这类问题里空转现在遇到类似选择会先去看市场上对应的岗位数量、薪资、门槛和趋势再结合自身条件做判断。这套方法论完全可以迁移到任何职业决策场景。如果你也想做类似的分析系统我的建议很简单先想清楚要回答什么问题再动手爬数据图表能少放就少放但每张图都得扛得住一句追问。数据是旧的问题是新的把这两个点持续迭代这个项目就不会变成一次性的玩具。