本文整理自智聯(lián)招聘資深工程師李世明在「智聯(lián)招聘推薦場景應用」的實踐分享

image.png

搜索推薦架構(gòu)

image.png

在講具體的應用場景之前腐晾，我們先看下智聯(lián)招聘搜索和推薦頁面的截圖迂烁。 這是一個簡單的智聯(lián)搜索頁面络凿，登錄到智聯(lián)招聘 App 的用戶都能看到双藕，但是這個頁面背后涉及到的推薦爬坑、召回邏輯以及排序概念滥崩，是本文的重點。

功能矩陣

image.png

從功能上來說鹦牛，從矩陣圖我們可以了解到做搜索和推薦時搞糕，系統(tǒng)分為 Online 和 Offline 兩個部分。

在 Online 部分能岩，主要涉及到實時操作寞宫，例如：搜索某個關(guān)鍵詞、實時展示個人推薦拉鹃。而這些功能性操作需要其他功能支持，比如：熱詞聯(lián)想鲫忍，以及根據(jù)特定的輸入進行實體識別膏燕、意圖理解，或是個人用戶畫像的繪制悟民。再下一步操作便是召回坝辫，利用倒排索引，根據(jù)文本射亏、相似度匹配近忙，以及引入 Nebula Graph 實現(xiàn)圖索引、向量索引智润，都是為了解決召回問題及舍。最后，便是搜索結(jié)果的展示——如何排序窟绷。這里會有個粗排锯玛，比如常見的排序模型 TF/IDF，BM25兼蜈，向量的余弦相似 等召回引擎排序攘残。粗排后面是精排，即：機器學習的排序为狸，常見的有線性模型歼郭、樹型模型、深度模型辐棒。

上述為在線 Online 流程病曾，相對應的還有一套 Offline牍蜂，離線流程。離線部分主要是整個業(yè)務的數(shù)據(jù)加工處理工作知态，把用戶的相關(guān)行為捷兰，例如：數(shù)據(jù)采集、數(shù)據(jù)加工负敏，再把數(shù)據(jù)最終寫到召回引擎贡茅，像是上文提及過的倒排索引的 Solr 和 ES、圖索引的 Nebula Graph 以及向量索引的 Milvus其做，以提供線上的召回能力顶考。

線上架構(gòu)

image.png

當一個用戶點擊了智聯(lián)招聘的搜索按鈕，會發(fā)生什么呢妖泄？如上圖所示驹沿，經(jīng)過一個 API 調(diào)用，再通過 Query DSL 的統(tǒng)一封裝加工蹈胡，再進入三路（之前提過的倒排索引渊季、圖索引和向量索引）召回，機器學習排序罚渐，最終將結(jié)果返回到前端進行展示却汉。

離線架構(gòu)

image.png

如同上面功能矩陣方面介紹的那般，離線部分主要是數(shù)據(jù)的加工處理荷并，將諸如 HBase合砂、關(guān)系型數(shù)據(jù)庫 PostgreSQL、KV 數(shù)據(jù)庫 TiDB 之類的數(shù)據(jù)平臺通過數(shù)據(jù)鏈路進行加工源织，最終寫入到數(shù)據(jù)存儲層翩伪。

整體業(yè)務流程

將在線和離線架構(gòu)進行整合，下圖細化了 API 請求的處理谈息、緩存缘屹、分頁、A/B Test黎茎、用戶畫像囊颅、Query Understanding、多路召回等流程傅瞻。

image.png

平臺架構(gòu)

介紹了線上和離線的功能架構(gòu)踢代，現(xiàn)在來講下智聯(lián)招聘是如何支撐整個功能矩陣的。

image.png

從底層來說嗅骄，智聯(lián)技術(shù)團隊是通過構(gòu)建了這三個平臺來支撐整個功能矩陣的胳挎。

