攜程搜廣推算法策略開發(fā)平臺

作者：Eagle技術(shù)團(tuán)隊(duì) 2024-08-08 16:17:29

目前Eagle（攜程搜廣推中臺框架）技術(shù)生態(tài)在集團(tuán)多個(gè)業(yè)務(wù)線搜廣推業(yè)務(wù)中發(fā)揮了關(guān)鍵作用。

作者簡介

攜程搜廣推中臺框架（Eagle）技術(shù)團(tuán)隊(duì)。

團(tuán)隊(duì)熱招崗位：AI中臺資深算法工程師

在攜程的搜廣推業(yè)務(wù)中，Eagle技術(shù)生態(tài)扮演著核心角色，不斷地應(yīng)對業(yè)務(wù)擴(kuò)展帶來的新挑戰(zhàn)。本文首先剖析了Eagle算法策略平臺的架構(gòu)創(chuàng)新，包括流程組件化、編排可視化和邏輯算子化，這些設(shè)計(jì)有效提高了開發(fā)效率并確保生產(chǎn)穩(wěn)定性。進(jìn)一步通過推薦信息流業(yè)務(wù)的實(shí)踐案例，展示了策略平臺在性能提升和資源優(yōu)化方面的實(shí)際效益。最后，對平臺的未來發(fā)展進(jìn)行了展望，包括優(yōu)化調(diào)度、增強(qiáng)編排、靈活部署、全鏈路監(jiān)控和提升用戶體驗(yàn)等，以持續(xù)引領(lǐng)技術(shù)創(chuàng)新，滿足業(yè)務(wù)發(fā)展需求。

一、背景

二、算法策略平臺是什么？

三、整體設(shè)計(jì)

3.1 策略編排：簡單，直觀，安全，高效

3.2 OP-Lib：面向運(yùn)行時(shí)的統(tǒng)一代碼庫

3.3 DAG執(zhí)行器：高效的通用策略執(zhí)行引擎

3.4 策略平臺在推薦信息流中的實(shí)踐

3.5 未來規(guī)劃

一、背景

目前Eagle（攜程搜廣推中臺框架）技術(shù)生態(tài)在集團(tuán)多個(gè)業(yè)務(wù)線搜廣推業(yè)務(wù)中發(fā)揮了關(guān)鍵作用。它在模型訓(xùn)練/推理，特征生產(chǎn)/服務(wù)，在線策略服務(wù)、分層實(shí)驗(yàn)以及運(yùn)維監(jiān)控等方面提供了統(tǒng)一且易用的基礎(chǔ)框架，顯著提升了各業(yè)務(wù)團(tuán)隊(duì)在研發(fā)效率和業(yè)務(wù)效果上的表現(xiàn)。

在效率提升方面的核心點(diǎn)包括：首先它改變了傳統(tǒng)的算法和開發(fā)協(xié)作模式，使得算法同學(xué)能夠直接參與到線上召回和重排模塊算法策略代碼的開發(fā)，大幅降低了溝通成本和一致性問題。其次，通過分層實(shí)驗(yàn)平臺實(shí)現(xiàn)了A/B實(shí)驗(yàn)參數(shù)化、配置化高效做實(shí)驗(yàn)。這在一定程度上提升了策略邏輯的透明性和實(shí)驗(yàn)效率。然而，隨著業(yè)務(wù)場景的擴(kuò)展、業(yè)務(wù)需求量和復(fù)雜度的增加，同時(shí)更多的算法和產(chǎn)品同學(xué)參與進(jìn)來，在代碼質(zhì)量、參數(shù)管理以及溝通協(xié)作出現(xiàn)了一些新的問題。這些對工程質(zhì)量、迭代效率和性能帶來了新的挑戰(zhàn)。主要體現(xiàn)在以下幾個(gè)方面：

1）代碼冗余、參數(shù)爆炸：由于各場景在召回和重排階段存在策略邏輯的相似性、導(dǎo)致了大量的代碼復(fù)制現(xiàn)象。這種狀況不僅使得服務(wù)變得過于臃腫，也大幅增加了維護(hù)成本和迭代難度。

2）邏輯黑盒和溝通成本：業(yè)務(wù)邏輯的掌握僅限于開發(fā)者本人，其他人一般都是通過文檔和口述同步邏輯。反之則需要投入大量時(shí)間來理解和掌握現(xiàn)有的代碼邏輯，這無疑增加了團(tuán)隊(duì)的協(xié)作難度和溝通成本。比如，日常的case Debug和策略解釋路徑很長，產(chǎn)品找算法找開發(fā)一層層傳遞，效率和溝通成本問題嚴(yán)重。

