前言
本文是基于在2019QCon北京大会上所做的《物流车货匹配业务中的搜索排序平台实践》的演讲PPT和前续文章《车货匹配”平台-搜索排序系统的工程设计与思考（1）》做的整理、补充与总结。主要内容分为如下几个部分：
- 核心场景
- 平台架构
- 数据驱动
核心场景
在平台架构之前，首先来看看现在已知的车货匹配平台的核心匹配场景有哪些：
（1）货主在平台上发布货源信息，货运司机在App上过滤、搜索货源，平台返回匹配的货源列表。而在这个大的场景下，又有很多细分策略，如：
1. 基于司机搜索的当前路线及过去一定时间（含近实时）内的司机行为数据（点击、拨打），实时计算其偏好（偏好的货源类型、目的地、车长等，如按目的地、车长、类型聚合统计，计算出权重），平台匹配排序时优先召回并排序符合其偏好的货源列表；
2. 基于司机搜索的当前路线，平台识别出该路线及周边“相似”路线（如按被）下司机与货源间的供需关系（数量上的对比、货源被反馈数）”，将“冷线”（相对供需不平衡 -- 供小于需）货源穿插在列表中，通过“热线”（相对供需不平衡 -- 供大于需）带动“冷线”；
3. 平台识别出整个路线下还有未被反馈的货源，在索引中进行标记。司机搜索时如果有这些货源被召回命中，在粗排时将这些货源进行打分提权，列表排序时排在前面；同时，将过度曝光或反馈的货源修改其排序权重，列表排序时排在后面；
4. 在产品运营侧，需要平台对某类优质货源在曝光排序策略上倾斜（置顶、穿插固定位）；或者对某类司机，这类司机搜索时将某类货源上优先其他司机被搜索曝光；
5. 这些不同的策略，需要在App上有不同的流量入口（即，从司机对产品的视角是不同的搜索场景，如主搜列表、详情页推荐、周边推荐等等），且如果一个策略在召回的货源列表集合不足一页（一页有一定的货源列表Size）时，需要补充其他策略进行货源列表的召回补齐（如，先从司机所在的区召回、不足时上升到市级召回等等）；
（2）平台货源主动推送。策略如：
1. 平台定时扫描城市、区内的货源及城市、区内的司机。首先每个机器节点按被分配管理的地理区域（区域指被地理索引化了的区域，如Uber H3索引），召回这些地理区域内的货源、过滤、排序（排序可以按货源被拨打概率等模型打分，或者按指定规则，如货源类别等产品运营规则）、截断（新、老货源分界），然后再召回这些货源所在地理区域及周边的司机、进行过滤、排序，将货源推送给这些司机。
2. 上述策略中在未来不断演化中可能还有其他一些细节：
- 产品形态的不同，决定策略实现与应用上的不同。如派单亦或听单。比如派单，则一个货源派送给一个司机，那么平台需要控制这个货源的唯一可见性只对一个司机，司机拒绝后，再派送给下一个司机；若是听单，则货源可以推送给多个司机，并结合听单搜索列表，司机可以回查这些货源；
- 按照第一层地理区域召回出的一组货源列表和一组司机列表后，需要进行货源与司机间的匹配，可分为几个步骤：
A. 对货源的过滤、排序。召回的货源排序时，有可能按货源在线无反馈时长加权，被推送的次数、被推送之后的反馈次数、也可以按产品运营规则加更多权重进行综合排序，使得排在前面的货源具有“优先”性的推送的机会。这里的“优先”可能意味着：
a. 在给司机推送的候选货源集合里，此“优先”货源有机会被重复推送的次数比其他的货源多（比如，其他普通货源推送次数在一定时间内（如20分钟）只能推送1次，“优先”货源则可以推送2次，以增大曝光机会）；
b. “优先”的货源，对应召回司机的地理范围更大、或者匹配更“优质”的司机；
c. 如果有“派单”模式司机，则优先走“派单”模式；
B. 对司机的召回与排序。司机的召回源于“优先”排序好了的货源，货源携带货源出发地（装货地）地理区域信息（可以按此属性将分组）、目的地、被反馈次数、在线时长、被推送次数等，进行司机召回。过程如：
a. 召回 --- 用一个或一组货源（一组的话，符合同一个级别）的出发地召回在货源装货地附近的司机列表（也可以在粗排的同时进行货源车长、车型的匹配）；
b. 特征增强 --- 如：
* 货源所需车长、车型与司机注册车长、车型的匹配。比如，完全一致的评分为100，货源车长在司机车长范围内的权重为80等，依次类推进行打分排序，增强为“司机车辆与货源装载范围匹配度评分”的特征；
* 货源装货地与司机位置间行驶距离的计算，增强为“司机行驶距离”的特征；
* 获取司机实时接单数量及好评度，增强为“司机信誉度”的特征；
c. 综合打分排序 --- 即基于各个特征综合打分，按打分后的值进行排序。打分的方式，可以是基于各个特征值归一化后基于权重的加权求和，也可以是按照学习模型预测的分数；
d. 过滤、截断
平台架构
平台架构的设计思路与目标，主要围绕几点：
（1）统一的针对实现召回、特征增强、过滤、打分、排序等搜索排序核心逻辑的编程模型和框架。车货匹配的业务发展在不断的快速变化，那么就需要在研发效率、效能上进行思考。只有统一了车货匹配在“匹配”需求功能实现上的研发方式、架构模块的扩展方式，才能让团队中的老同学、新进同学，在一个统一的层面上进行需求的设计思考与研发，并遵循相对固定的模式，从而提升效能；
（2）在效能的目标上，可以进一步将搜索排序等功能的部署落地平台化，即平台提供统一的搜索上下文协议包（搜索出入对象、工具类等等）、召回/过滤/缓存/合并/打分/排序等基础算子开发包，研发同学基于不同的车货匹配需求场景（如第一部分 --- 核心场景中介绍的），通过编写算子间用于参数传递的校验、逻辑处理等“胶水”业务代码，设计针对不同场景的“查询策略”计划（即，对这些“胶水”代码中的bean 对象和通用算子对象进行逻辑编排；在后台，不同场景的“查询策略”计划是以json配置化存在的，搜索排序平台进行装载、解析、执行），并将这些业务代码按业务场景独立打包成业务项目、部署，隔离了场景间线上服务的稳定性风险；
（3）基于车货匹配的货源信息、车源信息等数据流特点及产品形态、场景，平台架构需要能够适应，并需要围绕服务吞吐量、性能等指标进行加固。
1. 从数据流特点上，货源信息时效性短（相比电商的商品）、路线及地理区域上货源量和搜索量不均；
2. 产品形态有列表搜索、推荐、平台推送；
因此，在货源和司机索引这块的核心设计上，需要考虑：
- 设计多个货源索引集群以分摊召回压力及货源搜索场景的灾备恢复；
- 索引的存储形式按请求场景、吞吐量需求，分k-v 存储和ES 倒排存储。如，对于基于地理位置的带有简单过滤条件的召回，使用k-v存储索引设计可以实现较高吞吐量下货源和司机的召回；
平台设计要点
这里仅对于部分要点说明，更多内容可以参看PPT :)
首先，需要统一领域模型。针对不同的车货匹配场景，其核心不变的是一组针对Item的召回、打分、排序等等逻辑实现的过程，和控制数据流入流出的搜索上下文和Item 列表结果。平台通过提供基础类和工具包、“查询策略计划”编排和解析框架，研发同学基于具体业务需求实现召回、排序等扩展代码的开发。
例如，在列表搜索场景，有多楼层的召回需求（即一次召回不足一页，则需要补充召回Item）。研发同学只需要围绕新的召回策略逻辑，比如按“相似路线”召回 --- 在召回算子PreChecker里，组装召回参数，即编写调用特征平台服务接口，通过当前搜索路线取得其相似路线，并做“查询改写”的功能实现；然后，在“查询策略计划”中，将此PreChecker和框架中提供的召回算子进行配置编排。
数据驱动
最后一点聊聊‘数据驱动’，这个话题比较大，暂且也只是自己一点点体系上的思考:)
围绕产品价值，是让用户满意。在匹配侧，货主发布的货源在平台上，通过匹配功能控制货源列表的曝光及push通道更快的匹配到靠谱司机；司机在平台找货，平台能帮助司机找到更符合其自身需求的货。因此，
（1）在平台架构上，需要提供比较稳固的工程能力。在研发效能（如，平台沉淀出模块化的搜索排序开发组件、AB测试、底层索引存储集群及基础数据服务能力，且匹配平台能够将底层复杂访问需求在实际的搜索排序场景中，通过平台“算子”暴露出去，这样新场景的搜索排序就可以快速迭代上线）、平台性能（适当的场景和workload，采用不同的索引存储）、吞吐量、稳定性等层面进行保障。
（2）需要有对业务的匹配效果进行数据分析的反馈闭环。首先，有指标体系和对应数据模型的设计建模，可以查看到匹配的效率。如以司机/货主行为为数据模型，收集和计算不同司机/货主人群，在不同地域，不同时间段，访问App业务应用场景时，查看到的货源曝光数量、点击拨打的货源数量及对应的货源状态（反馈次数）；在实时/离线获取这些数据后，就可以继续聚合统计计算查看到哪些地域的货源曝光量、反馈量高或低，地域内正在寻货的司机量、潜在寻货的和周边的司机量（当然有时间线这一个重要口径）多或者少；之后，基于这些数据，就可以做应用和决策了：
1. 运营决策。比如，以天或周粒度来看，如果某个地区的货源司机访问量（pv&uv）、留存、访问时长在成降低的趋势，那么就需要进行数据分析，看看只是区域性的问题，或者是受什么周边政策、天气等影响。同时，可以采取措施，基于某个地区或者特定类型的货主和司机做营销影响，如货主线上/线下回访、基于人群做文案推送吸引用户回来等等（例子可能比较简单，实际决策的过程可能会看更多维度的数据，来做决策）；
2. 产品决策。对于产品的设计，更应该围绕数据来进行。比如，通过数据分析和定时任务（计算模型）跑出来的不活跃的司机或者货主，可以进行线上产品的增强，如将运费价格高、诚信度好、热门路线货主的货源进行线上“定点”推送，以达到促活的目的；同时，监控这些货源的到达率和用户点击转化效果，进而决定是否采取进一步的行动，如定点推送更加符合司机偏好的好货源，使用户形成习惯。同样，对于其他带有某些标签的司机或者货主，如只在某些地区进行跑活的司机，经常拉某类货源和具有某些特点的车长、车型的司机，在推送和列表搜索等场景下，也可以有很多的产品变化，如提示回程货、周边货源等等，一方面增强司机体验，一方面增强货源的及时反馈；
3. 策略演进。要发挥数据的价值，一方面要采集、传输、建模存储，另一方面还要结合算法策略应用数据。比如，一个路线下的所有发布的货源中，随着时间的推移有的货源被反馈了，那么应该给其他新的货源提供更多的曝光机会。那么，就需要一个随时间、货源反馈量、未被反馈的货源量的算法公式当搜索时实时计算该路线下货源在排序中的排序因子的值，从而调整影响货源的曝光量；
最后
一个平台的架构演进是随着业务需求变化不断总结和沉淀的，需要的是对过程中业务研发需求的认知，技术组件应用的不断积累和学习以及那些“书本上讲到”的架构模式的实际操练和落地实践。