首先最上方就是我們整個的搜索推薦架構(gòu)平臺，分為數(shù)據(jù)處理溺森、聚合層慕爬、機器學習三個模塊窑眯。在數(shù)據(jù)處理模塊，主要用來完成數(shù)據(jù)加工医窿、數(shù)據(jù)同步磅甩、數(shù)據(jù)合并、格式轉(zhuǎn)換等數(shù)據(jù)層事項姥卢；聚合層則處理意圖識別卷要、AB 測試、在線召回独榴、排序模型僧叉；而機器學習模塊，主要用來做特征加工棺榔、特征抽取瓶堕、模型更新之類的事情。

在搜索推薦架構(gòu)平臺下方症歇，便是搜索召回引擎郎笆，由 Solr、Elasticsearch忘晤、Nebula Graph题画、Milvus 組成，分別負責倒排索引德频、圖索引和向量索引。

最下層缩幸，是大數(shù)據(jù)平臺壹置，對接 Pulsar、Flink表谊、HBase钞护、HIVE、Redis爆办、TiDB 等數(shù)據(jù)源难咕。

Nebula Graph 在推薦場景下的應用

智聯(lián)的數(shù)據(jù)規(guī)模

智聯(lián)這邊線上環(huán)境部署了 9 臺高配物理機，機器配置的話 CPU 核數(shù)大概在 64~72距辆，256G 左右的內(nèi)存余佃。每臺機器部署 2 個 storaged 節(jié)點，一共有 18 個 storaged 節(jié)點跨算，查詢 graphd 和元數(shù)據(jù) metad 節(jié)點分別部署了 3-5 個爆土。線上環(huán)境目前有 2 個 namespace，一共 15 個分片诸蚕，三副本模式步势。

而測試環(huán)境氧猬，采用了 K8s 部署，后續(xù)線上的部署也會慢慢變成 K8s 方式坏瘩。

說完部署情況盅抚，再來講下智聯(lián)招聘這塊的使用情況，目前是千萬級別的點和十億級別的邊倔矾。線上運行的話妄均，最高 QPS 是 1,000 以上；耗時 P99 在 50 ms 以下破讨。

下圖為智聯(lián)自研的監(jiān)控系統(tǒng)丛晦，用來看 Prometheus 的監(jiān)控數(shù)據(jù)，查看節(jié)點狀態(tài)提陶、當前查詢的 QPS 和耗時烫沙，還有更詳細的 CPU 內(nèi)存耗損等監(jiān)控指標。

image.png

業(yè)務場景介紹

下面來簡單介紹下業(yè)務場景

推薦場景下的協(xié)同過濾

image.png

推薦場景下有個比較常見的業(yè)務是協(xié)同過濾隙笆，主要用來解決上圖左下角的 4 個業(yè)務：

1. U2U：user1 和 user2 為相似用戶锌蓄；
2. I2I：itemA 和 itemB 為相似物品；
3. U2I2I：基于物品的協(xié)同撑柔，推薦相似物品瘸爽；
4. U2U2I：基于用戶的協(xié)同，推薦相似用戶的偏好物品铅忿；

上面 U2U 是在創(chuàng)建 user to user 的某種關(guān)系剪决，可能是矩陣（向量級別）相似，也可能是行為級別的相似檀训。1. 和 2. 是基本的協(xié)同（相似性）柑潦，把用戶和用戶、物品和物品建立好關(guān)系峻凫，基于這種基本協(xié)同再延伸出更復雜的關(guān)系渗鬼，比如：通過物品的協(xié)同給用戶推薦相似物品，或是根據(jù)用戶的協(xié)同荧琼，推薦相似用戶的偏好物品譬胎。簡單來說，這個場景主要是實現(xiàn)用戶通過某種關(guān)系命锄，可得到相關(guān)物品的相似推薦或者是相似用戶的關(guān)聯(lián)物品推薦堰乔。

下面來分析一波這個場景

協(xié)同過濾的需求分析

image.png