3）迭代風(fēng)險(xiǎn)與難度：代碼缺少流程和模塊化設(shè)計(jì)，比如：某一個(gè)召回策略邏輯幾十行甚至幾百行代碼都寫在一個(gè)類里面。這樣當(dāng)需要更改這塊邏輯時(shí)，無疑增加了出錯(cuò)的風(fēng)險(xiǎn)，也使得迭代過程變得更加困難和低效。

4）質(zhì)量和性能問題：算法同學(xué)（包括一部分工程同學(xué)）工程能力層次不齊，算法同學(xué)更多的是關(guān)注策略邏輯的實(shí)現(xiàn)，在代碼設(shè)計(jì)和質(zhì)量沒有太多的優(yōu)化經(jīng)驗(yàn)。導(dǎo)致上線運(yùn)行時(shí)的各種問題逐漸顯現(xiàn)，如：時(shí)空復(fù)雜度、頻繁GC、潛在的代碼漏洞，系統(tǒng)的穩(wěn)定性、資源利用率以及性能瓶頸等問題等。

二、算法策略平臺是什么？

Eagle 算法策略平臺是一個(gè)高度配置化和透明化的算法策略開發(fā)和部署平臺。平臺專為搜索、廣告和推薦系統(tǒng)業(yè)務(wù)領(lǐng)域設(shè)計(jì)，通過實(shí)現(xiàn)搜廣推全流程的配置化和透明化，簡化算法策略的迭代流程，使得算法團(tuán)隊(duì)能夠更加專注于策略的效果優(yōu)化和業(yè)務(wù)目標(biāo)的實(shí)現(xiàn)。平臺提供了視圖和工具，使算法團(tuán)隊(duì)能夠直觀地理解和監(jiān)控流程中的每個(gè)環(huán)節(jié)（數(shù)據(jù)召回、排序邏輯、模型預(yù)測等），同時(shí)集成了自動化測試、實(shí)時(shí)監(jiān)控和告警、分層實(shí)驗(yàn)和問題排查功能，確保了平臺服務(wù)的高穩(wěn)定性和可靠性。

三、整體設(shè)計(jì)

策略開發(fā)平臺為用戶提供一套從算子開發(fā)，任務(wù)編排到策略上線的完整解決方案，實(shí)現(xiàn)了策略上線流程標(biāo)準(zhǔn)化平臺化管理，沉淀策略通用能力。策略開發(fā)人員可以根據(jù)不同的業(yè)務(wù)場景對相應(yīng)的業(yè)務(wù)流程進(jìn)行編排和發(fā)布。相對于傳統(tǒng)的策略開發(fā)上線流程，該方案具有以下優(yōu)勢：

流程組件化：將策略上線流程劃分為三個(gè)階段：算子開發(fā)，策略編排，任務(wù)運(yùn)行；三階段分別封裝為完全解耦的三個(gè)組件，使方案整體具有高擴(kuò)展性和低成本維護(hù)。
編排可視化：策略的編排采用標(biāo)準(zhǔn)的DAG模型，在頁面直觀的展現(xiàn)策略節(jié)點(diǎn)邏輯信息及節(jié)點(diǎn)間的邏輯關(guān)系，實(shí)現(xiàn)了策略邏輯完全透明。
邏輯算子化：框架提供一套統(tǒng)一的OP算子接口，實(shí)現(xiàn)了每個(gè)算子參數(shù)協(xié)議獨(dú)立，功能單一，進(jìn)一步減少策略代碼的冗余度和提升代碼的復(fù)用性。

因此，我們將整個(gè)開發(fā)平臺劃分為三部分：

1）OP-Organization：通過可視化的頁面管理邏輯算子（OP-Lib）代碼庫，策略組件管理，策略邏輯編排（DAG）。執(zhí)行策略標(biāo)準(zhǔn)化上線流程；

2）OP-Lib：實(shí)現(xiàn)統(tǒng)一OP接口的代碼庫。通過接口及注解定義了統(tǒng)一的OP代碼開發(fā)規(guī)范，元數(shù)據(jù)聲明，耗時(shí)及異常實(shí)時(shí)監(jiān)控。大幅提高代碼的開發(fā)效率和復(fù)用性；

3）OP-engine：實(shí)時(shí)監(jiān)聽策略配置（DAG）變更，支持DAG的自動優(yōu)化（節(jié)點(diǎn)合并），動態(tài)裁剪，節(jié)點(diǎn)限流，熔斷，實(shí)時(shí)監(jiān)控，數(shù)據(jù)回流等功能，確保策略高效運(yùn)行；

3.1 策略編排：簡單，直觀，安全，高效

