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