具體來說，招聘領(lǐng)域來說累舷，CV（簡歷）和 JD（職位）之間存在關(guān)聯(lián)關(guān)系浩考，聚焦到上圖的中間部分，CV 和 JD 之間存在用戶行為和矩陣相似關(guān)系被盈，像用戶查看了某個職位析孽、用戶投遞了某個職位搭伤，或者是企業(yè)端的 HR 瀏覽了某個簡歷這些用戶行為，或者是基于某種算法袜瞬，都會給 CV 和 JD 建立起某種關(guān)聯(lián)怜俐。同時，還要創(chuàng)建 CV 和 CV 之間的聯(lián)系邓尤，也就是上文說到的 U2U拍鲤；JD 和 JD 之間的關(guān)系，就是上面的 I2I汞扎。關(guān)聯(lián)創(chuàng)建之后季稳，可以整點有意思的事情——通過用戶 A 查看過 CV1（簡歷）推薦相似的 CV2（簡歷），用戶 B 瀏覽過職位澈魄，也可以根據(jù)職位的相似性景鼠，給他推薦另外的 JD…這里再提下這個需求的“隱藏”重點，就是需要進行屬性過濾痹扇。什么是屬性過濾呢铛漓？系統(tǒng)會根據(jù) CV 的相似度來推薦 CV，這里就要做相關(guān)的屬性匹配了：基于期望城市鲫构、期望薪資浓恶、期望行業(yè)進行屬性過濾。召回的實現(xiàn)一定要考慮上述因素结笨，不能 CV1 的期望城市是北京包晰，你推薦的相似 CV 期望城市卻是廈門。

技術(shù)實現(xiàn)

原先的技術(shù)實現(xiàn)——Redis

image.png

智聯(lián)這邊最開始實現(xiàn)協(xié)同過濾的方式是用 Redis 將關(guān)系通過 kv 方式存儲起來炕吸，方便進行查詢杜窄。顯而易見的是，這樣操作是能帶來一定的好處：

1. 架構(gòu)簡單算途，能快速上線；
2. Redis 使用門檻低蚀腿；
3. 技術(shù)相對成熟嘴瓤；
4. Redis 因為是內(nèi)存數(shù)據(jù)庫的原因，很快莉钙，耗時低廓脆；

但，與此同時磁玉，也帶來一些問題：

屬性過濾實現(xiàn)不了停忿，像上面說到的基于城市、薪資之類的屬性過濾蚊伞，使用 Redis 這套解決方案是實現(xiàn)不了的席赂。舉個例子吮铭，現(xiàn)在要給用戶推 10 個相關(guān)職位，通過離線我們得到了 10 個相關(guān)職位颅停，然后我們創(chuàng)建好了這個關(guān)聯(lián)關(guān)系谓晌，但如果這時候用戶修改了他的求職意向，或者是增加了更多的篩選條件癞揉，就需要在線來實時推薦纸肉，這種場景下是無法滿足的。更不用提上面說到過的復雜的圖關(guān)系喊熟，實際上這種查詢用圖來做的話柏肪，1 跳查詢就能滿足。

再嘗試倒排索引實現(xiàn)——ES 和 Solr

image.png

因為智聯(lián)在倒排索引這塊有一定的積累芥牌，所以后面嘗試了倒排索引的方式烦味。基于 Lucene 角度胳泉，它有一個索引的概念拐叉。可以將關(guān)系保存為子索引 nested扇商，然后過濾這塊的話凤瘦，子索引中存關(guān)系 ID，再通過 JOIN query 實現(xiàn)跨索引 JOIN案铺，這樣屬性就可以通過 JOIN 方式進行過濾蔬芥。這種形式相比較 Redis 實現(xiàn)的話，關(guān)系也能存上了控汉，屬性過濾也能實現(xiàn)笔诵。但實際開發(fā)過程中我們發(fā)現(xiàn)了一些問題：