策略邏輯作為支撐線上效果的主要邏輯，需要高效的迭代上線，不斷的驗(yàn)證正向收益，在底層的框架支持上，已有分層實(shí)驗(yàn)平臺和ABtest實(shí)驗(yàn)可以滿足高效的實(shí)驗(yàn)和結(jié)果驗(yàn)證，但在涉及到邏輯執(zhí)行層，沒有統(tǒng)一的管理平臺，以適應(yīng)策略的高頻迭代，為解決上述痛點(diǎn)，設(shè)計(jì)并開發(fā)了策略開發(fā)平臺。在搜廣推場景中，針對不同的調(diào)用階段，將整體流程分為了召回，粗排，精排，重排幾個(gè)階段，下面就以召回階段的視角來介紹策略開發(fā)平臺的特點(diǎn)。

3.1.1 策略編排可視化，所見即所得

召回首先要解決的問題是如何將策略邏輯透明化，需要宏觀視角去呈現(xiàn)線上服務(wù)運(yùn)行的策略鏈路，它們之間的調(diào)用關(guān)系是什么？如何快速地調(diào)整不合理的策略邏輯。

3.1.1.1 應(yīng)用場景可視化

進(jìn)入BU下的策略首頁，即可看見以卡片形式展示出的策略梗概信息(場景，上線狀態(tài)，更新時(shí)間等)，擁有權(quán)限人員可以編輯對應(yīng)卡片。

3.1.1.2 策略組件可視化

進(jìn)入具體策略，可以查看編輯該策略，同時(shí)可以追蹤、回退歷史版本。在當(dāng)前頁面中，為了增加策略邏輯的可讀性，使用自定義組件將邏輯功能相同的策略節(jié)點(diǎn)封裝在一起，使用戶對邏輯策略的認(rèn)識更加直觀。例如下圖中，在召回階段按召回通道將策略封裝成一個(gè)個(gè)并行組件，使用戶直觀了解到該策略下的所有召回通道。

3.1.1.3 策略節(jié)點(diǎn)可視化

組件中的策略節(jié)點(diǎn)是平臺中的最小單元，是由策略O(shè)P算子（OP-Lib代碼庫）和策略參數(shù)組成。通過此頁面不僅可以方便的選擇一個(gè)OP來生成策略節(jié)點(diǎn)，同時(shí)可以以拖拽的方式編排各個(gè)節(jié)點(diǎn)的調(diào)用關(guān)系，通過OP算子上報(bào)了的元數(shù)據(jù)信息，平臺確保節(jié)點(diǎn)調(diào)用關(guān)系的正確性，保證策略上線的安全。

3.1.2 標(biāo)準(zhǔn)化上線流程，提升上線效率

標(biāo)準(zhǔn)化上線流程在提升上線效率的同時(shí)，保證每次配置發(fā)布都按照規(guī)定的步驟和規(guī)范進(jìn)行，降低人為錯(cuò)誤的風(fēng)險(xiǎn)，并通過驗(yàn)證和測試來提高配置發(fā)布的質(zhì)量和穩(wěn)定性。

3.1.2.1 自動化測試

自動化測試工具將服務(wù)代碼打包成Docker鏡像并部署到k8s容器中。根據(jù)線上服務(wù)的歷史請求數(shù)據(jù)，構(gòu)建請求報(bào)文并發(fā)送到該服務(wù)。獲取到結(jié)果后，對不同配置獲取到的結(jié)果進(jìn)行比較。最終生成的測試結(jié)果將作為策略開發(fā)人員判斷配置變更對服務(wù)性能、功能、穩(wěn)定性的影響的評估依據(jù)。如果測試結(jié)果不符合預(yù)期，策略開發(fā)人員可以及時(shí)調(diào)整配置，確保服務(wù)可以正常運(yùn)行。

3.1.2.2 灰度發(fā)布

策略開發(fā)人員可以將新配置發(fā)布到鏡像集群或者測試集群，在正式上線前盡可能發(fā)現(xiàn)并解決潛在的問題，確保基于新配置的服務(wù)能夠穩(wěn)定運(yùn)行，功能和各項(xiàng)指標(biāo)符合預(yù)期。當(dāng)新配置通過測試和驗(yàn)證，即可發(fā)布到生產(chǎn)環(huán)境。

3.1.2.3 配置回滾

當(dāng)配置發(fā)布到生產(chǎn)環(huán)境后不符合預(yù)期或者出現(xiàn)問題，可以通過回滾功能將配置回退到上一個(gè)穩(wěn)定版本，降低配置對服務(wù)的影響。

3.1.3 先設(shè)計(jì)、再開發(fā)（Design First）

