1. 這套系統(tǒng)的起點先想清楚分析什么和推薦什么做招聘數(shù)據(jù)可視化與分析這類的項目第一反應(yīng)往往是我先抓數(shù)據(jù)、建數(shù)倉、跑模型、再懟個大屏。但真正動手之后你會發(fā)現(xiàn)卡住進(jìn)度的從來不是框架本身而是你根本說不清楚分析出來給誰看、推薦給誰用。我最初拿到這個需求的時候某公司人力平臺那邊給的目標(biāo)非常樸素求職者投簡歷像開盲盒企業(yè)收簡歷像大海撈針兩邊都在憑感覺做事。他們想要的東西拆開其實是三件事——第一市場上哪些崗位在漲、哪些技能在貶值薪資到底被什么因素拉高或壓低第二能不能根據(jù)一個人的經(jīng)歷和偏好主動推給他一批匹配度高的崗位第三所有結(jié)論要能放到一張大屏上開會、匯報、做決策時一眼能看懂。所以確切地說這個項目的完整名字應(yīng)該是招聘數(shù)據(jù)可視化分析與推薦系統(tǒng)hadoopsparkhive 只是它的底座薪資預(yù)測、崗位推薦、可視化大屏分別對應(yīng)了分析、匹配、展示三個環(huán)節(jié)。整個鏈路從數(shù)據(jù)接入開始經(jīng)過 Hive 數(shù)倉分層存儲再到 Spark 做批量計算和模型訓(xùn)練最后結(jié)果落到關(guān)系型數(shù)據(jù)庫和大屏接口層。推薦系統(tǒng)單獨走一條離線計算 結(jié)果緩存的路徑保證頁面響應(yīng)速度。項目做完以后我對這一類系統(tǒng)最大的感受是數(shù)據(jù)的口徑統(tǒng)一比技術(shù)選型重要得多。比如平均薪資到底是算術(shù)平均還是中位數(shù)、高薪崗位的閾值劃在哪一檔、推薦是優(yōu)先保準(zhǔn)確率還是保覆蓋率這些不定義清楚后面所有環(huán)節(jié)都會返工。1.1 招聘數(shù)據(jù)分析場景的特殊性招聘數(shù)據(jù)和其他行業(yè)數(shù)據(jù)有一個明顯差異它既有結(jié)構(gòu)化字段城市、學(xué)歷要求、經(jīng)驗?zāi)晗?、薪資區(qū)間又有強(qiáng)文本屬性崗位名稱、技能標(biāo)簽、職位描述。薪資還是典型的區(qū)間值而不是單點數(shù)比如15-20K·14薪拆起來比想象中麻煩。更麻煩的是同一家公司不同部門的崗位命名風(fēng)格差異極大高級Java開發(fā)工程師和Java技術(shù)專家可能干的是同一件事但薪資帶寬完全不同。在做字段設(shè)計時我給崗位定義了一套統(tǒng)一標(biāo)簽體系崗位大類后端開發(fā)、前端開發(fā)、算法、測試、運(yùn)維、產(chǎn)品、運(yùn)營、設(shè)計、市場、銷售等、技能標(biāo)簽Java、Python、Spring、Spark、Flink等、行業(yè)歸屬互聯(lián)網(wǎng)、金融、制造、零售等、公司規(guī)模檔位0-20人、20-99人、100-499人、500-1999人、2000人以上。這套體系是做可視化分析和薪資預(yù)測的共同基礎(chǔ)推薦系統(tǒng)也靠它計算相似度。1.2 為什么選 Hadoop Spark Hive 這套組合標(biāo)題里這三個組件放在一起基本可以確定是一個典型的離線數(shù)倉 批處理架構(gòu)。HDFS 負(fù)責(zé)底層存儲Hive 承擔(dān)數(shù)據(jù)倉庫的建模與管理Spark 跑核心計算和算法模型。這個組合最大的優(yōu)勢在于生態(tài)統(tǒng)一——Spark 可以直接讀 Hive 表通過 Catalog 共享元數(shù)據(jù)寫起來不用在不同引擎之間來回搬運(yùn)數(shù)據(jù)。如果數(shù)據(jù)量沒有到 TB 級甚至 PB 級用這套架構(gòu)看起來有點重但它帶來的收益是清晰的第一存儲與計算分離數(shù)倉分層之后每一層都可以獨立回溯第二集群擴(kuò)展方便數(shù)據(jù)漲了加節(jié)點就行第三Spark 的 DataFrame API 和 MLlib 能在一套代碼里完成從 ETL 到模型訓(xùn)練的全流程不用跨多個系統(tǒng)。我在環(huán)境規(guī)劃上做了一個很多人忽略的決定Hive 的存儲格式統(tǒng)一用 ORC Snappy 壓縮。實測下來相比默認(rèn)的 TextFile查詢性能至少提升三倍而且支持列裁剪和謂詞下推。代價是中間結(jié)果無法直接用文本編輯器查看調(diào)試期稍微有點不習(xí)慣但進(jìn)入穩(wěn)定期以后這個代價完全值得。2. 數(shù)據(jù)從哪來、怎么進(jìn)數(shù)倉Hive 分層與清洗細(xì)節(jié)招聘數(shù)據(jù)的來源無非三種招聘網(wǎng)站公開頁面、企業(yè)官網(wǎng)的招聘頻道、少量通過接口獲取的結(jié)構(gòu)化數(shù)據(jù)?？紤]到合規(guī)性我在項目里沒有做全網(wǎng)爬取而是收集了幾個主要渠道在授權(quán)范圍內(nèi)的公開職位信息再補(bǔ)了一批模擬生成的種子數(shù)據(jù)用于驗證鏈路。這里必須說清楚任何做數(shù)據(jù)項目的朋友優(yōu)先確認(rèn)數(shù)據(jù)源的可獲取性和合規(guī)邊界這比技術(shù)方案更前置。原始數(shù)據(jù)落到 HDFS 之后粗略統(tǒng)計每天新增大約 20 萬條崗位記錄累計三個月能到千萬級。這個量級對 Hadoop 生態(tài)來說完全是熱身級別但恰恰是這種不算大也不算小的數(shù)據(jù)最容易暴露數(shù)倉設(shè)計粗糙的問題——表建少了后面天天寫嵌套子查詢分區(qū)字段選錯了跑任務(wù)時眼睜睜看著掃描全表。2.1 原始數(shù)據(jù)字段構(gòu)成與數(shù)據(jù)質(zhì)量現(xiàn)狀抓下來的原始數(shù)據(jù)字段列表大致如下字段名含義示例主要質(zhì)量問題job_title崗位名稱高級Java開發(fā)工程師命名粒度不一致company_name公司名稱某科技有限公司同一公司多種寫法city工作城市上海部分?jǐn)?shù)據(jù)為空salary_min / salary_max薪資下限/上限K15 / 20區(qū)間解析困難salary_period薪資周期14薪文本格式多樣experience經(jīng)驗要求3-5年區(qū)間解析困難education學(xué)歷要求本科枚舉值不統(tǒng)一skills技能標(biāo)簽Java,Spring,MySQL分隔符不統(tǒng)一industry所屬行業(yè)互聯(lián)網(wǎng)部分缺失company_size公司規(guī)模500-1999人文本格式多樣publish_date發(fā)布日期2024-11-20少量亂序最頭痛的是薪資字段。招聘網(wǎng)站為了展示效果喜歡寫15-20K·14薪、20-35K·15薪有的寫面議有的寫3-5萬/月。如果直接按照 max 或者 min 提取數(shù)值預(yù)測模型和可視化統(tǒng)計都會產(chǎn)生系統(tǒng)性偏差。我最終的做法是先寫一個薪資解析 UDF把所有文本統(tǒng)一轉(zhuǎn)成月薪數(shù)值規(guī)則是——XXK·XX薪拆成單月基礎(chǔ)薪資再乘以薪期系數(shù)除以12個月XX萬/月直接換算成 K純區(qū)間取中位數(shù)面議標(biāo)記為 null 并單獨歸為一檔不參與回歸模型的訓(xùn)練。2.2 ODS / DWD / DWS / ADS 四層建設(shè)思路Hive 數(shù)倉我嚴(yán)格按照四層來建每一層的職責(zé)必須清晰不能圖省事把表都堆在同一層ODS 層原始數(shù)據(jù)層保持原樣入倉按dt做天級分區(qū)。這里不做任何清洗字段名和數(shù)據(jù)質(zhì)量保留最初狀態(tài)方便日后回溯排查。DWD 層明細(xì)數(shù)據(jù)層做清洗與標(biāo)準(zhǔn)化解析薪資、拆分技能標(biāo)簽、統(tǒng)一公司名稱、補(bǔ)齊城市枚舉。這層是后續(xù)所有計算的唯一可信數(shù)據(jù)源任何業(yè)務(wù)方要用數(shù)據(jù)都從這層取。DWS 層匯總數(shù)據(jù)層按主題做輕度匯總比如崗位維度的日新增統(tǒng)計城市維度的薪資分布直方圖技能標(biāo)簽的詞頻統(tǒng)計。這樣做的價值在于可視化接口的查詢基本都落在 DWS 層響應(yīng)速度能控制在秒級。ADS 層應(yīng)用數(shù)據(jù)層面向具體應(yīng)用場景定制包括大屏需要的指標(biāo)結(jié)果、推薦系統(tǒng)的用戶-崗位匹配結(jié)果、薪資預(yù)測模型的預(yù)測結(jié)果。表命名上我習(xí)慣加前綴來表明分層比如ods_job_post_raw、dwd_job_post_cleaned、dws_job_city_salary_stats、ads_job_recommend_result。這樣在寫 SQL 的時候掃一眼表名就知道數(shù)據(jù)到了哪一層、可不可以直接用。2.3 薪資字段的標(biāo)準(zhǔn)化工序全項目最容易被低估的步驟寫一個薪資解析函數(shù)看起來簡單真正動手才發(fā)現(xiàn)字符串格式五花八門。實測下來常見的模式至少有十幾種15-20K、15-20K·13薪、20-35K·15薪、3-5萬/月、3-5萬、100-150萬/年、面議、薪資面議、300元/天、4-6千/月還有少數(shù)直接寫15K以上這種開放性區(qū)間。我最后寫了一套規(guī)則優(yōu)先的解析邏輯先正則匹配主模式再對特殊格式逐一兜底。以下是核心處理思路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 } }里面最值得注意的細(xì)節(jié)是薪期系數(shù)?；ヂ?lián)網(wǎng)行業(yè)寫14薪15薪非常普遍如果忽略這個系數(shù)同一份工作用月薪口徑統(tǒng)計會偏低 10% 到 20%。我的處理方式是從文本中單獨提取薪期數(shù)字統(tǒng)一年化后再除以 12。做完這一步之后后續(xù)所有的統(tǒng)計口徑都基于年化月薪避免了同崗位不同公司薪期差異帶來的偏差。提示薪資面議的數(shù)據(jù)不要直接丟棄。可視化分析中可以單獨統(tǒng)計面議崗位占比這本身就是一個有價值的信息維度——它往往和崗位職級、薪資敏感性有相關(guān)性。2.4 分區(qū)策略與小文件治理數(shù)倉穩(wěn)定運(yùn)行的前提Hive 表我統(tǒng)一用dt日期分區(qū)作為第一級分區(qū)因為招聘數(shù)據(jù)的分析場景里按天增量是最自然的節(jié)奏。部分大表加了第二級分區(qū)city_level一線城市/新一線/二線/其他但實際測試下來收益有限反而增加了分區(qū)數(shù)量后面就取消了只保留日期分區(qū)。增量數(shù)據(jù)落地的過程里小文件問題比數(shù)據(jù)傾斜更早出現(xiàn)。招聘數(shù)據(jù)源本身是碎片化的每天從多個渠道收集每個渠道都可能產(chǎn)生幾十個小文件。如果直接 INSERT 進(jìn) Hive 表一天積累下來可能產(chǎn)生上千個小文件每次 Spark 讀表光打開文件就要浪費大量時間。我的處理方式是在寫入前對 DataFrame 執(zhí)行repartition(分區(qū)數(shù), col(dt))讓每個 Spark 分區(qū)對應(yīng)一個 Hive 分區(qū)并且把分區(qū)內(nèi)文件數(shù)量控制在 1-2 個。同時在 Hive 表屬性里開啟了orc.compress和文件合并相關(guān)的參數(shù)在周末低峰期手動跑一次ALTER TABLE ... CONCATENATE做小文件合并。這套組合拳打完任務(wù)運(yùn)行時間穩(wěn)定在原來的 60% 左右。3. Spark 在這里干了什么從統(tǒng)計報表到薪資預(yù)測模型Hive 把數(shù)倉建好之后計算層的主角就是 Spark。我在項目里把 Spark 的職責(zé)分成了兩大塊第一塊是用 Spark SQL 做常規(guī)指標(biāo)統(tǒng)計統(tǒng)一口徑、生成 DWS 層匯總數(shù)據(jù)第二塊是用 MLlib 訓(xùn)練薪資預(yù)測模型這也是標(biāo)題里薪資預(yù)測最核心的部分。兩塊都在同一個 Spark Session 里完成讀取 Hive 表、寫回 Hive 表全程不走外部存儲。為什么不直接用 Hive 跑 SQL因為薪資預(yù)測涉及特征工程和模型迭代用 SQL 做特征拼接雖然也能實現(xiàn)但每調(diào)整一次特征都要改一大段 HQL調(diào)試效率太低。Spark 的 DataFrame API 能讓特征工程和模型訓(xùn)練在同一個程序里連貫運(yùn)行數(shù)據(jù)直接以 DataFrame 形式從 Hive 讀取這才是 Spark 在這個架構(gòu)里不可替代的原因。3.1 Spark SQL 批處理與指標(biāo)口徑統(tǒng)一做可視化大屏的基礎(chǔ)是那些聚合統(tǒng)計指標(biāo)比如城市平均薪資 Top10、崗位數(shù)量分布餅圖、技能詞云、近 30 天薪資趨勢。我建了一套專門的指標(biāo)計算任務(wù)每晚定時跑把結(jié)果寫入 DWS 層的獨立結(jié)果表大屏后端直接查詢結(jié)果表不直接掃描明細(xì)表。指標(biāo)口徑制定過程中最容易踩的坑是**平均這個詞的定義**。常規(guī)統(tǒng)計學(xué)喜歡用算術(shù)平均但招聘數(shù)據(jù)的薪資分布是明顯的右偏分布——少數(shù)高薪崗位會把平均數(shù)拉得很高。我最終在項目中同時計算了平均值、中位數(shù)和 P75 分位數(shù)可視化頁面上默認(rèn)展示中位數(shù)因為中位數(shù)更能反映大多數(shù)求職者能拿到的薪資水平。Spark SQL 的代碼風(fēng)格比較樸素基本都是標(biāo)準(zhǔn)的GROUP BY 聚合函數(shù)。真正需要注意的反而是數(shù)據(jù)傾斜問題比如Java這種熱門技能標(biāo)簽的行數(shù)可能是Rust標(biāo)簽的幾百倍。我在做技能詞頻統(tǒng)計時先用explode把技能數(shù)組炸開再用filter清理空值和純空白字符串最后再做聚合。那段代碼看起來簡單實測數(shù)據(jù)量大了之后explode會產(chǎn)生大量中間行建議配合repartition控制并行度。3.2 薪資預(yù)測的特征工程數(shù)字不能直接喂給模型薪資預(yù)測本質(zhì)上是一個回歸問題我們的目標(biāo)是輸入崗位屬性輸出預(yù)測的月薪數(shù)值。剛開始我也踩過特征越全越好的誤區(qū)——把崗位名稱、公司名、城市、學(xué)歷、經(jīng)驗、技能標(biāo)簽全塞進(jìn)去結(jié)果模型訓(xùn)練倒是很快但預(yù)測結(jié)果毫無解釋性而且某些特征比如公司名直接造成了嚴(yán)重的過擬合。后來重新梳理了特征體系最終保留了以下維度城市編碼把城市映射為一線/新一線/二線/三線/其他這是薪資差異最大的結(jié)構(gòu)性因素。崗位大類編碼按 10 大類組織算法崗和運(yùn)營崗的薪資帶寬差異非常大模型需要學(xué)習(xí)到這個差異。經(jīng)驗要求把3-5年轉(zhuǎn)換成數(shù)值區(qū)間下限 3 和上限 5再取均值作為特征。學(xué)歷要求按學(xué)歷等級映射為數(shù)字大專1本科2碩士3博士4不限0。技能標(biāo)簽數(shù)量技能數(shù)量越多通常對應(yīng)技術(shù)棧更復(fù)雜的崗位但也不是絕對。行業(yè)編碼互聯(lián)網(wǎng)、金融、制造等行業(yè)之間的薪資水平有明顯差異。公司規(guī)模按規(guī)模檔位映射為 1-5 的等級。這些特征里絕大多數(shù)是類別型特征我全部用StringIndexer轉(zhuǎn)成數(shù)值索引再通過OneHotEncoderEstimator做獨熱編碼。數(shù)值型特征如經(jīng)驗?zāi)晗?、技能個數(shù)則做了標(biāo)準(zhǔn)化防止量綱差異影響模型收斂。用一個簡單的例子說明兩個崗位一個是上海-算法工程師-碩士-3年-互聯(lián)網(wǎng)-500人以上另一個是某縣城-行政專員-大專-不限經(jīng)驗-制造業(yè)-20人以下喂給模型的特征向量應(yīng)該能夠顯著拉開差異模型才有能力預(yù)測出合理的薪資差距。3.3 模型訓(xùn)練與評估為什么選了 GBT 回歸而不是線性回歸模型選型我做了一輪對比實驗參與候選的有線性回歸、決策樹回歸、隨機(jī)森林回歸和 GBT梯度提升樹回歸。直接說結(jié)論線性回歸R2 大概 0.42MAE 在 6K 左右。問題在于薪資和特征之間不是簡單的線性關(guān)系比如經(jīng)驗從 1 年到 3 年的薪資增幅和從 8 年到 10 年的增幅完全不同線性模型無法刻畫這種非線性。隨機(jī)森林回歸R2 到 0.61MAE 降到 4.5K。訓(xùn)練速度快參數(shù)少作為 baseline 非常合適。GBT 回歸R2 到 0.68MAE 降到 3.8K。效果最好代價是訓(xùn)練時間長了約一倍但對這個數(shù)據(jù)量級完全可接受。最終選了 GBT 回歸器參數(shù)大致如下val gbt new GBTRegressor() .setFeaturesCol(features) .setLabelCol(label) .setMaxIter(100) .setMaxDepth(6) .setStepSize(0.1) .setSubsamplingRate(0.8)訓(xùn)練之前做了標(biāo)準(zhǔn)化的 8:2 切分訓(xùn)練集 80 萬條測試集 20 萬條。評估指標(biāo)上除了 RMSE 和 MAE我還額外關(guān)注了一個指標(biāo)預(yù)測值落在真實薪資區(qū)間內(nèi)的比例。因為招聘領(lǐng)域的薪資本身就是一個區(qū)間概念如果預(yù)測值和真實值相差在 15% 以內(nèi)就算一個合格預(yù)測。這個口徑做出來合格預(yù)測的比例大約在 60% 出頭作為離線模型的 baseline 已經(jīng)具備參考價值。3.4 預(yù)測結(jié)果如何落地成可解釋的數(shù)字模型訓(xùn)練完不是終點關(guān)鍵在于把預(yù)測結(jié)果變成業(yè)務(wù)方能理解的信息。我在 ADS 層建了一張薪資預(yù)測結(jié)果表字段包括崗位 ID、預(yù)測薪資、真實薪資如果有、預(yù)測置信度、參與預(yù)測的特征快照。大屏上展示的薪資預(yù)測除了人數(shù)均值和眾數(shù)還會按城市、崗位大類、經(jīng)驗段做交叉分析。這里的實操細(xì)節(jié)是不要只存一個預(yù)測值要把預(yù)測模型的版本號也存下來。因為模型會迭代同一個崗位在不同版本下預(yù)測結(jié)果可能不同。如果可視化界面上突然出現(xiàn)薪資異常波動可以通過版本號定位是不是模型更新導(dǎo)致的而不是誤判為市場變化。模型訓(xùn)練任務(wù)在調(diào)度體系里跑在 DWS 層數(shù)據(jù)更新之后依賴關(guān)系用調(diào)度平臺的任務(wù) A 成功后觸發(fā)任務(wù) B來保證。整個鏈路跑完大約需要 40 分鐘其中特征工程占了大頭模型訓(xùn)練本身在 100 迭代下只需要十分鐘出頭。4. 崗位推薦系統(tǒng)看似簡單坑都在數(shù)據(jù)里推薦系統(tǒng)是標(biāo)題里的另一個重頭戲。招聘場景的推薦和電商推薦有本質(zhì)區(qū)別電商推薦追求點擊率和轉(zhuǎn)化率用戶點錯了最多是誤買成本不高招聘推薦一旦推薦了不匹配的崗位用戶會產(chǎn)生強(qiáng)烈的這個平臺不懂我的觀感流失率極高。所以我把推薦系統(tǒng)的設(shè)計原則定為寧可少推不可錯推。這也決定了我在算法選型上的傾向——不追求最前沿的深度模型而是在可解釋性、可維護(hù)性、效果三者的平衡點上找方案。4.1 推薦策略選型基于內(nèi)容 vs 協(xié)同過濾對比了兩種主流方案協(xié)同過濾ALS能捕捉相似人群的偏好但有一個致命前提——需要足夠多的用戶行為數(shù)據(jù)。招聘平臺的用戶行為天然稀疏一個人一年可能只投遞幾十份簡歷瀏覽記錄也沒有電商那么頻繁。ALS 在數(shù)據(jù)稀疏場景下表現(xiàn)很一般容易所有用戶被推薦同一批熱門崗位。基于內(nèi)容的推薦不依賴用戶行為而是計算用戶畫像與崗位畫像之間的相似度。用戶畫像是從他的簡歷里抽取——技能標(biāo)簽、期望城市、工作經(jīng)驗、學(xué)歷崗位畫像是從崗位詳情里抽取——同樣的技能標(biāo)簽、工作地點、經(jīng)驗要求、崗位類別。相似度用余弦相似度計算直觀、可解釋而且冷啟動友好。最終我采用基于內(nèi)容 規(guī)則加權(quán)的方案協(xié)同過濾作為補(bǔ)充策略只在用戶行為數(shù)據(jù)積累較充分的條件下啟用。具體來說主推薦計算用戶畫像與崗位畫像的余弦相似度相似度 Top 50 的崗位進(jìn)入候選池。規(guī)則過濾剔除已經(jīng)在用戶投遞記錄中的崗位、薪資低于用戶期望的崗位、城市不匹配的崗位。兜底策略如果候選池不足 20 個從熱門崗位中補(bǔ)足保證推薦列表不為空。4.2 構(gòu)建用戶畫像與崗位畫像的實操細(xì)節(jié)用戶畫像和崗位畫像的構(gòu)建邏輯是對稱的都做成了標(biāo)簽向量。用戶簡歷解析出以下字段期望城市、期望薪資、技能標(biāo)簽從項目經(jīng)歷中提取、工作年限、學(xué)歷、目標(biāo)崗位類別。崗位側(cè)同樣抽取城市、薪資范圍、技能要求、經(jīng)驗要求、學(xué)歷要求、崗位類別。技能標(biāo)簽的標(biāo)準(zhǔn)化是核心難點。簡歷里寫Java和崗位要求里寫JAVA或Java開發(fā)的相似度如何計算純字符串匹配一定會漏。我的做法是維護(hù)一份技能同義詞表java、Java、JAVA、java開發(fā)全部歸一化到j(luò)avapython和Python歸一到python另外解決一些復(fù)合詞比如大數(shù)據(jù)開發(fā)標(biāo)簽會拆分出hadoop、spark、hive等子技能。這份同義詞表初期手工維護(hù)后面根據(jù)推薦效果持續(xù)迭代。畫像向量的權(quán)重設(shè)置也做了一些調(diào)優(yōu)。技能標(biāo)簽的權(quán)重最高其次是城市匹配再次是崗位類別和學(xué)歷。實際操作時我在相似度計算里加入了城市匹配的懲罰項城市不匹配直接扣掉 30% 的相似度分。這一步是調(diào)試過程中試出來的結(jié)論——很多用戶根本不會考慮異地崗位就算其他標(biāo)簽相似度極高城市不匹配照樣不會投遞。4.3 冷啟動與推薦結(jié)果的解釋性冷啟動問題在招聘推薦里分兩種新用戶沒有簡歷、老用戶簡歷信息量不足。項目中的處理方式新用戶沒有簡歷時展示熱門崗位榜——根據(jù)投遞量和社會關(guān)注度排名。這個榜單有天然的推薦合理性至少不會讓用戶覺得推薦的崗位完全不搭邊。等用戶瀏覽了 5 個以上崗位后再根據(jù)他的瀏覽行為動態(tài)調(diào)整畫像切換到個性化推薦。簡歷信息量不足時我會把畫像中不確定的部分加入置信度概念。技能標(biāo)簽不足 3 個的用戶相似度計算時給每個匹配技能更大的權(quán)重并額外增加一條規(guī)則優(yōu)先推薦熱門崗位類別里的中低競爭崗位因為這類崗位對人才要求更寬容推薦后用戶實際投遞的轉(zhuǎn)化率會更高。推薦結(jié)果的解釋性也是我特意做的一個點。推薦列表里的每個崗位都帶了 3 個推薦原因標(biāo)簽比如技能匹配Java、Spring城市匹配上海崗位類別匹配后端開發(fā)。前端把這些原因展示出來用戶能理解為什么給我推這個信任感提升非常明顯。4.4 離線計算 結(jié)果緩存的更新節(jié)奏推薦計算不要求實時用戶畫像的更新頻率是每天一次。每天凌晨 Spark 任務(wù)會將前一天的用戶行為數(shù)據(jù)合并進(jìn)畫像表重新計算所有活躍用戶的推薦列表結(jié)果寫入ads_job_recommend_result表。后端接口讀這個表時加了一層 Redis 緩存緩存有效期 6 小時有效避免了大屏和接口頻繁查詢 Hive 表帶來的延遲問題。這套離線方案的延遲在于——用戶當(dāng)天新增的行為要第二天才能體現(xiàn)在推薦里。但我實測下來對招聘場景來說這個延遲完全可以接受因為用戶的求職意向通常是相對穩(wěn)定的不太會出現(xiàn)上午看了前端職位下午就必須給我推前端這種強(qiáng)實時需求。真要做實時推薦技術(shù)棧就要引入 Flink 和在線向量檢索復(fù)雜度和成本都會大幅上升現(xiàn)階段性價比不高。5. 可視化大屏數(shù)據(jù)分析的最后一公里大屏是這個項目最容易出效果、也最容易做得華而不實的地方。很多團(tuán)隊喜歡把大屏做成數(shù)據(jù)炫技墻——動態(tài)流光、3D 地球、異常酷炫的轉(zhuǎn)場但數(shù)據(jù)本身經(jīng)不起推敲。我在設(shè)計時定了兩條原則第一大屏上的每個數(shù)字和圖表都必須指向一個明確的業(yè)務(wù)動作第二如果大屏上的信息無法支撐會議決策那就是純裝飾。最終的大屏采用 1920×1080 分辨率的布局以地圖、柱狀圖、折線圖、詞云、雷達(dá)圖為主要圖表類型。后端用 Spring Boot 提供 HTTP 接口數(shù)據(jù)從 DWS/ADS 層讀取并聚合后以 JSON 格式返回。前端用 Vue ECharts 渲染每 30 秒自動輪詢一次接口保證大屏上的數(shù)據(jù)能反映最新計算結(jié)果。5.1 大屏整體布局與數(shù)據(jù)接口設(shè)計大屏的布局我先列了一個核心指標(biāo)區(qū)——總崗位數(shù)、今日新增崗位、平均薪資中位數(shù)、高薪崗位占比、熱門技能 Top5、崗位供需比這些是管理者最關(guān)心的指標(biāo)。中間區(qū)域放一張城市薪資地圖用熱力色階展示不同城市的平均薪資水平右側(cè)區(qū)域放崗位類別分布餅圖和技能詞云底部區(qū)域放近 30 天薪資走勢折線圖和學(xué)歷要求分布柱狀圖。數(shù)據(jù)接口設(shè)計有一個經(jīng)驗可以分享大屏接口的返回體量一定要小。很多前端開發(fā)習(xí)慣讓后端直接返回全量明細(xì)數(shù)據(jù)然后在前端做聚合但大屏數(shù)據(jù)源在數(shù)倉里全量明細(xì)可能有幾十萬行前端渲染直接卡死。我的做法是后端接口只返回聚合好的 JSON一個接口對應(yīng)一個圖表數(shù)據(jù)量控制在幾十條到幾百條之間。前端拿到數(shù)據(jù)直接映射到 ECharts 的 series性能非常穩(wěn)定。5.2 核心圖表與業(yè)務(wù)含義的對應(yīng)關(guān)系每個圖表我都做了明確的業(yè)務(wù)定義城市薪資地圖用于回答去哪些城市薪資更有競爭力。地圖上采用中位數(shù)薪資而非平均薪資因為高薪崗位集中在一線城市平均薪資會讓新一線城市看起來毫無吸引力。崗位類別分布餅圖用于回答哪些崗位需求量最大。這里我看的是崗位存量占比而不是投遞量占比因為投遞量受品牌聲量和曝光影響太大不能真實反映市場需求。技能詞云用于回答哪些技能是當(dāng)前市場的硬通貨。詞頻來自清庫后 DWD 層表里skills字段的 explode 結(jié)果再用 TF 權(quán)重做歸一化。詞云字體大小對應(yīng)詞頻排名。學(xué)歷要求分布柱狀圖按崗位數(shù)量統(tǒng)計各學(xué)歷檔位占比并配合本科及以上比例這一行指標(biāo)直觀反映學(xué)歷門檻變化。薪資走勢折線圖按日期展示全崗位中位數(shù)薪資的 30 天趨勢用于揭示短期供需波動。這些圖表搭配在一起基本覆蓋了看行情—挑城市—選崗位—估薪資的決策路徑。5.3 展示口徑大屏到底給誰看大屏的觀眾通常有兩類一類是公司管理層他們要的是宏觀趨勢和對策建議另一類是 HR 運(yùn)營團(tuán)隊他們要的是可操作的數(shù)據(jù)洞察。兩者關(guān)注的點完全不同。管理層看的是城市盤子怎么分布、薪資是否有異常、熱門人才流向哪里運(yùn)營團(tuán)隊看的是哪些技能供給不足、哪些城市需要加大招聘力度、哪些崗位長期掛著招不到人。所以我在大屏上額外放了兩塊運(yùn)營向的內(nèi)容長期掛職崗位 Top10和供不應(yīng)求技能方向。前者直接從崗位發(fā)布時間超過 90 天但狀態(tài)仍為招聘中的崗位中篩出后者通過對比崗位需求量和簡歷供給量得出。這兩塊數(shù)據(jù)能直接轉(zhuǎn)化為運(yùn)營動作是我覺得整個大屏最有實際價值的部分。5.4 大屏性能和刷新機(jī)制上的優(yōu)化細(xì)節(jié)大屏作為 7×24 小時掛在會議室的系統(tǒng)穩(wěn)定性和流暢度比功能豐富更重要。優(yōu)化經(jīng)驗整理為以下幾點圖表銷毀重建ECharts 實例在數(shù)據(jù)刷新時要dispose后再重新init避免內(nèi)存泄漏和疊影。輪詢接口加條件判斷前端每次請求先帶一個lastUpdate參數(shù)后端返回dataVersion如果版本沒變就直接返回 304 或空數(shù)據(jù)減少無效傳輸。靜態(tài)資源 CDN 本地緩存大屏的 JS、CSS 體積不小首屏加載速度直接影響開會體驗務(wù)必做好緩存。數(shù)據(jù)異常兜底接口返回空值時圖表顯示暫無數(shù)據(jù)而不是渲染成空白否則大屏?xí)@得像出了故障。6. 踩坑記錄從數(shù)據(jù)傾斜到預(yù)測偏差任何項目在真實環(huán)境中跑起來都會遇到文檔里沒寫過的問題這套系統(tǒng)也不例外。下面記錄幾個讓我印象最深的坑和處理過程希望對后來者有幫助。6.1 Hive 小文件過多引發(fā)的任務(wù)卡死項目運(yùn)行兩周之后Spark 任務(wù)的執(zhí)行時間從 25 分鐘悄悄漲到了 50 分鐘一度逼近 60 分鐘。查看 Spark UI發(fā)現(xiàn)大部分時間花在了文件讀取階段。定位后發(fā)現(xiàn)每天增量寫入 DWD 層時因為每個渠道產(chǎn)生的文件太小導(dǎo)致 HDFS 上積累了成千上萬個小文件。排查方式是看 Hive 表的文件數(shù)量hdfs dfs -ls /user/hive/warehouse/dwd_job_post_cleaned/dt2024-11-20發(fā)現(xiàn)這個分區(qū)下有幾十個幾十 KB 的小文件。修復(fù)手段有兩個第一是在 Spark 寫入前repartition控制分區(qū)數(shù)第二是對歷史分區(qū)執(zhí)行ALTER TABLE ... CONCATENATE合并小文件。雙管齊下之后任務(wù)時長恢復(fù)到了 25 分鐘左右。6.2 Join 數(shù)據(jù)傾斜導(dǎo)致的 OOM做 DWS 層城市-崗位-技能多維匯總時某一座一線城市的崗位數(shù)據(jù)量遠(yuǎn)大于其他城市Spark 執(zhí)行join時發(fā)生了數(shù)據(jù)傾斜部分 Executor 直接 OOM。我當(dāng)時用兩種方式解決方案一優(yōu)先采用對熱點 Key 加隨機(jī)前綴做兩階段聚合。具體做法是不直接影響結(jié)果——先對熱點城市的數(shù)據(jù)加一個 0-9 的隨機(jī)后綴將一個大 Key 拆成 10 個小 Key 分別聚合再做第二輪合并。方案二如果傾斜規(guī)?？煽馗挠肂roadcast Join把小表廣播到每個 Executor避免 Shuffle。但要求小表數(shù)據(jù)量小于 10MB 左右否則廣播本身就有成本。我最終在熱點城市場景下用了方案一。這種鹽化 兩階段聚合的寫法是處理數(shù)據(jù)傾斜的通用手段值得記錄到自己的常用工具庫里。6.3 薪資預(yù)測低估高薪崗位的問題模型上線后可視化大屏上出現(xiàn)了一個扎眼的現(xiàn)象薪資預(yù)測的最低值和真實數(shù)據(jù)差距不大但高薪崗位的預(yù)測值明顯偏低。100 萬年薪以上的崗位模型大多只預(yù)測出 60-70 萬。原因分析后發(fā)現(xiàn)高薪崗位樣本量非常少。訓(xùn)練集中年薪 80 萬以上的樣本占比只有 0.5% 左右GBT 回歸在擬合過程中為了降低整體損失會主動犧牲那些稀疏的高薪樣本。解決辦法有兩個方向一是對高薪樣本做過采樣把權(quán)重調(diào)高二是使用分位數(shù)回歸或者單獨訓(xùn)練一個高薪崗位子模型。實驗下來過采樣 單獨訓(xùn)練高薪段模型的組合效果最好高薪崗位的 MAE 從 25 萬降到了 12 萬左右。但代價是代碼復(fù)雜度上來了所以我在最終版本中對通用模型和高薪模型做了分檔預(yù)測超過 80 萬年薪的崗位走子模型其余走通用模型。6.4 調(diào)度與數(shù)據(jù)回溯補(bǔ)數(shù)據(jù)比寫代碼更考驗人整個系統(tǒng)依賴 6-7 個定時任務(wù)鏈路是數(shù)據(jù)采集 - ODS - DWD - DWS - ADS - 模型訓(xùn)練 - 推薦結(jié)果 - 大屏刷新。任何一環(huán)失敗下游數(shù)據(jù)就會缺。有一次某個上游數(shù)據(jù)源連續(xù)三天沒有更新導(dǎo)致 DWD 層連續(xù)三天沒有增量數(shù)據(jù)下游任務(wù)全都啞掉了。問題不在任務(wù)失敗而在回溯機(jī)制。數(shù)據(jù)源恢復(fù)之后直接重跑當(dāng)天的任務(wù)只能補(bǔ)齊一天的增量前三天缺的數(shù)據(jù)需要手動補(bǔ)跑。我在調(diào)度平臺上給每個任務(wù)都配了重跑指定日期區(qū)間的能力并且補(bǔ)數(shù)任務(wù)執(zhí)行時會自動檢查目標(biāo)分區(qū)的數(shù)據(jù)是否完整不完整就報錯提示。這樣雖然補(bǔ)數(shù)仍要人工觸發(fā)但至少不會出現(xiàn)看似跑完、實際沒有數(shù)據(jù)的隱性失敗。這個項目跑通半年之后我最大的體會是技術(shù)架構(gòu)的復(fù)雜度可以慢慢提升但數(shù)據(jù)的質(zhì)量和口徑一致性必須從第一天就盯緊。Hadoop、Spark、Hive 提供了穩(wěn)定的底座但真正的價值來自數(shù)據(jù)能不能講出可信的故事——薪資預(yù)測是否貼近市場、推薦結(jié)果能不能幫人找到機(jī)會、大屏上的數(shù)字是否可以支撐決策。如果從頭再來一次我會在第一天就把數(shù)據(jù)規(guī)范和數(shù)據(jù)質(zhì)量監(jiān)控做扎實那才是這個系統(tǒng)持續(xù)運(yùn)轉(zhuǎn)的根基。