1. 不能支持大數(shù)據(jù)量存儲，當關(guān)系很大時姑子，相對應的單個倒排會特別大乎婿。對于 Lucene 來說它是標記刪除，先將標記的刪除了再插入新的街佑，每次子索引都要重復該操作谢翎。
2. 關(guān)系較多時 JOIN 性能不好，雖然實現(xiàn)了跨索引 JOIN 查詢沐旨，但是它的性能并不好森逮。
3. 關(guān)系只能全量更新，其實設(shè)計跨索引時磁携，我們設(shè)計的方案是單機跨索引 JOIN褒侧，都在一個分片里進行 JOIN 操作，但這種方案需要每個分片存放全量的 JOIN 索引數(shù)據(jù)。
4. 使用資源較多闷供，如果跨索引涉及到跨服務器的話烟央，性能不會很好，想要調(diào)好性能就比較耗資源这吻。

上圖右側(cè)是一個具體的實現(xiàn)實錄吊档，數(shù)據(jù)格式那邊是關(guān)系的存儲方式，再通過 JOIN JD 的數(shù)據(jù)進行屬性過濾唾糯，這個方案最終雖然實現(xiàn)了功能但是沒在線上運行怠硼。

圖索引——Nebula Graph

image.png

經(jīng)過我們調(diào)研，業(yè)界對 Nebula Graph 評價挺高移怯，智聯(lián)這邊用了 Nebula Graph 來實現(xiàn)圖索引香璃。像剛在 U2U 和 U2I 的場景，通過圖的方式把 CV 和 JD 存儲成點舟误，邊則存儲關(guān)系葡秒。至于屬性過濾，如上圖所示將 JD 諸如所在城市嵌溢、學歷要求眯牧、薪資要求、經(jīng)驗要求等屬性存儲為點的屬性赖草；而相關(guān)性的話学少，則在關(guān)系邊上存了一個“分”，最終通過分進行相關(guān)性排序秧骑。

新技術(shù)方案唯一的缺點便是新領(lǐng)域的學習成本版确，不過在熟悉圖數(shù)據(jù)庫之后就方便很多了。

基于 Nebula Graph 的推薦

image.png

具體的 CV 推 CV乎折、CV 推 JD绒疗、JD 推 JD、JD 推 CV 場景骂澄，都能滿足吓蘑，像下面這條語句：

match (cv:CV_TAG)-[p]-(jd:JD_TAG) 

    where id(cv)==1 AND p.SALARY>2000

return jd.ID, jd.TITLE, p.score

ORDER BY p.score DESC 

SKIP 0 LIMIT 1000;

便是一個 CV 推 JD 的具體 nGQL 語句：通過簡歷（CV）開始進行查詢，經(jīng)過一些屬性過濾條件坟冲，比如：薪資士修，根據(jù)邊上的相似分進行 ORDER BY 排序，最終返回一個推薦 JD 信息樱衷。

整個業(yè)務這塊，因為關(guān)系相對簡單酒唉，所以這里一共涉及了 5 種 Tag 和 20+ 種邊關(guān)系矩桂，以及創(chuàng)建 100 多種索引，整個數(shù)據(jù)量在千萬級點和十億級別的邊。

Nebula Graph 使用過程中問題總結(jié)

數(shù)據(jù)寫入

image.png

數(shù)據(jù)寫入這里主要分為了 3 個方面：

首先 T+1 數(shù)據(jù)刷新侄榴。展開來說雹锣，因為數(shù)據(jù)是提前加工的，要給在線業(yè)務使用的話癞蚕，涉及了 T+1 數(shù)據(jù)刷新問題蕊爵。刷數(shù)據(jù)的話，一開始可能是個冷數(shù)據(jù)桦山，或者是沒有數(shù)據(jù)攒射，刷新的時候是直接寫入關(guān)系數(shù)據(jù)，這個邊數(shù)據(jù)可能連起始點都沒有恒水。整個邊數(shù)據(jù)刷新之后会放，就需要將不存在的點插入。所以這里有個改進點钉凌，我們先插入點數(shù)據(jù)之后再寫入邊數(shù)據(jù)咧最，這樣關(guān)系能更好地創(chuàng)建起來。數(shù)據(jù)刷新這塊還有個問題御雕，就是邊數(shù)據(jù)是 T+1 跑出來的矢沿，所以前一天的數(shù)據(jù)已經(jīng)失效了，這里就需要把已經(jīng)存在的關(guān)系刪掉酸纲，再將新的關(guān)系寫入捣鲸。

