乾貨 | 攜程酒店排序推薦廣告高效可靠資料基座--填充引擎

qing_yun發表於2024-02-23

一、背景與思考

1.1 背景

攜程酒店排序推薦廣告工程(以下簡稱酒店推薦工程)在資料層面引入抽象化的統一資料協議UnifiedPB,解決了過去各場景各自維護,建立各自的資料流,網狀開放式資料表,煙囪式迭代的問題,實現了全場景資料的標準化、規範化、統一化。

那麼,UnifiedPB具體是什麼呢?它是基於protobuf構建的統一工程、策略、資料三方的標準資料模型。從資料時效性上,我們抽象出三類:Online、NearLine、Offline;從資料型別歸屬上,我們抽象出四類:User、Item、User-Item、Common(公用字典)。

UnifiedPB資料作為酒店推薦工程最核心的底層資料基座,是整個推薦工程的資料入口,無論是線上Serving(召回→ 粗排 → 精排 → 重排),還是離線調研(特徵調研 → 小流量 → 全流量),全鏈路多模組都強依賴UnifiedPB資料,因此UnifiedPB資料填充的上線質量和效率顯得尤為重要,將直接影響到系統推薦質量和策略收益效果。

1.2 存在問題

基於上述現狀背景,雖然我們引入UnifiedPB統一資料協議解決了網狀開放式迭代問題,但是UnifiedPB資料填充在開發效率和成本等方面還存在如下一些問題亟需解決:

迭代效率低:case by case按需、人工hardCode開發、專人運維模式,交付週期長,效率低。例如60個特徵從需求提出,到開發測試,最終上線預估需要8天。

複用效率低:三端、跨場景之間無法快速直接複用。一個版本特徵在某個小流量場景實現顯著後,期望能夠在其他場景快速複用生效,需要重新進行重複開發工作,效率低。

邏輯耦合不透明:策略邏輯與資料工程強耦合,且不透明化,排查問題需要人工扒程式碼,排查效率低。

成本不可控:資料版本生命週期缺乏有效的管理監測機制,各模組各階段(小流量/全流量)所依賴的資料版本是由人肉進行控制。隨著特徵資料的快速迭代,勢必會造成資料冗餘儲存,快速擴張,造成資源浪費。

三端不統一:酒店排序推薦廣告一直存在著三端(國內/海外/IBU)不統一的問題,三端各自進行迭代,架構邏輯不統一,資料不統一是其中最底層最重要的一部分,需求無法快速三端同時上線。

二、解決方案

針對上述面臨的效率和成本問題,我們以技術驅動主動進行工程端的重大技術升級創新。基於serverless理念,設計並落地了填充引擎框架,實現了邏輯與資源的隔離解耦,策略只需關注邏輯,工程負責框架。框架核心架構bin+data+conf,構建出標準化、低碼化、配置化、可度量的資料填充引擎,實現一站式、自動化資料填充。同時,對全場景資料進行統一收口,對資料建立到銷燬下線的全生命週期管理監控機制,杜絕冗餘儲存,有效控制資源成本,實現資源利用率最大化。

2.1 實現方案

基於邏輯與資源隔離的核心思想,設計出如下圖的實現方案,總體分為兩塊策略邏輯和工程框架。其中,策略邏輯主要是進行邏輯開發,演算法同學只需要關注邏輯實現,可用最擅長的、學習成本最低的SQL實現,並透過統一的web頁面進行管理和規範。

工程框架主要由工程負責開發,重點關注框架的功能性,流程規範制定和效能保障。兩者之間透過配置進行解耦並關聯,最終以配置驅動,實現需求上線。透過框架實現標準化、配置化、自動化實現UnifiedPB資料一站式填充,最終輸出給推薦引擎(排序推薦廣告三端全場景)。

2.2 框架架構

框架整體架構包含Bin + Conf + Data三個模組,Data模組即特徵資料生產模組,生產邏輯由需求方策略同學開發;Conf模組配置中心,是連線填充模組和資料之間的橋樑,使用公司內部框架qconfig進行配置檔案儲存。由於配置檔案內容直接影響UnifiedPB資料填充結果,因此檔案的生成只能透過web頁面按照規範自動生成,嚴格禁止進行人工直接修改。

Bin模組是框架核心模組,主要包含CodeGen、DataLoad、Transform、ConfListen等模組。為了提高框架整體效能,採用位元組碼+反射方式,在應用初始化階段進行配置檔案的解析,生成相應的動態類,實現對用PB節點的資料填充;資料載入模組即將策略生產的特徵資料實時載入,給填充模組進行填充;當需要對源資料欄位級別的資料進行二次處理,即可以使用transform模組,支援以外掛形式進行擴充套件,使用者自定義實現相關功能。配置更新模組會實時監聽配置檔案變化,當需要新增修改特徵資料時,配置更新模組將實時獲取到實時結果,非同步進行動態類構建。基於上述幾個核心模組整體聯動協調,實現UnifiedPB資料一站式、自動化填充。

2.3 質量保障

透過配置驅動,自動化實現需求上線,大家會擔心覺得不夠可靠。那麼我們是如何保證需求上線質量的呢?我們有一套完整的流程去保證這件事情的穩定性和可靠性,實現每次變更都可灰度、可回滾、可觀測。

