作者簡介

yang，攜程資深后端開發(fā)工程師，專注推薦系統(tǒng)架構(gòu)、數(shù)據(jù)流批一體、系統(tǒng)穩(wěn)定性、效率提升等領(lǐng)域；

kevin，攜程高級(jí)研發(fā)經(jīng)理，專注以技術(shù)驅(qū)動(dòng)解決推薦系統(tǒng)中產(chǎn)品業(yè)務(wù)上的共性問題，創(chuàng)新生產(chǎn)模式，重構(gòu)生產(chǎn)力；

莫禿，攜程高級(jí)后端開發(fā)工程師，負(fù)責(zé)酒店機(jī)器學(xué)習(xí)平臺(tái)的研發(fā)工作；

一、背景與思考

1.1 背景

攜程酒店排序推薦廣告工程（以下簡稱酒店推薦工程）在數(shù)據(jù)層面引入抽象化的統(tǒng)一數(shù)據(jù)協(xié)議UnifiedPB，解決了過去各場景各自維護(hù)，建立各自的數(shù)據(jù)流，網(wǎng)狀開放式數(shù)據(jù)表，煙囪式迭代的問題，實(shí)現(xiàn)了全場景數(shù)據(jù)的標(biāo)準(zhǔn)化、規(guī)范化、統(tǒng)一化。

那么，UnifiedPB具體是什么呢？它是基于protobuf構(gòu)建的統(tǒng)一工程、策略、數(shù)據(jù)三方的標(biāo)準(zhǔn)數(shù)據(jù)模型。從數(shù)據(jù)時(shí)效性上，我們抽象出三類：Online、NearLine、Offline；從數(shù)據(jù)類型歸屬上，我們抽象出四類：User、Item、User-Item、Common（公用字典）。        

UnifiedPB數(shù)據(jù)作為酒店推薦工程最核心的底層數(shù)據(jù)基座，是整個(gè)推薦工程的數(shù)據(jù)入口，無論是在線Serving（召回→ 粗排 → 精排 → 重排），還是離線調(diào)研（特征調(diào)研 →  小流量 → 全流量），全鏈路多模塊都強(qiáng)依賴UnifiedPB數(shù)據(jù)，因此UnifiedPB數(shù)據(jù)填充的上線質(zhì)量和效率顯得尤為重要，將直接影響到系統(tǒng)推薦質(zhì)量和策略收益效果。

1.2 存在問題 

基于上述現(xiàn)狀背景，雖然我們引入U(xiǎn)nifiedPB統(tǒng)一數(shù)據(jù)協(xié)議解決了網(wǎng)狀開放式迭代問題，但是UnifiedPB數(shù)據(jù)填充在開發(fā)效率和成本等方面還存在如下一些問題亟需解決：

迭代效率低：case by case按需、人工hardCode開發(fā)、專人運(yùn)維模式，交付周期長，效率低。例如60個(gè)特征從需求提出，到開發(fā)測試，最終上線預(yù)估需要8天。

復(fù)用效率低：三端、跨場景之間無法快速直接復(fù)用。一個(gè)版本特征在某個(gè)小流量場景實(shí)現(xiàn)顯著后，期望能夠在其他場景快速復(fù)用生效，需要重新進(jìn)行重復(fù)開發(fā)工作，效率低。

邏輯耦合不透明：策略邏輯與數(shù)據(jù)工程強(qiáng)耦合，且不透明化，排查問題需要人工扒代碼，排查效率低。

成本不可控：數(shù)據(jù)版本生命周期缺乏有效的管理監(jiān)測機(jī)制，各模塊各階段（小流量/全流量）所依賴的數(shù)據(jù)版本是由人肉進(jìn)行控制。隨著特征數(shù)據(jù)的快速迭代，勢必會(huì)造成數(shù)據(jù)冗余存儲(chǔ)，快速擴(kuò)張，造成資源浪費(fèi)。

三端不統(tǒng)一：酒店排序推薦廣告一直存在著三端（國內(nèi)/海外/IBU）不統(tǒng)一的問題，三端各自進(jìn)行迭代，架構(gòu)邏輯不統(tǒng)一，數(shù)據(jù)不統(tǒng)一是其中最底層最重要的一部分，需求無法快速三端同時(shí)上線。