再來講下數(shù)據(jù)格式轉(zhuǎn)換，之前我們使用了倒排索引或者是 KV 來存儲關(guān)系福青，在數(shù)據(jù)結(jié)構(gòu)這塊摄狱，圖結(jié)構(gòu)同之前略有不同。像剛才提到的關(guān)系无午，兩個點之間需要創(chuàng)建什么關(guān)系邊媒役，邊上存儲何種數(shù)據(jù)，都是需要重新設(shè)定的宪迟。智聯(lián)這邊當時開發(fā)了個內(nèi)部工具酣衷，用來自定義 Schema，可以方便地將數(shù)據(jù)存儲為點次泽，部分數(shù)據(jù)存儲為邊穿仪，可以靈活操作配置。即便有別的業(yè)務接入意荤，有了這個小工具也無需通過 Coding 方式來解決 Schema 設(shè)定啊片。

最后一個問題是數(shù)據(jù)持續(xù)增加帶來的數(shù)據(jù)失效。像常見的累積線上活躍用戶玖像，經(jīng)過一段時間紫谷，像是三個月之前的活躍用戶現(xiàn)在可能是個沉寂用戶了，但按照累積機制的話，活躍用戶的數(shù)據(jù)是會一直增加的笤昨，這無疑會給服務器帶來數(shù)據(jù)壓力祖驱。因此，我們給具有時效性的特性增加 TTL 屬性瞒窒，定期刪除已經(jīng)失效的活躍用戶捺僻。

數(shù)據(jù)查詢

image.png

數(shù)據(jù)查詢這塊主要也是有 3 個方面的問題：

1. 屬性多值問題
2. Java 客戶端 Session 問題
3. 語法更新問題

具體來說，Nebula 本身不支持屬性多值崇裁，我們想到給點連接多條邊匕坯，但是這樣操作的話，會帶來額外的一跳查詢的成本寇壳。但醒颖，我們想了另外個易操作的方法來實現(xiàn)屬性多值問題，舉個例子壳炎，我們現(xiàn)在要存儲 3 個城市泞歉，其中城市 A 的 ID 是城市 B 的 ID 前綴，這里如果用簡單的文本存儲匿辩，會存在檢索結(jié)果不精準問題腰耙。像上面查詢 5 時便會把 530 這個城市也查詢出來，于是我們寫入數(shù)據(jù)時铲球，給數(shù)據(jù)前后加入了標識符挺庞，這樣進行前綴匹配時不會誤返回其他數(shù)據(jù)。

第二個是 Session 管理問題稼病，智聯(lián)這邊在一個集群中創(chuàng)建了多個 Space选侨，一般來說多 Space 的話是需要切換 Space 再進行查詢的。但是這樣會存在性能損耗然走，于是智聯(lián)這邊實現(xiàn)了 Session 共享功能援制。每個 Session 維護一個 Space 的連接，相同的 Session 池是不需要切 Space 的芍瑞。

最后一個是語法更新問題晨仑，因為我們是從 v2.0.1 開始使用的 Nebula Graph，后來升級到了 v2.6拆檬，經(jīng)歷了語法迭代——從最開始的 GO FROM 切換到了 MATCH洪己。本身來說，寫業(yè)務的同學并不關(guān)心底層使用了何種查詢語法竟贯。于是答捕，這里智聯(lián)實現(xiàn)了一個 DSL，在查詢語言上層抽象一層進行語法轉(zhuǎn)換屑那，將業(yè)務的語法轉(zhuǎn)換成對應的 nGQL 查詢語法拱镐。加入 DSL 的好處還在于場景的查詢語句不再拘泥于單一的語法晌缘，如果用 MATCH 實現(xiàn)效果好就用 MATCH，用 GO 實現(xiàn)好就采用 GO痢站。