平臺提供了在線編排可視化功能，極大降低了用戶上線策略的學(xué)習(xí)成本，用戶只需對策略O(shè)P進(jìn)行編排，即可完成策略上線。這種開發(fā)模式的轉(zhuǎn)變，要求用戶更多的去思考如何合理編排策略O(shè)P，以及如何設(shè)計(jì)可復(fù)用的策略O(shè)P，避免了老的開發(fā)模式（邊開發(fā)邊設(shè)計(jì)）帶來的需求演變、迭代時(shí)大量修改和補(bǔ)丁的問題。

同時(shí)，策略O(shè)P的動態(tài)組合也帶來了一些問題：1）如何確保組合后的各個(gè)OP能正常調(diào)用，避免出現(xiàn)不合理的調(diào)用關(guān)系甚至參數(shù)類型不兼容，2）編排好的DAG圖在運(yùn)行時(shí)卻找不到掛載的OP實(shí)例。在高并發(fā)流量的首頁信息流場景中，每一個(gè)問題都足以致命，為了解決上線的安全性，這就需要依靠完善的OP元數(shù)據(jù)上報(bào)機(jī)制以及OP代碼庫的版本驗(yàn)證來保證。

3.1.3.1 OP開發(fā)流程和規(guī)范

為了保證用戶在操作策略節(jié)點(diǎn)編排時(shí)的安全性，在設(shè)計(jì)OP時(shí)，首先定義元數(shù)據(jù)信息，包括但不限于：OP類信息，輸入輸出類型和校驗(yàn)邏輯、方法詳細(xì)功能描述等。當(dāng)OP設(shè)計(jì)完成后再是代碼開發(fā)。

3.1.3.2 OP代碼庫版本驗(yàn)證

由于OP代碼庫在線上服務(wù)中為預(yù)加載方式，即線上OP實(shí)例在一個(gè)運(yùn)行周期內(nèi)是完全恒定且單例的，需要在配置平臺在推送策略DAG異步上線時(shí)確保每個(gè)DAG節(jié)點(diǎn)掛載的OP實(shí)例在服務(wù)中是存在的，平臺使用的方案是在推送策略變更前做一次版本驗(yàn)證，保證線上OP版本與配置版本完全一致。

OP代碼版本驗(yàn)證流程圖

i. 用戶編排策略（DAG）時(shí)從OP池選定某一個(gè)OP-Lib代碼版本構(gòu)圖，如選擇最新版V3。

ii. 策略發(fā)布時(shí)進(jìn)入版本驗(yàn)證流程（version check），該流程從在線服務(wù)中拉取當(dāng)前線上OP代碼版本與構(gòu)圖OP版本對比，版本相同時(shí)策略進(jìn)入launch流程推送至配置存儲系統(tǒng)（Config store）。

iii. 在線應(yīng)用實(shí)時(shí)監(jiān)聽，將內(nèi)存中的策略配置（DAG）更新，完成一次策略發(fā)布。

3.1.4 數(shù)據(jù)引擎

平臺集成了數(shù)據(jù)引擎matrix，為在線策略提供線上數(shù)據(jù)訪問能力。matrix負(fù)責(zé)管理數(shù)據(jù)上線流程和提供統(tǒng)一的類sql查詢訪問，對應(yīng)用屏蔽底層存儲，大大降低了策略開發(fā)成本，開發(fā)人員能夠?qū)Ｗ⒂跇I(yè)務(wù)實(shí)現(xiàn)。

3.2 OP-Lib：面向運(yùn)行時(shí)的統(tǒng)一代碼庫

在敏捷開發(fā)模式下，開發(fā)人員更加關(guān)注的是每次迭代需求的快速交付，往往容易忽略新增代碼與現(xiàn)有代碼的統(tǒng)一風(fēng)格規(guī)范，代碼冗余度，整體運(yùn)行效率等問題。容易出現(xiàn)不同功能代碼間的強(qiáng)耦合，編碼相互入侵，上下文運(yùn)行環(huán)境不兼容等一系列問題。這些問題帶來的最直接的后果就是代碼維護(hù)成本不斷提高，線上運(yùn)行效率的不斷下降，同時(shí)大量的補(bǔ)丁代碼也增加了線上BUG出現(xiàn)的概率，因此我們需要提供一套標(biāo)準(zhǔn)的策略算子統(tǒng)一規(guī)范，在滿足業(yè)務(wù)功能的前提下將異常的影響控制在最小的范圍內(nèi)。

3.2.1 OP-API：功能完善的OP接口

