乾貨 | 攜程酒店排序推薦廣告高效可靠資料基座--填充引擎
一、背景與思考
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,如有侵權,請聯絡管理員刪除。
相關文章
- 乾貨 | 攜程酒店實時數倉架構和案例架構
- 乾貨 | 攜程酒店基於血緣後設資料的資料流程最佳化實踐
- 乾貨 | 每天十億級資料更新,秒出查詢結果,ClickHouse在攜程酒店的應用
- 乾貨 | 攜程圖片服務架構架構
- 乾貨 | 資料為王,攜程國際火車票的 ShardingSphere 之路
- 乾貨 | 攜程線上風控系統架構架構
- 乾貨 | 攜程日誌系統治理演進之路
- 乾貨!谷歌推薦的技術能力提升指南谷歌
- 攜程酒店基於血緣後設資料的資料流程最佳化實踐
- 攜程個性化推薦演算法實踐演算法
- 攜程大資料實踐:高併發應用架構及推薦系統案例大資料應用架構
- 【乾貨】Ftrans資料擺渡裝置 建立安全高效數傳通道!
- python酒店相似度推薦系統Python
- 資深Java工程師推薦新手乾貨教材 《Java Web開發實戰》Java工程師Web
- 乾貨 | 廣告系統架構解密架構解密
- 乾貨|個性化推薦系統五大研究熱點之可解釋推薦(五)
- 乾貨 | 攜程一次Redis遷移容器後Slowlog“異常”分析Redis
- Nebula Graph|資訊圖譜在攜程酒店的應用
- Mahout的taste推薦系統引擎(影片推薦案例)AST
- 【乾貨分享】嵌入式學習路線公開!(書籍推薦+視訊推薦+練手專案)
- 推薦系統演算法合集,滿滿都是乾貨(建議收藏)演算法
- 推薦 Go 實戰專案—高效能 kv 資料庫 LotusDBGo資料庫
- 資料庫課程作業筆記 - 編寫資料填充資料庫筆記
- NLP 科研資料推薦
- 攜程高管解讀財報:加大海外酒店網路建設
- 乾貨丨遊戲音訊與聲音設計相關書籍推薦遊戲音訊
- 乾貨:mysql索引的資料結構MySql索引資料結構
- 乾貨 | 影像資料增強實戰
- 【乾貨】Kaggle 資料探勘比賽經驗分享(mark 專業的資料建模過程)
- 大廠技術實現 | 騰訊資訊流推薦排序中的並聯雙塔CTR結構 @推薦與計算廣告系列排序
- Faker資料填充
- Laravel - 資料填充Laravel
- Flutter入門資料推薦Flutter
- 精文推薦,12個開源專案開發必備,絕對乾貨
- 華雲資料攜"信創雲基座"亮相2021資訊科技應用創新論壇
- php 高效率寫法 推薦PHP
- 【推薦系統篇】--推薦系統之測試資料
- AI客服上線 乾貨 乾貨 全是乾貨!AI