統(tǒng)一 DSL 的實現(xiàn)

image.png

上圖便是統(tǒng)一 DSL 的大概想法，首先從一個點（CV）出發(fā)（上圖上方藍色塊）选酗，去 join 某條邊（上圖中間藍色塊）阵难，再落到某個點上（上圖下方藍色塊），最終通過 select 來輸出字段芒填，以及 sort 來進行排序呜叫，以及 limit 分頁。

實現(xiàn)來說殿衰，圖索引這塊主要用到 match朱庆、range 和 join 函數(shù)。match 用來進行相等匹配闷祥，range 是用來進行區(qū)間查詢娱颊，比如說時間區(qū)間或者是數(shù)值范圍。而 join 主要實現(xiàn)一個點如何關(guān)聯(lián)另外一個點凯砍。除了這 3 個基本函數(shù)之外箱硕，還搭配了布爾運算。

通過上面這種方式悟衩，我們統(tǒng)一了 DSL剧罩，無論是 Nebula 還是 Solr、還是 Milvus 都可以統(tǒng)一成一套用法座泳，一個 DSL 便能調(diào)用不同的索引惠昔。

智聯(lián) Nebula Graph 的后續(xù)規(guī)劃

更有意思更復雜的場景

image.png

上面講的業(yè)務實現(xiàn)是基于離線加工的數(shù)據(jù)，后面智聯(lián)這邊將處理在線實時關(guān)系挑势。像上圖所示镇防，對于一個用戶和一個職位而言，二者存在的關(guān)系可以很復雜薛耻。比如它們都同某個公司有關(guān)系营罢，或者是職位所屬的公司是某個用戶之前任職過的，用戶更傾向于求職某一個領(lǐng)域或者行業(yè)饼齿，職位要求用戶熟練掌握某種技能等等饲漾，這些構(gòu)建成一個復雜的關(guān)系網(wǎng)絡(luò)。

image.png

而智聯(lián)的下一步嘗試便是構(gòu)建起這種復雜的關(guān)系網(wǎng)絡(luò)缕溉，再做些比較有意思的事情考传。例如，某個用戶在公司 A 就職過证鸥，于是通過這個關(guān)系查詢出他的同事僚楞，再進行相關(guān)性推薦勤晚；或者是用戶同校的上一屆學生 / 下屆學生傾向投遞某個職位或者公司，這種都可以進行相關(guān)推薦泉褐；像用戶投遞的這個職位曾經(jīng)和誰聊過天這種行為數(shù)據(jù)赐写，這個用戶的求職意向要求：薪資水平、城市膜赃、領(lǐng)域行業(yè)等信息挺邀，便可以通過在線的方式進行關(guān)聯(lián)推薦。

更方便的數(shù)據(jù)展示

目前數(shù)據(jù)查詢都是通過特定的查詢語法跳座，但是下一步操作便是讓更多的人低門檻的查詢數(shù)據(jù)端铛。

更高的資源利用率

image.png

目前來說，我們的機器部署資源利用率不高疲眷，現(xiàn)在是一個機器部署兩個服務節(jié)點禾蚕，每臺物理機配置要求較高，這種情況下 CPU狂丝、內(nèi)存使用率不會很高换淆，如果我們將它加入 K8s 中，可以將所有的服務節(jié)點打散美侦，可以更方便地利用資源产舞，一個物理節(jié)點掛了，可以借助 K8s 快速拉起另外一個服務菠剩，這樣容災能力也會有所提升易猫。還有一點是現(xiàn)在我們是多圖空間，采用 K8s 的話具壮，可以將不同 Space 進行隔離准颓，避免圖空間之間的數(shù)據(jù)干擾。

更好用的 Nebula Graph

最后一點是棺妓，進行 Nebula Graph 的版本升級攘已。目前，智聯(lián)用的是 v2.6 版本怜跑，其實社區(qū)發(fā)布的 v3.0 中提到了對 MATCH 進行了性能優(yōu)化样勃，這塊我們后續(xù)將會嘗試進行版本升級。