質量保障覆蓋釋出前、中、後三個階段,釋出前主要是自動化測試,包含一套標準全面的測試元件Pipeline(TestCase/BDA/PFT),確保每次釋出變更的穩定性和可靠性。規則校驗:主要是對資料質量進行一些基本規則校驗,比如總量、值範圍等;TestCase:即單例測試,主要對本地新增的特徵進行單例測試,確保新增特徵的準確性;BDA:批次相容性測試,確保新增資料,不影響老資料;PFT:效能測試,確保每次新增特徵,對效能影響符合預期可控範圍之內。

釋出中、後主要以監控為主,包括整體服務效能監控和資料級別監控,同時有一鍵回滾機制。

2.4 視覺化平臺

平臺接入使用方式,與設計理念基本一致,包括三個角色:策略、工程、平臺。策略負責特徵邏輯實現(標準化SQL語句)、工程負責框架升級和釋出校驗流程執行、平臺負責規範約束。下圖給出了策略新增特徵所進行的具體流程。

策略:選擇資料來源 -> 特徵匯入 -> 編寫SQL邏輯 -> 定義主鍵 -> 特徵路徑選擇

工程:稽核新增特徵 -> 灰度釋出 -> 自動化pipline -> 釋出

三、落地成果

3.1 落地場景

該專案已分階段(酒店詞推薦(2023.02)、IBU全場景(2023.04)、海外全場景(2023.05)、國內全場景(2023.09))在酒店排序廣告推薦三端20多個場景落地上線,100%覆蓋酒店排序推薦廣告全場景。後續將積極賦能推廣到其他BU團隊,近期已在準備在攜程公共首頁資訊流團隊接入。

3.2 效率提升

需求迭代上線效率

產品策略日常新增特徵需求,都需要經過特徵資料資料從數倉Adm層->UnifiedPB。以往hardCode開發模式,包括需求溝通、排期、開發、測試、釋出,這樣一個長週期的上線過程(8d/60個特徵)。填充引擎在這一階段實現資料填充的配置化、自動化,產品策略需求上線週期從天/周級別 -> 小時級別。同時資料跨場景之間可以直接快速複用,複用效率也得到了極大提升,整體效率提升90%以上。

特徵資料表切換效率

排序推薦廣告業務不同於其他業務領域,模型的推薦效果對特徵資料的一致性、準確性有較高的要求。當遇到特徵資料上游團隊(前端埋點、數倉等)有資料變更或遷移時,需要重新開發接入新資料,進行線上無diff AB實驗。以上半年前端埋點token資料切換為例,接入token新資料開發測試上線用時近15天,整體效率低,並且會影響上游團隊的進度。為此,填充引擎針對此類需求,實現了線上AB分版本特徵填充的配置化,可快速實現此功能,當天即可上線,已在多場景落地應用。

上圖展示了我們構建的資料度量系統,橫軸代表需求新增特徵數量,縱軸代表從需求提出到開發完成上線所用的時間。可以明顯看出,接入填充引擎前後,需求上線迭代的效率明顯提升。接入填充引擎前,由於開發人員排期、開發測試、新增特徵的數量、開發過程中遇到節假日、開發人員休假等因素,需求上線迭代效率非常低。接入填充引擎後,上線效率明顯提升,並且排期開發、特徵數量的多少等因素對上線效率的影響很小,上線時間基本維持在小時級別,當天即可上線,平均新增一個特徵用時由20+小時降低到2小時,效率提升90%以上。

3.3 三端資料統一

針對酒店排序推薦廣告三端不一致的歷史長期問題,填充引擎實現了資料層面三端的一致性,對三端各業務場景提供統一的資料訪問層,資料透明化,無需關注具體資料內容;產品策略同學透過視覺化配置,即可實現三端資料的快速同時上線,徹底解決三端資料不一致、複用上線效率低的問題。

3.4 成本可控

透過featureLineage構建了一套從資料建立到銷燬下線的全生命週期管理監控機制,進行視覺化管理,全場景(精排)資料統一收口,杜絕冗餘儲存,實現資源利用率最大化,有效控制資源成本。

3.5 邏輯透明

策略邏輯與資料填充的解耦,資料填充邏輯、Source-Target對映關係實現可觀測、透明化,產品策略自助進行邏輯排查,極大提高了問題排查效率。

四、總結與展望

這篇文章介紹了酒店機器學習工程團隊,圍繞效率、成本、效果三個方面,透過技術驅動在酒店排序廣告推薦的實踐和最佳化思路。

經過近一年的摸索建設和實踐,填充引擎已經建立起完善的架構體系、一站式的服務流程,為酒店排序廣告推薦業務的演算法迭代提供了高效可靠支撐。未來,將繼續圍繞上述三方面,在迭代效率、效能最佳化、成本控制等方面持續投入探索和建設。同時,積極賦能其他BU,在更多的業務場景中發揮平臺的價值,助力集團業務蓬勃發展。

作者簡介:yang,攜程資深後端開發工程師,專注推薦系統架構、資料流批一體、系統穩定性、效率提升等領域;kevin,攜程高階研發經理,專注以技術驅動解決推薦系統中產品業務上的共性問題,創新生產模式,重構生產力;莫禿,攜程高階後端開發工程師,負責酒店機器學習平臺的研發工作;

來自 “ 攜程技術 ”, 原文作者:酒店BI;原文連結:https://mp.weixin.qq.com/s/E3TvF4VtwDjiF7B0MAAD8g,如有侵權,請聯絡管理員刪除。

相關文章