為了使策略邏輯代碼和開發(fā)平臺解耦，我們設(shè)計(jì)了一套完整的OP接口規(guī)范，通過這套接口的隔離，用戶只需定義OP的輸入輸出并實(shí)現(xiàn)對應(yīng)的OP接口，而請求上下文信息，參數(shù)驗(yàn)證，異常異常處理都由框架自動處理。

EagleOperations是OP算子的統(tǒng)一接口，作為OP與調(diào)用方的交互規(guī)范，為了增加OP的通用性，OP接口只有一個(gè)exec方法
AbtractEagleOp封裝了對OP算子的通用處理邏輯，包括參數(shù)驗(yàn)證，上下文解析，運(yùn)行時(shí)監(jiān)控埋點(diǎn)以及異常處理。
AbtractNodeOp是OP接口對策略執(zhí)行引擎的擴(kuò)展，主要面向執(zhí)行引擎的DAG節(jié)點(diǎn)實(shí)現(xiàn)，在OP接口的基礎(chǔ)上擴(kuò)展了節(jié)點(diǎn)相關(guān)參數(shù)

3.2.2 OP-Lib：開放的策略O(shè)P代碼庫

OP-Lib是所有策略業(yè)務(wù)實(shí)現(xiàn)的代碼庫，在OP接口的規(guī)范下，策略的實(shí)現(xiàn)可交由各個(gè)業(yè)務(wù)開發(fā)來完成，同時(shí)在發(fā)布代碼時(shí)上報(bào)該策略O(shè)P的元數(shù)據(jù)信息，如邏輯說明，輸入輸出參數(shù)類型等。框架將在服務(wù)啟動時(shí)以預(yù)加載的形式實(shí)例化這些OP算子，并在請求進(jìn)入時(shí)根據(jù)DAG執(zhí)行計(jì)劃統(tǒng)一實(shí)現(xiàn)調(diào)度策略O(shè)P開發(fā)流程遵循：OP設(shè)計(jì)與實(shí)現(xiàn)、單元測試、（框架）集成測試、 Snapshot包、Release包。

3.2.2.1 OP定義與實(shí)現(xiàn)

策略O(shè)P作為DAG的執(zhí)行圖節(jié)點(diǎn)，包含圖節(jié)點(diǎn)基本要素，同時(shí)作為邏輯單元，為提高策略復(fù)用性、策略上線效率，通過配置化驅(qū)動。同時(shí)為避免參數(shù)爆炸、策略實(shí)驗(yàn)等問題，引入“參數(shù)組”概念，OP代碼提供了邏輯模板，配合參數(shù)組完成具體業(yè)務(wù)策略。

i. 元數(shù)據(jù)信息定義

開發(fā)OP前，首先定義OP元數(shù)據(jù)信息，將定義的OP元數(shù)據(jù)信息通過配置文件的形式保存，用于后續(xù)上報(bào)。

ii. 代碼實(shí)現(xiàn)

框架提供了一套完整的OP開發(fā)接口，屏蔽了底層圖執(zhí)行相關(guān)實(shí)現(xiàn)細(xì)節(jié)，同時(shí)提供了異常、超時(shí)等機(jī)制，用戶只需關(guān)心OP的內(nèi)部的邏輯功能實(shí)現(xiàn)。

策略O(shè)P可繼承的OP基類可分為兩類：

1）NodeOp0<I,O,P>

表示接收多個(gè)同類型上游OP的輸出結(jié)果集合作為入?yún)ⅲ嫌蜲P的數(shù)量不限制，并且接受的上游的輸出是無序的。

I：輸入類型，O：輸出類型，P：參數(shù)類型

2）NodeOpN<I1,I2,....,IN,O,P>

表示接收N個(gè)不同類型上游OP的輸出結(jié)果作為入?yún)ⅲ琋在這里是泛指多個(gè)，具體基類包括：NodeOp1，NodeOp2，NodeOp3.......等，實(shí)際執(zhí)行時(shí)上游OP的數(shù)量要同該OP定義的數(shù)量保持一致，且有序。

I1，I2，....，IN：輸入類型，O：輸出類型，P：參數(shù)類型。

基類提供3個(gè)方法：

1）Opout<O> process()：具體的功能邏輯

2）Opout<O> fallback()：失敗回調(diào)方法，用于異常處理，降級處理。當(dāng)上游節(jié)點(diǎn)拋出異常、或者自身邏輯拋出異常時(shí)，會執(zhí)行該方法，方法的返回即節(jié)點(diǎn)的輸出。

3）Function<JsonNode,P> paramFn()：定義策略參數(shù)解析器，用于將策略平臺定義的json參數(shù)結(jié)構(gòu)轉(zhuǎn)化為OP定義的參數(shù)實(shí)體。

