1. 这套系统的起点先想清楚分析什么和推荐什么做招聘数据可视化与分析这类的项目第一反应往往是我先抓数据、建数仓、跑模型、再怼个大屏。但真正动手之后你会发现卡住进度的从来不是框架本身而是你根本说不清楚分析出来给谁看、推荐给谁用。我最初拿到这个需求的时候某公司人力平台那边给的目标非常朴素求职者投简历像开盲盒企业收简历像大海捞针两边都在凭感觉做事。他们想要的东西拆开其实是三件事——第一市场上哪些岗位在涨、哪些技能在贬值薪资到底被什么因素拉高或压低第二能不能根据一个人的经历和偏好主动推给他一批匹配度高的岗位第三所有结论要能放到一张大屏上开会、汇报、做决策时一眼能看懂。所以确切地说这个项目的完整名字应该是招聘数据可视化分析与推荐系统hadoopsparkhive 只是它的底座薪资预测、岗位推荐、可视化大屏分别对应了分析、匹配、展示三个环节。整个链路从数据接入开始经过 Hive 数仓分层存储再到 Spark 做批量计算和模型训练最后结果落到关系型数据库和大屏接口层。推荐系统单独走一条离线计算 结果缓存的路径保证页面响应速度。项目做完以后我对这一类系统最大的感受是数据的口径统一比技术选型重要得多。比如平均薪资到底是算术平均还是中位数、高薪岗位的阈值划在哪一档、推荐是优先保准确率还是保覆盖率这些不定义清楚后面所有环节都会返工。1.1 招聘数据分析场景的特殊性招聘数据和其他行业数据有一个明显差异它既有结构化字段城市、学历要求、经验年限、薪资区间又有强文本属性岗位名称、技能标签、职位描述。薪资还是典型的区间值而不是单点数比如15-20K·14薪拆起来比想象中麻烦。更麻烦的是同一家公司不同部门的岗位命名风格差异极大高级Java开发工程师和Java技术专家可能干的是同一件事但薪资带宽完全不同。在做字段设计时我给岗位定义了一套统一标签体系岗位大类后端开发、前端开发、算法、测试、运维、产品、运营、设计、市场、销售等、技能标签Java、Python、Spring、Spark、Flink等、行业归属互联网、金融、制造、零售等、公司规模档位0-20人、20-99人、100-499人、500-1999人、2000人以上。这套体系是做可视化分析和薪资预测的共同基础推荐系统也靠它计算相似度。1.2 为什么选 Hadoop Spark Hive 这套组合标题里这三个组件放在一起基本可以确定是一个典型的离线数仓 批处理架构。HDFS 负责底层存储Hive 承担数据仓库的建模与管理Spark 跑核心计算和算法模型。这个组合最大的优势在于生态统一——Spark 可以直接读 Hive 表通过 Catalog 共享元数据写起来不用在不同引擎之间来回搬运数据。如果数据量没有到 TB 级甚至 PB 级用这套架构看起来有点重但它带来的收益是清晰的第一存储与计算分离数仓分层之后每一层都可以独立回溯第二集群扩展方便数据涨了加节点就行第三Spark 的 DataFrame API 和 MLlib 能在一套代码里完成从 ETL 到模型训练的全流程不用跨多个系统。我在环境规划上做了一个很多人忽略的决定Hive 的存储格式统一用 ORC Snappy 压缩。实测下来相比默认的 TextFile查询性能至少提升三倍而且支持列裁剪和谓词下推。代价是中间结果无法直接用文本编辑器查看调试期稍微有点不习惯但进入稳定期以后这个代价完全值得。2. 数据从哪来、怎么进数仓Hive 分层与清洗细节招聘数据的来源无非三种招聘网站公开页面、企业官网的招聘频道、少量通过接口获取的结构化数据。考虑到合规性我在项目里没有做全网爬取而是收集了几个主要渠道在授权范围内的公开职位信息再补了一批模拟生成的种子数据用于验证链路。这里必须说清楚任何做数据项目的朋友优先确认数据源的可获取性和合规边界这比技术方案更前置。原始数据落到 HDFS 之后粗略统计每天新增大约 20 万条岗位记录累计三个月能到千万级。这个量级对 Hadoop 生态来说完全是热身级别但恰恰是这种不算大也不算小的数据最容易暴露数仓设计粗糙的问题——表建少了后面天天写嵌套子查询分区字段选错了跑任务时眼睁睁看着扫描全表。2.1 原始数据字段构成与数据质量现状抓下来的原始数据字段列表大致如下字段名含义示例主要质量问题job_title岗位名称高级Java开发工程师命名粒度不一致company_name公司名称某科技有限公司同一公司多种写法city工作城市上海部分数据为空salary_min / salary_max薪资下限/上限K15 / 20区间解析困难salary_period薪资周期14薪文本格式多样experience经验要求3-5年区间解析困难education学历要求本科枚举值不统一skills技能标签Java,Spring,MySQL分隔符不统一industry所属行业互联网部分缺失company_size公司规模500-1999人文本格式多样publish_date发布日期2024-11-20少量乱序最头痛的是薪资字段。招聘网站为了展示效果喜欢写15-20K·14薪、20-35K·15薪有的写面议有的写3-5万/月。如果直接按照 max 或者 min 提取数值预测模型和可视化统计都会产生系统性偏差。我最终的做法是先写一个薪资解析 UDF把所有文本统一转成月薪数值规则是——XXK·XX薪拆成单月基础薪资再乘以薪期系数除以12个月XX万/月直接换算成 K纯区间取中位数面议标记为 null 并单独归为一档不参与回归模型的训练。2.2 ODS / DWD / DWS / ADS 四层建设思路Hive 数仓我严格按照四层来建每一层的职责必须清晰不能图省事把表都堆在同一层ODS 层原始数据层保持原样入仓按dt做天级分区。这里不做任何清洗字段名和数据质量保留最初状态方便日后回溯排查。DWD 层明细数据层做清洗与标准化解析薪资、拆分技能标签、统一公司名称、补齐城市枚举。这层是后续所有计算的唯一可信数据源任何业务方要用数据都从这层取。DWS 层汇总数据层按主题做轻度汇总比如岗位维度的日新增统计城市维度的薪资分布直方图技能标签的词频统计。这样做的价值在于可视化接口的查询基本都落在 DWS 层响应速度能控制在秒级。ADS 层应用数据层面向具体应用场景定制包括大屏需要的指标结果、推荐系统的用户-岗位匹配结果、薪资预测模型的预测结果。表命名上我习惯加前缀来表明分层比如ods_job_post_raw、dwd_job_post_cleaned、dws_job_city_salary_stats、ads_job_recommend_result。这样在写 SQL 的时候扫一眼表名就知道数据到了哪一层、可不可以直接用。2.3 薪资字段的标准化工序全项目最容易被低估的步骤写一个薪资解析函数看起来简单真正动手才发现字符串格式五花八门。实测下来常见的模式至少有十几种15-20K、15-20K·13薪、20-35K·15薪、3-5万/月、3-5万、100-150万/年、面议、薪资面议、300元/天、4-6千/月还有少数直接写15K以上这种开放性区间。我最后写了一套规则优先的解析逻辑先正则匹配主模式再对特殊格式逐一兜底。以下是核心处理思路def parseMonthlySalary(raw: String): Double { if (raw null || raw.trim.isEmpty || raw.contains(面议)) return NaN val monthlyPattern (\\d(?:\\.\\d)?)[-~](\\d(?:\\.\\d)?)K.r val annualPattern (\\d(?:\\.\\d)?)[-~](\\d(?:\\.\\d)?)万.r raw match { case monthlyPattern(min, max) val base (min.toDouble max.toDouble) / 2.0 parseSalaryPeriodFactor(raw) * base case annualPattern(min, max) val base (min.toDouble max.toDouble) / 2.0 * 10 parseSalaryPeriodFactor(raw) * base case _ NaN } }里面最值得注意的细节是薪期系数。互联网行业写14薪15薪非常普遍如果忽略这个系数同一份工作用月薪口径统计会偏低 10% 到 20%。我的处理方式是从文本中单独提取薪期数字统一年化后再除以 12。做完这一步之后后续所有的统计口径都基于年化月薪避免了同岗位不同公司薪期差异带来的偏差。提示薪资面议的数据不要直接丢弃。可视化分析中可以单独统计面议岗位占比这本身就是一个有价值的信息维度——它往往和岗位职级、薪资敏感性有相关性。2.4 分区策略与小文件治理数仓稳定运行的前提Hive 表我统一用dt日期分区作为第一级分区因为招聘数据的分析场景里按天增量是最自然的节奏。部分大表加了第二级分区city_level一线城市/新一线/二线/其他但实际测试下来收益有限反而增加了分区数量后面就取消了只保留日期分区。增量数据落地的过程里小文件问题比数据倾斜更早出现。招聘数据源本身是碎片化的每天从多个渠道收集每个渠道都可能产生几十个小文件。如果直接 INSERT 进 Hive 表一天积累下来可能产生上千个小文件每次 Spark 读表光打开文件就要浪费大量时间。我的处理方式是在写入前对 DataFrame 执行repartition(分区数, col(dt))让每个 Spark 分区对应一个 Hive 分区并且把分区内文件数量控制在 1-2 个。同时在 Hive 表属性里开启了orc.compress和文件合并相关的参数在周末低峰期手动跑一次ALTER TABLE ... CONCATENATE做小文件合并。这套组合拳打完任务运行时间稳定在原来的 60% 左右。3. Spark 在这里干了什么从统计报表到薪资预测模型Hive 把数仓建好之后计算层的主角就是 Spark。我在项目里把 Spark 的职责分成了两大块第一块是用 Spark SQL 做常规指标统计统一口径、生成 DWS 层汇总数据第二块是用 MLlib 训练薪资预测模型这也是标题里薪资预测最核心的部分。两块都在同一个 Spark Session 里完成读取 Hive 表、写回 Hive 表全程不走外部存储。为什么不直接用 Hive 跑 SQL因为薪资预测涉及特征工程和模型迭代用 SQL 做特征拼接虽然也能实现但每调整一次特征都要改一大段 HQL调试效率太低。Spark 的 DataFrame API 能让特征工程和模型训练在同一个程序里连贯运行数据直接以 DataFrame 形式从 Hive 读取这才是 Spark 在这个架构里不可替代的原因。3.1 Spark SQL 批处理与指标口径统一做可视化大屏的基础是那些聚合统计指标比如城市平均薪资 Top10、岗位数量分布饼图、技能词云、近 30 天薪资趋势。我建了一套专门的指标计算任务每晚定时跑把结果写入 DWS 层的独立结果表大屏后端直接查询结果表不直接扫描明细表。指标口径制定过程中最容易踩的坑是**平均这个词的定义**。常规统计学喜欢用算术平均但招聘数据的薪资分布是明显的右偏分布——少数高薪岗位会把平均数拉得很高。我最终在项目中同时计算了平均值、中位数和 P75 分位数可视化页面上默认展示中位数因为中位数更能反映大多数求职者能拿到的薪资水平。Spark SQL 的代码风格比较朴素基本都是标准的GROUP BY 聚合函数。真正需要注意的反而是数据倾斜问题比如Java这种热门技能标签的行数可能是Rust标签的几百倍。我在做技能词频统计时先用explode把技能数组炸开再用filter清理空值和纯空白字符串最后再做聚合。那段代码看起来简单实测数据量大了之后explode会产生大量中间行建议配合repartition控制并行度。3.2 薪资预测的特征工程数字不能直接喂给模型薪资预测本质上是一个回归问题我们的目标是输入岗位属性输出预测的月薪数值。刚开始我也踩过特征越全越好的误区——把岗位名称、公司名、城市、学历、经验、技能标签全塞进去结果模型训练倒是很快但预测结果毫无解释性而且某些特征比如公司名直接造成了严重的过拟合。后来重新梳理了特征体系最终保留了以下维度城市编码把城市映射为一线/新一线/二线/三线/其他这是薪资差异最大的结构性因素。岗位大类编码按 10 大类组织算法岗和运营岗的薪资带宽差异非常大模型需要学习到这个差异。经验要求把3-5年转换成数值区间下限 3 和上限 5再取均值作为特征。学历要求按学历等级映射为数字大专1本科2硕士3博士4不限0。技能标签数量技能数量越多通常对应技术栈更复杂的岗位但也不是绝对。行业编码互联网、金融、制造等行业之间的薪资水平有明显差异。公司规模按规模档位映射为 1-5 的等级。这些特征里绝大多数是类别型特征我全部用StringIndexer转成数值索引再通过OneHotEncoderEstimator做独热编码。数值型特征如经验年限、技能个数则做了标准化防止量纲差异影响模型收敛。用一个简单的例子说明两个岗位一个是上海-算法工程师-硕士-3年-互联网-500人以上另一个是某县城-行政专员-大专-不限经验-制造业-20人以下喂给模型的特征向量应该能够显著拉开差异模型才有能力预测出合理的薪资差距。3.3 模型训练与评估为什么选了 GBT 回归而不是线性回归模型选型我做了一轮对比实验参与候选的有线性回归、决策树回归、随机森林回归和 GBT梯度提升树回归。直接说结论线性回归R2 大概 0.42MAE 在 6K 左右。问题在于薪资和特征之间不是简单的线性关系比如经验从 1 年到 3 年的薪资增幅和从 8 年到 10 年的增幅完全不同线性模型无法刻画这种非线性。随机森林回归R2 到 0.61MAE 降到 4.5K。训练速度快参数少作为 baseline 非常合适。GBT 回归R2 到 0.68MAE 降到 3.8K。效果最好代价是训练时间长了约一倍但对这个数据量级完全可接受。最终选了 GBT 回归器参数大致如下val gbt new GBTRegressor() .setFeaturesCol(features) .setLabelCol(label) .setMaxIter(100) .setMaxDepth(6) .setStepSize(0.1) .setSubsamplingRate(0.8)训练之前做了标准化的 8:2 切分训练集 80 万条测试集 20 万条。评估指标上除了 RMSE 和 MAE我还额外关注了一个指标预测值落在真实薪资区间内的比例。因为招聘领域的薪资本身就是一个区间概念如果预测值和真实值相差在 15% 以内就算一个合格预测。这个口径做出来合格预测的比例大约在 60% 出头作为离线模型的 baseline 已经具备参考价值。3.4 预测结果如何落地成可解释的数字模型训练完不是终点关键在于把预测结果变成业务方能理解的信息。我在 ADS 层建了一张薪资预测结果表字段包括岗位 ID、预测薪资、真实薪资如果有、预测置信度、参与预测的特征快照。大屏上展示的薪资预测除了人数均值和众数还会按城市、岗位大类、经验段做交叉分析。这里的实操细节是不要只存一个预测值要把预测模型的版本号也存下来。因为模型会迭代同一个岗位在不同版本下预测结果可能不同。如果可视化界面上突然出现薪资异常波动可以通过版本号定位是不是模型更新导致的而不是误判为市场变化。模型训练任务在调度体系里跑在 DWS 层数据更新之后依赖关系用调度平台的任务 A 成功后触发任务 B来保证。整个链路跑完大约需要 40 分钟其中特征工程占了大头模型训练本身在 100 迭代下只需要十分钟出头。4. 岗位推荐系统看似简单坑都在数据里推荐系统是标题里的另一个重头戏。招聘场景的推荐和电商推荐有本质区别电商推荐追求点击率和转化率用户点错了最多是误买成本不高招聘推荐一旦推荐了不匹配的岗位用户会产生强烈的这个平台不懂我的观感流失率极高。所以我把推荐系统的设计原则定为宁可少推不可错推。这也决定了我在算法选型上的倾向——不追求最前沿的深度模型而是在可解释性、可维护性、效果三者的平衡点上找方案。4.1 推荐策略选型基于内容 vs 协同过滤对比了两种主流方案协同过滤ALS能捕捉相似人群的偏好但有一个致命前提——需要足够多的用户行为数据。招聘平台的用户行为天然稀疏一个人一年可能只投递几十份简历浏览记录也没有电商那么频繁。ALS 在数据稀疏场景下表现很一般容易所有用户被推荐同一批热门岗位。基于内容的推荐不依赖用户行为而是计算用户画像与岗位画像之间的相似度。用户画像是从他的简历里抽取——技能标签、期望城市、工作经验、学历岗位画像是从岗位详情里抽取——同样的技能标签、工作地点、经验要求、岗位类别。相似度用余弦相似度计算直观、可解释而且冷启动友好。最终我采用基于内容 规则加权的方案协同过滤作为补充策略只在用户行为数据积累较充分的条件下启用。具体来说主推荐计算用户画像与岗位画像的余弦相似度相似度 Top 50 的岗位进入候选池。规则过滤剔除已经在用户投递记录中的岗位、薪资低于用户期望的岗位、城市不匹配的岗位。兜底策略如果候选池不足 20 个从热门岗位中补足保证推荐列表不为空。4.2 构建用户画像与岗位画像的实操细节用户画像和岗位画像的构建逻辑是对称的都做成了标签向量。用户简历解析出以下字段期望城市、期望薪资、技能标签从项目经历中提取、工作年限、学历、目标岗位类别。岗位侧同样抽取城市、薪资范围、技能要求、经验要求、学历要求、岗位类别。技能标签的标准化是核心难点。简历里写Java和岗位要求里写JAVA或Java开发的相似度如何计算纯字符串匹配一定会漏。我的做法是维护一份技能同义词表java、Java、JAVA、java开发全部归一化到javapython和Python归一到python另外解决一些复合词比如大数据开发标签会拆分出hadoop、spark、hive等子技能。这份同义词表初期手工维护后面根据推荐效果持续迭代。画像向量的权重设置也做了一些调优。技能标签的权重最高其次是城市匹配再次是岗位类别和学历。实际操作时我在相似度计算里加入了城市匹配的惩罚项城市不匹配直接扣掉 30% 的相似度分。这一步是调试过程中试出来的结论——很多用户根本不会考虑异地岗位就算其他标签相似度极高城市不匹配照样不会投递。4.3 冷启动与推荐结果的解释性冷启动问题在招聘推荐里分两种新用户没有简历、老用户简历信息量不足。项目中的处理方式新用户没有简历时展示热门岗位榜——根据投递量和社会关注度排名。这个榜单有天然的推荐合理性至少不会让用户觉得推荐的岗位完全不搭边。等用户浏览了 5 个以上岗位后再根据他的浏览行为动态调整画像切换到个性化推荐。简历信息量不足时我会把画像中不确定的部分加入置信度概念。技能标签不足 3 个的用户相似度计算时给每个匹配技能更大的权重并额外增加一条规则优先推荐热门岗位类别里的中低竞争岗位因为这类岗位对人才要求更宽容推荐后用户实际投递的转化率会更高。推荐结果的解释性也是我特意做的一个点。推荐列表里的每个岗位都带了 3 个推荐原因标签比如技能匹配Java、Spring城市匹配上海岗位类别匹配后端开发。前端把这些原因展示出来用户能理解为什么给我推这个信任感提升非常明显。4.4 离线计算 结果缓存的更新节奏推荐计算不要求实时用户画像的更新频率是每天一次。每天凌晨 Spark 任务会将前一天的用户行为数据合并进画像表重新计算所有活跃用户的推荐列表结果写入ads_job_recommend_result表。后端接口读这个表时加了一层 Redis 缓存缓存有效期 6 小时有效避免了大屏和接口频繁查询 Hive 表带来的延迟问题。这套离线方案的延迟在于——用户当天新增的行为要第二天才能体现在推荐里。但我实测下来对招聘场景来说这个延迟完全可以接受因为用户的求职意向通常是相对稳定的不太会出现上午看了前端职位下午就必须给我推前端这种强实时需求。真要做实时推荐技术栈就要引入 Flink 和在线向量检索复杂度和成本都会大幅上升现阶段性价比不高。5. 可视化大屏数据分析的最后一公里大屏是这个项目最容易出效果、也最容易做得华而不实的地方。很多团队喜欢把大屏做成数据炫技墙——动态流光、3D 地球、异常酷炫的转场但数据本身经不起推敲。我在设计时定了两条原则第一大屏上的每个数字和图表都必须指向一个明确的业务动作第二如果大屏上的信息无法支撑会议决策那就是纯装饰。最终的大屏采用 1920×1080 分辨率的布局以地图、柱状图、折线图、词云、雷达图为主要图表类型。后端用 Spring Boot 提供 HTTP 接口数据从 DWS/ADS 层读取并聚合后以 JSON 格式返回。前端用 Vue ECharts 渲染每 30 秒自动轮询一次接口保证大屏上的数据能反映最新计算结果。5.1 大屏整体布局与数据接口设计大屏的布局我先列了一个核心指标区——总岗位数、今日新增岗位、平均薪资中位数、高薪岗位占比、热门技能 Top5、岗位供需比这些是管理者最关心的指标。中间区域放一张城市薪资地图用热力色阶展示不同城市的平均薪资水平右侧区域放岗位类别分布饼图和技能词云底部区域放近 30 天薪资走势折线图和学历要求分布柱状图。数据接口设计有一个经验可以分享大屏接口的返回体量一定要小。很多前端开发习惯让后端直接返回全量明细数据然后在前端做聚合但大屏数据源在数仓里全量明细可能有几十万行前端渲染直接卡死。我的做法是后端接口只返回聚合好的 JSON一个接口对应一个图表数据量控制在几十条到几百条之间。前端拿到数据直接映射到 ECharts 的 series性能非常稳定。5.2 核心图表与业务含义的对应关系每个图表我都做了明确的业务定义城市薪资地图用于回答去哪些城市薪资更有竞争力。地图上采用中位数薪资而非平均薪资因为高薪岗位集中在一线城市平均薪资会让新一线城市看起来毫无吸引力。岗位类别分布饼图用于回答哪些岗位需求量最大。这里我看的是岗位存量占比而不是投递量占比因为投递量受品牌声量和曝光影响太大不能真实反映市场需求。技能词云用于回答哪些技能是当前市场的硬通货。词频来自清库后 DWD 层表里skills字段的 explode 结果再用 TF 权重做归一化。词云字体大小对应词频排名。学历要求分布柱状图按岗位数量统计各学历档位占比并配合本科及以上比例这一行指标直观反映学历门槛变化。薪资走势折线图按日期展示全岗位中位数薪资的 30 天趋势用于揭示短期供需波动。这些图表搭配在一起基本覆盖了看行情—挑城市—选岗位—估薪资的决策路径。5.3 展示口径大屏到底给谁看大屏的观众通常有两类一类是公司管理层他们要的是宏观趋势和对策建议另一类是 HR 运营团队他们要的是可操作的数据洞察。两者关注的点完全不同。管理层看的是城市盘子怎么分布、薪资是否有异常、热门人才流向哪里运营团队看的是哪些技能供给不足、哪些城市需要加大招聘力度、哪些岗位长期挂着招不到人。所以我在大屏上额外放了两块运营向的内容长期挂职岗位 Top10和供不应求技能方向。前者直接从岗位发布时间超过 90 天但状态仍为招聘中的岗位中筛出后者通过对比岗位需求量和简历供给量得出。这两块数据能直接转化为运营动作是我觉得整个大屏最有实际价值的部分。5.4 大屏性能和刷新机制上的优化细节大屏作为 7×24 小时挂在会议室的系统稳定性和流畅度比功能丰富更重要。优化经验整理为以下几点图表销毁重建ECharts 实例在数据刷新时要dispose后再重新init避免内存泄漏和叠影。轮询接口加条件判断前端每次请求先带一个lastUpdate参数后端返回dataVersion如果版本没变就直接返回 304 或空数据减少无效传输。静态资源 CDN 本地缓存大屏的 JS、CSS 体积不小首屏加载速度直接影响开会体验务必做好缓存。数据异常兜底接口返回空值时图表显示暂无数据而不是渲染成空白否则大屏会显得像出了故障。6. 踩坑记录从数据倾斜到预测偏差任何项目在真实环境中跑起来都会遇到文档里没写过的问题这套系统也不例外。下面记录几个让我印象最深的坑和处理过程希望对后来者有帮助。6.1 Hive 小文件过多引发的任务卡死项目运行两周之后Spark 任务的执行时间从 25 分钟悄悄涨到了 50 分钟一度逼近 60 分钟。查看 Spark UI发现大部分时间花在了文件读取阶段。定位后发现每天增量写入 DWD 层时因为每个渠道产生的文件太小导致 HDFS 上积累了成千上万个小文件。排查方式是看 Hive 表的文件数量hdfs dfs -ls /user/hive/warehouse/dwd_job_post_cleaned/dt2024-11-20发现这个分区下有几十个几十 KB 的小文件。修复手段有两个第一是在 Spark 写入前repartition控制分区数第二是对历史分区执行ALTER TABLE ... CONCATENATE合并小文件。双管齐下之后任务时长恢复到了 25 分钟左右。6.2 Join 数据倾斜导致的 OOM做 DWS 层城市-岗位-技能多维汇总时某一座一线城市的岗位数据量远大于其他城市Spark 执行join时发生了数据倾斜部分 Executor 直接 OOM。我当时用两种方式解决方案一优先采用对热点 Key 加随机前缀做两阶段聚合。具体做法是不直接影响结果——先对热点城市的数据加一个 0-9 的随机后缀将一个大 Key 拆成 10 个小 Key 分别聚合再做第二轮合并。方案二如果倾斜规模可控改用Broadcast Join把小表广播到每个 Executor避免 Shuffle。但要求小表数据量小于 10MB 左右否则广播本身就有成本。我最终在热点城市场景下用了方案一。这种盐化 两阶段聚合的写法是处理数据倾斜的通用手段值得记录到自己的常用工具库里。6.3 薪资预测低估高薪岗位的问题模型上线后可视化大屏上出现了一个扎眼的现象薪资预测的最低值和真实数据差距不大但高薪岗位的预测值明显偏低。100 万年薪以上的岗位模型大多只预测出 60-70 万。原因分析后发现高薪岗位样本量非常少。训练集中年薪 80 万以上的样本占比只有 0.5% 左右GBT 回归在拟合过程中为了降低整体损失会主动牺牲那些稀疏的高薪样本。解决办法有两个方向一是对高薪样本做过采样把权重调高二是使用分位数回归或者单独训练一个高薪岗位子模型。实验下来过采样 单独训练高薪段模型的组合效果最好高薪岗位的 MAE 从 25 万降到了 12 万左右。但代价是代码复杂度上来了所以我在最终版本中对通用模型和高薪模型做了分档预测超过 80 万年薪的岗位走子模型其余走通用模型。6.4 调度与数据回溯补数据比写代码更考验人整个系统依赖 6-7 个定时任务链路是数据采集 - ODS - DWD - DWS - ADS - 模型训练 - 推荐结果 - 大屏刷新。任何一环失败下游数据就会缺。有一次某个上游数据源连续三天没有更新导致 DWD 层连续三天没有增量数据下游任务全都哑掉了。问题不在任务失败而在回溯机制。数据源恢复之后直接重跑当天的任务只能补齐一天的增量前三天缺的数据需要手动补跑。我在调度平台上给每个任务都配了重跑指定日期区间的能力并且补数任务执行时会自动检查目标分区的数据是否完整不完整就报错提示。这样虽然补数仍要人工触发但至少不会出现看似跑完、实际没有数据的隐性失败。这个项目跑通半年之后我最大的体会是技术架构的复杂度可以慢慢提升但数据的质量和口径一致性必须从第一天就盯紧。Hadoop、Spark、Hive 提供了稳定的底座但真正的价值来自数据能不能讲出可信的故事——薪资预测是否贴近市场、推荐结果能不能帮人找到机会、大屏上的数字是否可以支撑决策。如果从头再来一次我会在第一天就把数据规范和数据质量监控做扎实那才是这个系统持续运转的根基。