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信息。（接入限制，需申请）根据获取信号量进行业务限制。总结：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:27,startPoint:0,length:5400000 ,allStrategy:expireTime:27,startPoint:0,length:5400000 例子-ES Mapping 中用于计算刷新频率部分的结构pseudo codes 转换成ES 中的painless script 设计要点-匹配策略优化方法 对“刷新频率”值的控制，可以对路线上的货源曝光实现“劫富济贫”的效果无反馈货源“桶”有反馈货源“桶”货主发货司机打电话某X路线下货源无反馈货源量W有反馈货源量M无反馈货源刷新时间 T无反馈货源刷新时间 T1公式-(W/T)/(M/T1)=曝光比例未来展望干预配置的工具化，更快更好支撑运营规则类需求策略算法考虑各路线上货源发布量与司机反馈量的供需平衡指标 对“刷新频率”控制更加准确 对召回条件的动态更新