3.2.2.2 調(diào)試與監(jiān)控

1）在線debug調(diào)試

為方便用戶在線調(diào)試、排障，我們提供了debug模式，可以在線查看整個(gè)圖中各節(jié)點(diǎn)的輸出的結(jié)果，驗(yàn)證各節(jié)點(diǎn)結(jié)果的正確性，快速定位問題。

在構(gòu)建DAG圖的執(zhí)行請求時(shí)，通過設(shè)置debug參數(shù)為true來開啟debug模式。

同時(shí)考慮到某些節(jié)點(diǎn)的輸出可能是函數(shù)、延遲計(jì)算等不可直接查看的對象，我們提供了SyncOpOutput接口，實(shí)現(xiàn)OP輸出的自定義轉(zhuǎn)換，同時(shí)不影響線上正常輸出。

2）自動化測試

OP上線前，我們要保證對線上現(xiàn)有的策略和性能上無影響，可借助自動化測試完成。

目前平臺已集成自動化測試功能，支持多種測試需求，包括：功能測試、回歸測試、結(jié)果一致性測試、性能測試。上線前需要將測試包/分支上傳至測試平臺，同時(shí)設(shè)置樣本用例、測試規(guī)則等參數(shù)即可開始自動化測試任務(wù)。

3）監(jiān)控埋點(diǎn)

平臺提供了豐富全面的監(jiān)控埋點(diǎn)（流量監(jiān)控，耗時(shí)監(jiān)控，異常監(jiān)控等等），幫助用戶觀測OP在線運(yùn)行情況。

3.2.2.3 部署與注冊

最后需要將包含OP元數(shù)據(jù)信息的配置文件跟隨代碼一起發(fā)布到代碼倉庫，發(fā)布一個(gè)正式的代碼倉庫包，然后在策略平臺的OP管理庫中升級版本，將剛創(chuàng)建的包注冊進(jìn)去，完成OP上線。

3.3 DAG執(zhí)行器：高效的通用策略執(zhí)行引擎

策略的執(zhí)行引擎是一款基于有向無環(huán)圖（DAG）的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的策略節(jié)點(diǎn)調(diào)度框架，為了滿足和覆蓋搜廣推全場景策略的編排，在引擎的設(shè)計(jì)上充分突出靈活易擴(kuò)展的特點(diǎn)，既可以快速應(yīng)用于現(xiàn)有的策略場景中，又可以實(shí)現(xiàn)快速擴(kuò)展附加功能。該執(zhí)行引擎具有如下特點(diǎn)：

標(biāo)準(zhǔn)的DAG規(guī)范：框架接收所有符合DAG規(guī)范的執(zhí)行計(jì)劃。具有高通用性
OP復(fù)用，為了增加OP的復(fù)用性，降低代碼冗余，框架從設(shè)計(jì)上將OP實(shí)例作為單例模式預(yù)加載，并可以掛載到多個(gè)相同功能的節(jié)點(diǎn)上，通過執(zhí)行節(jié)點(diǎn)參數(shù)來執(zhí)行不同的邏輯分支
DAG嵌套：支持在DAG中將節(jié)點(diǎn)配置成另一個(gè)DAG子圖，形成DAG嵌套結(jié)構(gòu)。該功能在復(fù)雜的DAG中可避免節(jié)點(diǎn)平鋪，具有更好的可讀性，同時(shí)隔離資源及異常
動態(tài)圖裁剪：支持根據(jù)請求動態(tài)裁剪DAG的邊對象，滿足節(jié)點(diǎn)維度的ABtest實(shí)驗(yàn)
可擴(kuò)展的圖優(yōu)化器：框架監(jiān)聽到圖配置變更后默認(rèn)啟動責(zé)任鏈模式的圖優(yōu)化器，用戶根據(jù)應(yīng)用場景擴(kuò)展需要的節(jié)點(diǎn)優(yōu)化規(guī)則

OP策略執(zhí)行框架結(jié)構(gòu)設(shè)計(jì)示例圖

OP算子復(fù)用示例圖

3.3.1 應(yīng)對復(fù)雜場景的執(zhí)行引擎多種實(shí)現(xiàn)

由于框架設(shè)計(jì)目標(biāo)是可以執(zhí)行任何標(biāo)準(zhǔn)的DAG圖，為了保證各種簡單或復(fù)雜的DAG能以最高的效率運(yùn)行，我們在執(zhí)行器引擎設(shè)計(jì)上采用了統(tǒng)一接口的多種運(yùn)行策略實(shí)現(xiàn)，并支持動態(tài)切換，目前已實(shí)現(xiàn)了三種執(zhí)行引擎：