二、解決方案   

針對(duì)上述面臨的效率和成本問題，我們以技術(shù)驅(qū)動(dòng)主動(dòng)進(jìn)行工程端的重大技術(shù)升級(jí)創(chuàng)新?；趕erverless理念，設(shè)計(jì)并落地了填充引擎框架，實(shí)現(xiàn)了邏輯與資源的隔離解耦，策略只需關(guān)注邏輯，工程負(fù)責(zé)框架?？蚣芎诵募軜?gòu)bin+data+conf，構(gòu)建出標(biāo)準(zhǔn)化、低碼化、配置化、可度量的數(shù)據(jù)填充引擎，實(shí)現(xiàn)一站式、自動(dòng)化數(shù)據(jù)填充。同時(shí)，對(duì)全場景數(shù)據(jù)進(jìn)行統(tǒng)一收口，對(duì)數(shù)據(jù)創(chuàng)建到銷毀下線的全生命周期管理監(jiān)控機(jī)制，杜絕冗余存儲(chǔ)，有效控制資源成本，實(shí)現(xiàn)資源利用率最大化。

2.1 實(shí)現(xiàn)方案       

基于邏輯與資源隔離的核心思想，設(shè)計(jì)出如下圖的實(shí)現(xiàn)方案，總體分為兩塊策略邏輯和工程框架。其中，策略邏輯主要是進(jìn)行邏輯開發(fā)，算法同學(xué)只需要關(guān)注邏輯實(shí)現(xiàn)，可用最擅長的、學(xué)習(xí)成本最低的SQL實(shí)現(xiàn)，并通過統(tǒng)一的web頁面進(jìn)行管理和規(guī)范。

工程框架主要由工程負(fù)責(zé)開發(fā)，重點(diǎn)關(guān)注框架的功能性，流程規(guī)范制定和性能保障。兩者之間通過配置進(jìn)行解耦并關(guān)聯(lián)，最終以配置驅(qū)動(dòng)，實(shí)現(xiàn)需求上線。通過框架實(shí)現(xiàn)標(biāo)準(zhǔn)化、配置化、自動(dòng)化實(shí)現(xiàn)UnifiedPB數(shù)據(jù)一站式填充，最終輸出給推薦引擎（排序推薦廣告三端全場景）。  

2.2 框架架構(gòu)

框架整體架構(gòu)包含Bin + Conf + Data三個(gè)模塊，Data模塊即特征數(shù)據(jù)生產(chǎn)模塊，生產(chǎn)邏輯由需求方策略同學(xué)開發(fā)；Conf模塊配置中心，是連接填充模塊和數(shù)據(jù)之間的橋梁，使用公司內(nèi)部框架qconfig進(jìn)行配置文件存儲(chǔ)。由于配置文件內(nèi)容直接影響UnifiedPB數(shù)據(jù)填充結(jié)果，因此文件的生成只能通過web頁面按照規(guī)范自動(dòng)生成，嚴(yán)格禁止進(jìn)行人工直接修改。

Bin模塊是框架核心模塊，主要包含CodeGen、DataLoad、Transform、ConfListen等模塊。為了提高框架整體性能，采用字節(jié)碼+反射方式，在應(yīng)用初始化階段進(jìn)行配置文件的解析，生成相應(yīng)的動(dòng)態(tài)類，實(shí)現(xiàn)對(duì)用PB節(jié)點(diǎn)的數(shù)據(jù)填充；數(shù)據(jù)加載模塊即將策略生產(chǎn)的特征數(shù)據(jù)實(shí)時(shí)加載，給填充模塊進(jìn)行填充；當(dāng)需要對(duì)源數(shù)據(jù)字段級(jí)別的數(shù)據(jù)進(jìn)行二次處理，即可以使用transform模塊，支持以插件形式進(jìn)行擴(kuò)展，用戶自定義實(shí)現(xiàn)相關(guān)功能。配置更新模塊會(huì)實(shí)時(shí)監(jiān)聽配置文件變化，當(dāng)需要新增修改特征數(shù)據(jù)時(shí)，配置更新模塊將實(shí)時(shí)獲取到實(shí)時(shí)結(jié)果，異步進(jìn)行動(dòng)態(tài)類構(gòu)建?；谏鲜鰩讉€(gè)核心模塊整體聯(lián)動(dòng)協(xié)調(diào)，實(shí)現(xiàn)UnifiedPB數(shù)據(jù)一站式、自動(dòng)化填充。 

