2019年物流車貨匹配搜索排序平臺實踐.pdf

1、物流車貨匹配業務中的搜索排序平臺實踐滿幫集團車貨匹配團隊負責人目錄物流車貨匹配業務場景簡介 系統研發目標 車貨匹配業務搜索排序平臺系統架構 設計要點 未來展望貨主發布貨源信息，司機主要通過搜索列表來進行找貨，但場景有細分物流車貨匹配業務場景簡介貨源消息有比較高的時效性 列表召回與排序考慮了價值性、公平性物流車貨匹配業務場景簡介時間軸1322TnTn-1Tn-2Tn-3Tn-512321111匹配目標：效率！司機貨主請求時間貨源信息同顏色代表匹配或近似匹配-裝卸貨地-距我附近-車長范圍-車型高價值貨源召回20分鐘無反饋貨源平臺 根據算法自動刷新特定路線和場景下穿插出發地周邊 無反饋貨源不同場景下

2、，工程與算法同學對場景策略并行擴展開發與部署系統研發目標底層召回與排序等服務實現的通用性、擴展性搜索排序策略的實現可以做到部分配置化平臺穩定性及性能圍繞匹配效率的策略優化搜索排序平臺系統架構問題 早期邏輯實現不易擴展 領域模型抽象度不夠設計要點-統一領域模型方法 將各場景模型，統一到一個領域模型，即SearchPlan。支撐如下場景：司機“找”貨 貨“找”司機ScenUserDeviceSearchInputQuery AnalyseRecallMergeRankSortPaginationRecall-1Recall-2SearchPlan ModelEnhanceSearchContext