3.3.1.1 廣度優(yōu)先串行調(diào)度

在廣度優(yōu)先(BFS)的訪問策略下，執(zhí)行器會以入度為0的頂點(diǎn)作為入口，直接使用請求線程以串行方式依次調(diào)用當(dāng)前層的所有節(jié)點(diǎn)，如果同一層訪問完畢，再調(diào)用下一層，直到所有節(jié)點(diǎn)訪問完畢。該策略在執(zhí)行周期內(nèi)完全使用請求線程，沒有線程切換開銷，占用資源較少。但所有節(jié)點(diǎn)串行執(zhí)行會增加執(zhí)行器整體耗時(shí)，比較適用于對響應(yīng)時(shí)間要求不高或無狀態(tài)的純計(jì)算場景。

3.3.1.2 廣度優(yōu)先并行調(diào)度

此調(diào)度實(shí)現(xiàn)同樣使用BFS的算法訪問節(jié)點(diǎn)，并綁定一個(gè)線程池資源，調(diào)度時(shí)會將同一層的節(jié)點(diǎn)打包提交到線程池并行執(zhí)行，對于并行度較大的DAG，此策略可以有效提升DAG的執(zhí)行效率。

3.3.1.3 全異步響應(yīng)式調(diào)度

雖然并行調(diào)度的方式可以并發(fā)執(zhí)行DAG中平行的節(jié)點(diǎn)，但仍然存在“短板效應(yīng)”,由于提交批次間仍然是串行的，如果某一批次中的節(jié)點(diǎn)N執(zhí)行耗時(shí)較大，則該批次所有節(jié)點(diǎn)都會阻塞等待，盡管下一批次中大部分節(jié)點(diǎn)不依賴節(jié)點(diǎn)N。為解決此短板，我們使用異步阻塞隊(duì)列實(shí)現(xiàn)一個(gè)全異步響應(yīng)式執(zhí)行器，執(zhí)行過程如下：

主線程邏輯：

1）主線程（請求線程）進(jìn)入執(zhí)行器，創(chuàng)建一個(gè)阻塞任務(wù)隊(duì)列Q。并找出DAG的所有根節(jié)點(diǎn)（入度為0的頂點(diǎn)）作為任務(wù)隊(duì)列的初始任務(wù)；

2）主線程進(jìn)入事件隊(duì)列開始調(diào)度：主線程嘗試從任務(wù)隊(duì)列等待可執(zhí)行的節(jié)點(diǎn)，如果獲取到節(jié)點(diǎn)則將節(jié)點(diǎn)提交給異步線程（子線程）執(zhí)行（如果等待超時(shí)，則退出）；

3）如事件隊(duì)列還存有未執(zhí)行事件則重復(fù)2）操作，如當(dāng)前請求所有事件（任務(wù)）全部執(zhí)行完成，則獲取葉子節(jié)點(diǎn)的返回結(jié)果并退出DAG，執(zhí)行后續(xù)的流程。

子線程邏輯：

1）子線程接收到主線程提交的任務(wù)后開始執(zhí)行，并將返回值存入臨時(shí)緩存區(qū)。

2）子線程在完成當(dāng)前節(jié)點(diǎn)任務(wù)后，從DAG中找出當(dāng)前節(jié)點(diǎn)所有可執(zhí)行的下級節(jié)點(diǎn)集合，壓入任務(wù)隊(duì)列，（觸發(fā)主線程步驟2）

3）子線程標(biāo)記后被回收（如是虛擬線程則直接釋放）

異步響應(yīng)式調(diào)度的優(yōu)勢在于，在復(fù)雜DAG下，每個(gè)節(jié)點(diǎn)只要滿足了前置條件（入度全部完成）即可觸發(fā)運(yùn)行，不受同層平行節(jié)點(diǎn)的耗時(shí)干擾，進(jìn)一步提升了執(zhí)行器運(yùn)行效率。同時(shí)該策略下由于每個(gè)節(jié)點(diǎn)都是異步運(yùn)行，在傳統(tǒng)的平臺線程池模式下，高并發(fā)意味著占用更多的線程資源，需要合理設(shè)置線程池規(guī)模和資源降級策略，另外框架支持在java21環(huán)境下將線程池配置為虛擬線程模式，該模式下節(jié)點(diǎn)將使用無池化的虛擬線程異步執(zhí)行，關(guān)于虛擬線程相關(guān)概念可通過JDK官網(wǎng)了解

下圖對比了分層調(diào)用和響應(yīng)式調(diào)用的區(qū)別，可見響應(yīng)式調(diào)用可明顯減少調(diào)用時(shí)間：

