从未降级的搜索技术-实时之刃
流量是互联网变现的基石,而流量的资源是有限的,如何实现资源的最大化利用(买家-商品的最高效的匹配)是此次双11搜索技术深度切入的使命,也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。
一. 问题发现
天猫的业务团队同学,通过针对去年双11细致认真的数据分析,发现了去年双11暴露的一些问题。 预热期
- 小部分商品预热过度,预热期吸引的加购量远超出商品库存能支撑的量,大部分用户虽然加了购物车但当天也抢不到,购物车转化率低;而大部分商品预热不足,没有充分曝光;
- 活动期间商品的加购行为和历史行为差别巨大,离线( T-1)天的数据无法真实反映商品的实时受欢迎程度;
双11当天
- 即将售罄的热销商品仍然获得了大量流量,剩余库存无法支撑短时间内的大用户量;主售款(热销 sku)卖完的商品获得了流量,用户无法买到商品热销的 sku,转换率低;
- 和预热期一样,活动期间,商品离线( T-1)天的数据无法真实反映商品的实时的受欢迎程度;
二、问题解决
问题是很明显了,那么如何来解决呢?总体来看,无论是预热期还是双11当天,就是要降低资源(流量)浪费和提升资源(流量)利用率。
降低流量浪费层面,首先来看预热期,就是如何避免一个商品由于过度曝光(pv),使得加购总量所能带来的潜在成交笔数超出其库存,导致大量交消费者 即使加购,当天也无法下单; 那我们就要建立一个合理调控商品展示的机制来实现。我们根据一个商品的长期,实时的加购历史,预测出它在双11当天能够拿到的成交量,当成交笔数超出该商 品的库存承受能力时,降权分将会在商品排序中发挥作用,来减少该商品的曝光机会,通过有效的流量引导来减缓该商品的加购,从而减少无效加购的总量,提高双 11当天购物车的转化率。
接着来看看双11当天,理性和非理性消费者的购物欲望都在这一天得以释放,流量暴增, 如果一个商品即将销售一空却仍然获取大量的曝光和点击,带来的体验必然是很多消费者铩羽而归,同时浪费了宝贵的流量资源。如何来避免呢?同预热期一样,我 们要建立一个合理的商品展示调控机制,我们根据商品的成交记录,预测出商品销售速度,这样根据商品的剩余库存除以销售速度,就能预判出该商品从当前时刻起 还有多少时间就会售罄; 系统可以根据即将售罄的时间长短建立不同粒度的降权分,从而有效的调节即将售罄商品的曝光机会。 除了降权逻辑,我们也需要给那些表现突出的商品给与更多的曝光机会,提升流量转化效率。
接下来我们就从系统技术架构方面来加以阐述;算法方面具体细节不便透露
五角星的部分都是此次实时流量调控的重要核心模块:
PORA:PORA是搜索离线团队针对实时个性化业务场景打造的一套离线实时计算系统。它能实时同步海量用户日志,对每一条日志关联相关数据并驱动 执行相关算法业务模块,产出数据自动更新下游在线服务。整个过程通常在秒级别完成,这样用户实时行为可以在几秒内就对搜索排序等线上服务产生影响。为灵活 支持业务需要,PORA针对不同个性化场景提供了业务层的平台抽象,解决了所有算法不需要关心的工程问题,并通过接口和插件机制集成所有的算法模块。这样 算法只需要遵循接口,专注于实现从输入用户数据到输出下游数据的算法逻辑本身,而无须关注数据同步、提取、存储、查询、更新等复杂的前后工程逻辑,也无须 担心海量实时数据对系统的冲击,从而最大程度降低了算法开发成本。
具体到本次双11实时流量调控需求,PORA需要实时接入预热期和双11当天全网用户的所有点击、加购、成交行为日志,按商品维度累计相关行为数 量,并实时关联查询商品库存信息,提供流量调控算法插件进行实时售罄率和实时转化率的计算分析,并将插件计算出的字段更新实时同步给主搜、商城、店铺内搜 索引擎,天猫推荐平台,流量直播间等下游业务。其中,双11当天的用户访问压力是平常和预热期所难以想象的,业务方对此评估后给出了50w/s的预测峰值 QPS,PORA需要确保在这样的高压力下仍然保持端到端秒级实时更新。
UPS:UPS是搜索技术部门提供个性化服务存储计算的在线系统,承担了包括搜索个性化在内的众多业务线上全量实时KV/KKV数据的低延迟的存 储、查询和计算服务。在本次双11实时流量调控中,UPS在提供用户个性化数据等原有服务的基础上还存储了PORA实时更新的流量调控数据,供下游天猫双 11直播间使用。
Isearch5: ISearch5是搜索最新一代引擎平台,服务于淘宝、天猫、B2B等各个搜索业务线,支持秒级实时索引、辅表等众多新特性。在本次双11实时流量调控 中,PORA产出的实时售罄率和转化率字段正是通过Swift消息实时更新的索引字段。ISearch5引擎中还包含一个战马框架可以支持嵌入算法的排序 模块,算法在对应的流量调控排序模块中可以获取到PORA实时更新至引擎的售罄率和转化率字段值,从而实时影响排序结果,达到调控流量的目的。
SP :SP是搜索面向前端应用的统一服务接口,根据用户指定的查询条件制定查询计划,查询包括QP/UPS,ISearch5引擎在内的各个搜索后端系统,得到最终结果返回个前端。SP通过将业务逻辑从前端往后端下沉,简化了搜索调用逻辑,提升了前端系统性能。
BTS 服务:BTS是搜索的分桶测试管理服务,搜索的一次服务首先从BTS中获得自己所属的测试,BTS确保一个用户的前后多次访问获取到的始终是相同结果,测 试信息作为一个查询条件通过SP传给后端各个系统,后端据此可以进行分桶测试。具体到本次双11的实时流量调控需求,引擎的战马框架中配置的算法排序模块 会根据传入测试信息不同进行不同权重的流量调控排序,从而帮助算法对比和优化模型。
下面从系统层面讲一下这几个环节如何默契的配合来实现实时的流量调控的。 用户无论是通过PC还是无线每次点击/加购/成交一个商品,都会产生一条对应的行为日志,这个行为日志通过集团的日志实时传输系统 TT(TimeTunnel)实时进入PORA系统,PORA取到这条日志的同时会实时关联获得包括商品实时库存在内的相关商品数据,并以商品为单位累积 对应的点击/加购/成交数据,提供算法插件进行实时售罄率和转化率的计算更新,得到的数据更新自动同步给下游的ISearch5引擎、UPS和天猫推荐接 口。整个过程在几秒内自动完成,当新的用户再发起搜索请求时,先从BTS获得自己的测试信息,由SP将搜索请求连带测试信息传输至ISearch5引擎, 引擎内部的战马框架根据测试信息选择对应的算法模型,算法模型在对引擎查询返回的商品列表进行排序时,可以获取列表中所有商品经过PORA更新过的最新售 罄率和转化率数据,对即将售罄的商品进行降权,对转化率高的商品进行加权,从而完成实时流量调控的目的。其中不同测试可能对应不同的算法模型,不同模型的 降权和加权力度可能各不相同,因此各个分桶测试下算法的流量调控效果也各不相同。BTS服务的高效便捷性可以允许算法同学当天根据实时报表来切换排序策 略。此次实时流量调控不仅仅服务于搜索业务本身,也同时通过UPS和相关接口输出实时武器给兄弟团队(天猫推荐, 直播间, 店铺内搜),来共同优化业务效率。
三、双11流量调控效果
在进入效果数据review之前,需要明确指出一点,下面给出的数据都是基于AB-test机制得到实际效果,基准桶与测试桶除了在实时流量调控环节有差异外,所有其他的环节都保持一致,因此实际的效果对比数据都是能够反映算法调控的真实效果。
3.1 预热期效果
首先我们来看下预热期从以下几个指标下的对比效果; 预热期加购量及其引导双11当天成交金额
加购量提升 | 引导当天成交金额提升 | |
主搜索PC | 10.8% | 5.3% |
无线andriod | 13.4% | 5.5% |
无线iphone | 16.2% | 11.4% |
无效加购量对比
无效加购减少 | |
主搜索PC | -37.6% |
无线 | -12.4% |
3.2 双11当天效果
接下来再看看双11当天的效果。 系统运行情况:双11当天PORA在0-1点的最高峰QPS超过35万/s,主要的点击和成交行为日志平均延迟除0点后10分钟内出现波动最高到过20秒 外,全天维持在正常的几秒范围内。当天累计共更新5.5亿条实时增量索引。 算法效果:在双11当天我们关注的主要指标: 成交相关指标
金额提升 | 转换率提升 | uv价值提升 | |
主搜索PC | 4.7% | 6.5% | 4.7% |
无线andriod | 7.4% | 10.7% | 7.4% |
无线iphone | 6.9% | 8.3% | 6.7% |
四、改进和未来的发展
今年双11是我们第一次大规模的实时调控流量,数据指标给了我们很大的信心,但是模型里面的很多参数是根据去年双11的数据计算出来的,在后续的工作中我们会通过在线学习的方式,利用今年实时的数据训练实时模型,进一步提升效果。