2.3 質(zhì)量保障

通過配置驅(qū)動(dòng)，自動(dòng)化實(shí)現(xiàn)需求上線，大家會(huì)擔(dān)心覺得不夠可靠。那么我們是如何保證需求上線質(zhì)量的呢？我們有一套完整的流程去保證這件事情的穩(wěn)定性和可靠性，實(shí)現(xiàn)每次變更都可灰度、可回滾、可觀測。

質(zhì)量保障覆蓋發(fā)布前、中、后三個(gè)階段，發(fā)布前主要是自動(dòng)化測試，包含一套標(biāo)準(zhǔn)全面的測試組件Pipeline（TestCase/BDA/PFT），確保每次發(fā)布變更的穩(wěn)定性和可靠性。規(guī)則校驗(yàn)：主要是對(duì)數(shù)據(jù)質(zhì)量進(jìn)行一些基本規(guī)則校驗(yàn)，比如總量、值范圍等；TestCase：即單例測試，主要對(duì)本地新增的特征進(jìn)行單例測試，確保新增特征的準(zhǔn)確性；BDA：批量兼容性測試，確保新增數(shù)據(jù)，不影響老數(shù)據(jù)；PFT：性能測試，確保每次新增特征，對(duì)性能影響符合預(yù)期可控范圍之內(nèi)。

發(fā)布中、后主要以監(jiān)控為主，包括整體服務(wù)性能監(jiān)控和數(shù)據(jù)級(jí)別監(jiān)控，同時(shí)有一鍵回滾機(jī)制。

2.4 可視化平臺(tái)

平臺(tái)接入使用方式，與設(shè)計(jì)理念基本一致，包括三個(gè)角色：策略、工程、平臺(tái)。策略負(fù)責(zé)特征邏輯實(shí)現(xiàn)（標(biāo)準(zhǔn)化SQL語句）、工程負(fù)責(zé)框架升級(jí)和發(fā)布校驗(yàn)流程執(zhí)行、平臺(tái)負(fù)責(zé)規(guī)范約束。下圖給出了策略新增特征所進(jìn)行的具體流程。

策略：選擇數(shù)據(jù)源  -> 特征導(dǎo)入 -> 編寫SQL邏輯 -> 定義主鍵 -> 特征路徑選擇

工程：審核新增特征 -> 灰度發(fā)布 -> 自動(dòng)化pipline -> 發(fā)布

三、落地成果

3.1 落地場景

該項(xiàng)目已分階段（酒店詞推薦（2023.02）、IBU全場景（2023.04）、海外全場景（2023.05）、國內(nèi)全場景（2023.09））在酒店排序廣告推薦三端20多個(gè)場景落地上線，100%覆蓋酒店排序推薦廣告全場景。后續(xù)將積極賦能推廣到其他BU團(tuán)隊(duì)，近期已在準(zhǔn)備在攜程公共首頁信息流團(tuán)隊(duì)接入。

3.2 效率提升

需求迭代上線效率

產(chǎn)品策略日常新增特征需求，都需要經(jīng)過特征數(shù)據(jù)數(shù)據(jù)從數(shù)倉Adm層->UnifiedPB。以往hardCode開發(fā)模式，包括需求溝通、排期、開發(fā)、測試、發(fā)布，這樣一個(gè)長周期的上線過程（8d/60個(gè)特征）。填充引擎在這一階段實(shí)現(xiàn)數(shù)據(jù)填充的配置化、自動(dòng)化，產(chǎn)品策略需求上線周期從天/周級(jí)別 -> 小時(shí)級(jí)別。同時(shí)數(shù)據(jù)跨場景之間可以直接快速復(fù)用，復(fù)用效率也得到了極大提升，整體效率提升90%以上。

特征數(shù)據(jù)表切換效率