3.3.2 執(zhí)行效率提升：可擴(kuò)展的DAG圖優(yōu)化器

在策略開發(fā)平臺的策略編排（DAG構(gòu)圖）完全由用戶自定義，這意味著推送到執(zhí)行引擎中的DAG規(guī)模可能非常大，如果用戶同時(shí)使用的是異步執(zhí)行器，節(jié)點(diǎn)的并行規(guī)模可能會耗盡線程資源，因此，我們引入了一個(gè)異步圖優(yōu)化流程，執(zhí)行引擎監(jiān)聽到DAG圖變更后，會將此圖的節(jié)點(diǎn)按照需要的規(guī)則進(jìn)行合并，最終生成實(shí)際的物理執(zhí)行計(jì)劃；從設(shè)計(jì)上看，優(yōu)化器采用了責(zé)任鏈的開發(fā)模式，除框架預(yù)設(shè)的優(yōu)化器外，用戶可以擴(kuò)展實(shí)現(xiàn)自定義規(guī)則的優(yōu)化器并設(shè)置順序。合理的執(zhí)行順序能有效提高優(yōu)化器的執(zhí)行效率。

圖：基于責(zé)任鏈的圖優(yōu)化器

目前框架預(yù)設(shè)的優(yōu)化器為串行節(jié)點(diǎn)優(yōu)化器，可以將關(guān)系唯一的兩個(gè)相鄰節(jié)點(diǎn)合并為一個(gè)包裝節(jié)點(diǎn)，減少執(zhí)行器的調(diào)度次數(shù)和線程資源。

在實(shí)際案例中證明，用戶的DAG圖越復(fù)雜，默認(rèn)優(yōu)化器的優(yōu)化效率越高：

3.4 策略平臺在推薦信息流中的實(shí)踐

目前整個(gè)推薦策略已完成策略O(shè)P化改造工作，策略O(shè)P涵蓋了召回和重排等多個(gè)階段，已有80多個(gè)推薦信息流業(yè)務(wù)場景接入了策略平臺，涵蓋了多條業(yè)務(wù)線。

3.4.1 策略上線效率提升

以信息流召回階段的策略上線為例，在原有開發(fā)模式下，需要重新定義一個(gè)新的通道，涉及代碼邏輯定制，要經(jīng)歷開發(fā)、測試、發(fā)布的一個(gè)完整上線流程，至少兩天時(shí)間。接入策略平臺之后，完善的策略O(shè)P池基本覆蓋了召回各種需求策略，一個(gè)新通道上線，只需添加配置，測試驗(yàn)收即可，簡單的策略1小時(shí)內(nèi)可以上線，復(fù)雜的策略半天時(shí)間，極大的提升了策略上線效率。

3.4.2 策略邏輯透明

策略邏輯通過DAG圖化展現(xiàn)，根據(jù)每個(gè)節(jié)點(diǎn)所選擇的OP以及定義的參數(shù)組能夠快速了解該節(jié)點(diǎn)內(nèi)部邏輯，策略整體邏輯清晰明了，大大降低了學(xué)習(xí)成本低，溝通成本。

下圖為首頁召回階段平臺視角，可以清楚看到線上生效的策略（SWI，LIVE，PN，LGC，SEA，GPR等），以及各策略使用的召回組件模板，可大致了解通道邏輯，比如SEA使用的是模型召回組件（ModelRecall），通過模型來召回產(chǎn)品；SWI使用的是trigger召回組件（X2I），通過指定條件召回產(chǎn)品。

點(diǎn)擊通道可查看該通道具體的策略邏輯，下圖是PN通道的策略邏輯，可以看出該通道由兩路查詢策略合并組成。

3.4.3 性能提升，資源優(yōu)化

首頁推薦信息流召回服務(wù)接入策略平臺后，服務(wù)性能得到提升，資源利用率得到優(yōu)化。

性能相關(guān)指標(biāo)如下：

整體耗時(shí)提升30%左右，性能得到明顯提升。

資源相關(guān)指標(biāo)如下：

下圖左邊為老版召回應(yīng)用核數(shù)變化，初始核數(shù)為2400，右邊為新版應(yīng)用核數(shù)變化，流量完全切至新版后核數(shù)為900，CPU核數(shù)從2400縮減至900，縮減比例60%。

同時(shí)策略平臺底層框架引入了java21虛擬線程技術(shù)，對于召回這種重IO的業(yè)務(wù)場景，資源得到進(jìn)一步優(yōu)化。下圖為新版召回服務(wù)使用虛擬線程前后資源對比，因虛擬線程切換，CPU核數(shù)從900縮減至600，縮減比例30%，CPU利用率由 20%提高至40% ，提升100%。