3、SearchResult+Stage設計要點-統一領域模型調用層創建SearchContext 傳入基本查詢信息設計要點-統一領域模型一個SearchPlan實例 由配置出來的SearchStage組成execType 決定了Operator執行的方式(并行/串行）一個SearchStage實例則由StageExecutor和這個Stage中的Operator組成設計要點-“算子”的通用性與定制化問題 如何能夠快速擴展實現搜索排序場景并不斷迭代？設計要點-“算子”的通用性與定制化例子 多“樓層”召回排序司機進入某場景搜索入口出發地選擇“城市/區”目的地選擇“城市/區”出發地選擇“城市/區”目的

4、地選擇“附近”精確匹配用戶 所選“出發地”“到達地”發布時間距當前5分鐘內發布時間倒序精確匹配用戶 所選“出發地”“到達地”發布時間距當前5分鐘以外發布時間倒序用戶 所選“出發地”為“區”則上升到“市”發布時間距當前5分鐘以外一層按裝貨距離排序；二層距離接近則按發布時間倒序Layer 1Layer 2Layer 3精確匹配用戶 所選“出發地”目的地為用戶附近X發布時間距當前5分鐘內卸貨距離小于20KMLayer 1Layer 2Layer 3按發布時間倒序用戶輸入精確匹配用戶 所選“出發地”目的地為用戶附近X發布時間距當前5分鐘以外卸貨距離N小于20KM按N由小到大排序召回與排序邏輯策略1精確

5、匹配用戶 所選“出發地”目的地為用戶附近X發布時間距當前5分鐘以外卸貨距離N小于20KM按N由小到大排序策略2精確匹配用戶 所選“出發地”目的地為用戶附近X發布時間距當前5分鐘以外運輸距離N小于20KM按N由小到大排序策略3出發地周邊貨源匹配發布時間距當前5分鐘內按發布時間倒序Layer 4穿插在首部前兩個位置（按50%概率展示）并行一路召回A類貨設計要點-“算子”的通用性與定制化方法 查詢分析“算子”按場景定制，拼接入參不同場景下，屬性處理邏輯不一樣按“場景”粒度決定放一個QA還是多個底層召回“算子”調用模板化按場景拆分設計要點-“算子”的通用性與定制化方法 框架層，召回、打分、排序等“算子

6、”的實現通用化?召回”算子“按不同召回場景，取其對應的業務層傳入的召回參數設計要點-“算子”的通用性與定制化方法 業務層，則通過OperatorPreChecker等“膠水”代碼關聯起來在業務層召回“算子”的PreChecker實現 設計要點-“算子”的通用性與定制化方法 按場景將“算子”編排配置成SearchPlanTemplateLayer 1 Layer 2 Layer 3 多“樓層”SearchPlanTemplate 配置 設計要點-“算子”的通用性與定制化方法 SearchPlan在框架層中解析執行SearchContextObject poolXXXSearchPlan Temp

7、lateIntelliPush SearchPlanTemplatIntelliSort SearchPlanTemplat Object poolQueryAnalyzerBaseESRecallOperatorGaosiRankOperator UserProfileEnhance OperatorMultiListItemMerge OperatorCargoDetailRec SearchPlanTemplatDefaultSort SearchPlanTemplatSearchPlatformMgrSearchPlatformDispatcherSearchPlanBuilderSe

8、archPlanExecutorSearchStageExecutorLoadGenerate search planIterate search stageSearchResultPass search inputReturn search result框架核心邏輯組件設計要點-“算子”的通用性與定制化某場景QueryAnalyzer+UserProfileModelW類貨主貨 源召回M類 貨源召回普通 貨源召回多路貨源列表合并基于UserProfileModel Rank并行多路RecallOperatorMergeOperatorUFMSimilarRankOperator裝貨距離計算D

9、istanceComputeEnhanceOperator穿插并按相關度SortInsertAndSortOperator分頁截斷SearchPagingOperator總結：1.查詢計劃可編排“算子”2.易擴展設計要點-查詢計劃執行時的容錯與降級問題 SearchPlan 執行異常需要可降級與兜底 特定場景SearchPlan 執行，可以分開服務部署并做場景降級設計要點-查詢計劃執行時的容錯與降級方法 灰度-在SearchPlanBuilder中通過SearchContext和規則選擇器進行規則動態選擇，按流量比例（可以細分到路線、人群、場景等條件）切到新的SearchPlanTemplat

10、e。規則與SearchPlanTemplate一同配置。SearchContextSearchaPlanTemplate 1 Rule 1 Rule 2 Rule 3Rule if(searchContext.scene.name=defaultSort&searchContext.user.userId%100=10)return true;SearchaPlanTemplate 2SearchaPlanTemplate 3SearchPlanRuleSelectorSearchPlanBuilder設計要點-查詢計劃執行時的容錯與降級方法 拆分-按垂直場景（搜車、搜貨、不同打分模型等），基

11、于流量調用壓力，切分不同服務實例，但引用同一個搜索排序框架App ControllerSP-Core-ServiceSP-CommonRecall-ServiceOther-level-ServiceSP-CommonDispatch設計要點-召回服務業務上升、服務組件化原來 SearchRequestEsCommonDaoES1ES2ES3多個搜索場景參數混合，特定參數只能在單合一場景下使用統一參數解析，封裝查詢DSL。無法及時定位到哪一場景搜索劣化，無法根據場景降級。牽一發而動全身，維護成本巨大。某一改動可能涉及到所有場景出現問題。es集群分流粗糙，無法做到白名單、灰度策略切換。設計要點-

12、召回服務業務上升、服務組件化現在 ES1ES2ES3BaseSearchModelBaseRangeModelBaseGeoPointModelBaseSortModelBaseSourceModelAbstractSearchModel擴展-按照功能封裝基礎搜索模型排序：支持字段，scriptsource：支持字段，script_field提權：可使用搜索模型提權，修改doc評分ElevationFactorpreProcessBuildQuerySortSourceAbstractSearchTemplateChainmatchIndexAndType匹配域和場景。（接入限制，需申請）解析

13、SearchModel組合邏輯，拼裝條件排序、設置source等Es-common匹配域和場景、獲取集群、index、type信息。（接入限制，需申請）根據獲取信號量進行業務限制?？偨Y：1.業務上升、基礎組件沉淀2.構建基礎查詢模型3.查詢鏈路擴展，接入場景限制4.集群統一管理，流量分配5.快速定位問題，非核心業務快速降級，防止雪崩設計要點-匹配策略優化現狀 貨主貨源發布時間與司機尋貨時間不一定匹配司機搜索路線上的貨源量與尋貨司機數量不一定匹配高價值及無反饋貨源需要更快匹配疑似“廣告”及“黃反”需要降權與屏蔽目標設計要點-匹配策略優化方法 粗排分樓層，按“pageRank”值一層排序，再按“u

14、pdateTime”來做第二層排序Item 1Item 2Item 3 Item 30Item 31Item 32 pk:400pk:300Item 3Item 2Item 1 Item 30Item 32Item 31 ut:st1ut:st2第一層排序第二層排序注：1.pageRank 按運營規則配置隨貨源寫入索引2.updateTime 則由貨源發布時間&刷新頻率計算出來設計要點-匹配策略優化方法 將貨源按刷新頻率“分桶”，基于刷新頻率動態計算updateTimeEx.0-20 minEx.0-40 minEx.0-60 minEx.0-90 minallStrategy-實時計算平臺

15、寫入0-20 min0-40 mingroupXStrategy -實驗新算法時使用0-60 mindefaultStrategy-貨源入 索引時寫入的默認刷新值 123司機display:defaultStrategy:expireTime:-1,length:4620000,startPoint:0 ,group0Strategy:expireTime:1556419588627,startPoint:0,length:5400000 ,allStrategy:expireTime:1556419588627,startPoint:0,length:5400000 例子-ES Mapping 中用于計算刷新頻率部分的結構pseudo codes 轉換成ES 中的painless script 設計要點-匹配策略優化方法 對“刷新頻率”值的控制，可以對路線上的貨源曝光實現“劫富濟貧”的效果無反饋貨源“桶”有反饋貨源“桶”貨主發貨司機打電話某X路線下貨源無反饋貨源量W有反饋貨源量M無反饋貨源刷新時間 T無反饋貨源刷新時間 T1公式-(W/T)/(M/T1)=曝光比例未來展望干預配置的工具化，更快更好支撐運營規則類需求策略算法考慮各路線上貨源發布量與司機反饋量的供需平衡指標 對“刷新頻率”控制更加準確 對召回條件的動態更新