排序推薦廣告業(yè)務(wù)不同于其他業(yè)務(wù)領(lǐng)域，模型的推薦效果對(duì)特征數(shù)據(jù)的一致性、準(zhǔn)確性有較高的要求。當(dāng)遇到特征數(shù)據(jù)上游團(tuán)隊(duì)（前端埋點(diǎn)、數(shù)倉等）有數(shù)據(jù)變更或遷移時(shí)，需要重新開發(fā)接入新數(shù)據(jù)，進(jìn)行線上無diff AB實(shí)驗(yàn)。以上半年前端埋點(diǎn)token數(shù)據(jù)切換為例，接入token新數(shù)據(jù)開發(fā)測試上線用時(shí)近15天，整體效率低，并且會(huì)影響上游團(tuán)隊(duì)的進(jìn)度。為此，填充引擎針對(duì)此類需求，實(shí)現(xiàn)了在線AB分版本特征填充的配置化，可快速實(shí)現(xiàn)此功能，當(dāng)天即可上線，已在多場景落地應(yīng)用。

上圖展示了我們構(gòu)建的數(shù)據(jù)度量系統(tǒng)，橫軸代表需求新增特征數(shù)量，縱軸代表從需求提出到開發(fā)完成上線所用的時(shí)間。可以明顯看出，接入填充引擎前后，需求上線迭代的效率明顯提升。接入填充引擎前，由于開發(fā)人員排期、開發(fā)測試、新增特征的數(shù)量、開發(fā)過程中遇到節(jié)假日、開發(fā)人員休假等因素，需求上線迭代效率非常低。接入填充引擎后，上線效率明顯提升，并且排期開發(fā)、特征數(shù)量的多少等因素對(duì)上線效率的影響很小，上線時(shí)間基本維持在小時(shí)級(jí)別，當(dāng)天即可上線，平均新增一個(gè)特征用時(shí)由20+小時(shí)降低到2小時(shí)，效率提升90%以上。

3.3 三端數(shù)據(jù)統(tǒng)一

針對(duì)酒店排序推薦廣告三端不一致的歷史長期問題，填充引擎實(shí)現(xiàn)了數(shù)據(jù)層面三端的一致性，對(duì)三端各業(yè)務(wù)場景提供統(tǒng)一的數(shù)據(jù)訪問層，數(shù)據(jù)透明化，無需關(guān)注具體數(shù)據(jù)內(nèi)容；產(chǎn)品策略同學(xué)通過可視化配置，即可實(shí)現(xiàn)三端數(shù)據(jù)的快速同時(shí)上線，徹底解決三端數(shù)據(jù)不一致、復(fù)用上線效率低的問題。

3.4 成本可控

通過featureLineage構(gòu)建了一套從數(shù)據(jù)創(chuàng)建到銷毀下線的全生命周期管理監(jiān)控機(jī)制，進(jìn)行可視化管理，全場景（精排）數(shù)據(jù)統(tǒng)一收口，杜絕冗余存儲(chǔ)，實(shí)現(xiàn)資源利用率最大化，有效控制資源成本。

3.5 邏輯透明

策略邏輯與數(shù)據(jù)填充的解耦，數(shù)據(jù)填充邏輯、Source-Target映射關(guān)系實(shí)現(xiàn)可觀測、透明化，產(chǎn)品策略自助進(jìn)行邏輯排查，極大提高了問題排查效率。

四、總結(jié)與展望

這篇文章介紹了酒店機(jī)器學(xué)習(xí)工程團(tuán)隊(duì)，圍繞效率、成本、效果三個(gè)方面，通過技術(shù)驅(qū)動(dòng)在酒店排序廣告推薦的實(shí)踐和優(yōu)化思路。

經(jīng)過近一年的摸索建設(shè)和實(shí)踐，填充引擎已經(jīng)建立起完善的架構(gòu)體系、一站式的服務(wù)流程，為酒店排序廣告推薦業(yè)務(wù)的算法迭代提供了高效可靠支撐。未來，將繼續(xù)圍繞上述三方面，在迭代效率、性能優(yōu)化、成本控制等方面持續(xù)投入探索和建設(shè)。同時(shí)，積極賦能其他BU，在更多的業(yè)務(wù)場景中發(fā)揮平臺(tái)的價(jià)值，助力集團(tuán)業(yè)務(wù)蓬勃發(fā)展。