该文章来自阿里巴巴技术协会（ATA）精选集，原文发布于阿里云云栖社区（
http://yq.aliyun.com/articles/2699 ）

0. 前言

何为双链路实时计算体系？

• 微观实时计算链路

• a) 最细粒度商品/店铺/用户数据的实时

• b) 底层模型的实时

• 宏观实时计算链路

• 相比微观实时，宏观实时的对象粒度更粗，更上层

• a) 以实时效果为目标，基于bandit learning的实时策略寻优

• b) 以流量实时匀速化投放为目标，基于PID控制理论的实时流量调控

在整个实时计算算法优化工作中，金榕教授给予了细致指导，使得项目得以顺利开发和落地。

1. 搜索实时计算体系

1.1 系统架构

1.2 重要组件介绍

①Pora：

Pora是淘宝搜索基于iStream（自主研发的运行在Hadoop YARN上的实时计算引擎）+ HBase基础平台打造的一套实时计算和在线学习系统，支持在秒级别内对海量用户行为及其相关联的海量商品作实时分析处理，从中提取多维度的用户/商品数据特征，并采用分布式Parameter Server架构进行在线学习，从而使用户行为可以在几秒内影响搜索排序等在线服务。Pora目前已经应用于实时个性化搜索/推荐、实时反作弊、实时流量优化等诸多领域。

双11期间，Pora实现7*24持续运行无重启，双11当天共处理消息量1300亿，峰值QPS 500万。

②iGraph：

iGraph是淘宝搜索打造的实时在线图存储与查询的系统，可以提供大规模KV/KKV数据的存储、查询、更新和计算服务。目前支持了包括搜索/推荐个性化在内的众多业务线。

双11期间，iGraph 访问峰值QPS 245W，同时支持大规模实时数据更新，如用户实时点击表峰值更新QPS 28WQPS，用户信息表 40W QPS

③SP ：

SP（search planer）是搜索面向前端应用的统一服务接口，根据用户指定的查询条件制定查询计划，查询包括QP,igraph,ISearch5引擎在内的各个搜索后端系统，得到最终结果返回个前端。SP通过将业务逻辑从前端往后端下沉，简化了搜索调用逻辑，提升了前端系统性能。

④Isearch5引擎：

ISearch5是搜索最新一代引擎平台，服务于淘宝、天猫、B2B等各个搜索业务线，支持秒级实时索引，数据实时更新等众多特性。

⑤实时报表系统：

基于Galaxy平台的实时报表系统，实时统计分平台/桶/策略/商品类型/用户类型等多维度业务指标数据（包括但不限于曝光,点击,成交与加购等）。该系统提供分钟级别的实时反馈精度，让算法、产品、运营同学能够在功能升级、大促、运营推广中及时准确了解业务指标的变化，通过强大的数据闭环功能为快速响应及决策提供依据。该系统同时提供了丰富的使用接口，为算法同学在大促中在线寻优提供了可靠实时数据。

⑥BtsServer：

BtsServer是搜索的分桶测试管理服务平台，能够随时调整每个分桶的测试内容。依托实时报表系统产出的实时数据，今年在BtsServer平台上开发了实时策略寻优和实时流量调控两个模块，可以根据实时报表做智能化的分桶测试寻优，实现整体效果的最优化。

2. 在线学习

数据和模型是算法的两大核心，14年基于Pora我们现实了数据的实时更新。15年我们又在Pora上开发了基于Parameter Server架构的在线学习框架，实现了模型的实时更新。

why在线学习？

在batch learning中，一般会假设样本独立服从一个未知的分布D，学习得到的模型都是基于该分布的，如果分布变化，模型效果会明显降低。而在实际业务中，很多数情况下，一个模型生效后，样本的分布会发生大幅变化，因此学到的模型并不能很好的fit线上数据。而实时模型，能通过不断的去拟合最近的线上数据，解决这一问题；同时实时模型还能catch用户和商品的实时特征，因此效果会较离线模型有较大提升，特别是在实时数据极为丰富的情况下，例如双11和双12这种大促。

why秒级更新？

相比历史长期模型，小时级模型和纯实时秒级模型的时效性都有大幅提升，为什么我们选择了纯实时模型？一个方面是系统工程能力的允许，另外更重要的原因是业务需要，特别是在双11这种成交爆发力强，变化剧烈的场景，秒级实时模型时效性的优势会更加明显。下图是大家都看到的今年双11实时成交额情况，前面1小时已经完成了大概总成交的1/3，小时模型无法很好的catch这段时间里面的变化。

2.1 在线学习框架

模块介绍：

• Sample Worker：处理日志生成训练样本，Fetch最新的模型计算特征梯度

• FeatureHQ：将相同特征的梯度送到同一个FeatureWorker

• Feature Worker：接收梯度，计算更新模型

• Hbase：模型存储（lr模型的w，ftrl的z,n，矩阵分解的user,item向量）

特点：异步，并行，平台化

异步，并行：整个训练过程就像不断迭代的map-reduce，需要注意的是Sample Worker中的各个worker和Feature Worker中的各个worker是完全异步的，并没有做任何同步。一开始我们也非常担心这种纯异步的sgd训练方式是否有问题，但实验发现这套系统能够很好做到模型收敛，并且得到和同步训练差不多的准确性。

平台化：做为一个在线学习框架，我们不仅仅只是提供现成的算法，也可以让大家能够在这个框架下方便地开发实现自己定制的在线学习算法。目前是把三个主要的接口开放给开发者自己来实现：CalcSample（样本采样，样本特征,目标构建），CalcGradient（梯度计算），CalcWeight（模型更新）

目前这套在线学习框架已经支持训练样本百亿级别/每天，特征十亿级别。包括pc搜索，手淘搜索，天猫搜索，聚划算，淘金币在内的多个业务场景已经有10+的在线模型跑在上面。

2.2 pointwise model

2.2.1 LR/FTRL

Logistical Regression（逻辑回归）作为最常用算法之一，是我们实现的第一个在线学习算法。随后在lr基础上了做了简单的改动实现了Ftrl，模型更新（CalcWeight的实现）这一步不同。这里就不介绍lr和ftrl的原理了，有非常多的资料可以参考。下面说一下遇到的一些问题：

a) 纯异步训练的收敛性和准确性

前面提到过，异步训练的收敛性和准确性是我们非常担心的点，实际的实验效果表明模型能够正确收敛，并且准确性和离线同步训练比也差异不大。

下面是某一场景下的ctr预估应用在不同训练方式下的auc对比：

在线异步训练的auc比离线同步训练的auc是要差一点，但差异很小。有初值下效果更好一点。都远好于使用历史长期模型（历史数据训练的模型）的效果。

b) 模型稳定性

模型不稳定是在线学习在实际应用中遇到的一个大问题，比如在搜索排序场景下，如果短时间内模型变化太大，会造成排序结果剧烈变化，用户体验不连续。为了解决这个问题，预测打分的时候使用模型的平均值，可以有效地平滑掉这种不稳定。

实际操作中，还可以考虑把最开始的n轮去掉后再做平均（无初值情况下，最开始n轮模型的效果可能还比较差）。

当然了，模型的稳定性和时效性是一个trade off，为了兼顾这两点，更好的做法是使用移动平均（当前轮的前面t轮模型做平均）。

c) 热点问题

通过前面的框架图可以看到，feature worker其实就是一个reduce的过程。如果存在热点特征，比如截距特征beta0，这类特征的梯度会非常非常多，会造成这个特征所在的feature worker处理不过来，出现阻塞，从而造成这个worker节点上的所有特征的更新都延迟。为了解决这个问题，我们在sample worker上做了feature grad的合并（类似于mapreduce的map节点做local combine），大幅减少了往FeatureHQ发送的数据。

2.2.2 Online AUC Optimization

与online LR/FTRL 不同的是，在线学习中有一类是直接针对 AUC 进行优化的算法。AUC 直接优化是 NP-Hard，但有一些近似算法能够进行高效的求解。我们实现了 AUC 最大化算法- One-Pass AUC (Refence One-Pass AUC Optimization, Wei Gao, Rong Jin, Lu Wang, Shenghuo Zhu, Zhi-Hua Zhou. Artificial Intelligence Journal, 2014 )

2.3 pairwise model

why pair-wise？

在搜索中，算法更关注的是商品的排序，而不是单个商品的算分。使用point-wise算法，是通过回归单个样本的分数从而得到排序效果；而使用pair-wise算法，是直接优化商品之间的序关系。因此从loss的角度来看，point-wise上会有不必要的约束，这些约束常常会对序关系产生负向影响；pair-wise算法目标明确，是没有这些约束的。另外，从工程框架上来开，日志的不均匀会对point-wise的算法产生极大的不良影响，而pair-wise则不受此干扰。

因此，我们设计了一套针对排序优化的实时协同过滤框架，并在这个框架上设计和实现了2个pair-wise算法。2个算法均有实时和离线2部分，离线模型会作为实时模型的初始值使用，使用ODPS Graph实现；在线模型由PORA实现。下面会简单介绍模型的含义和实验结果

2.3.1 实时矩阵分解（Realtime Matrix Factorization for Ranking with Side Information）

假设我们有m个用户和n个商品，除用户向量
和向量

外，我们还为每个商品j学习一个bias，

。此时的我们将每个用户对每一个商品的偏好标示为：

在搜索排序中，我们更关注的是商品之间的顺序，而不是模型对偏好程度的预测值和真实值之间的平方误差或绝对值误差。从搜索日志中我们抽取训练三元组

，其中每一个三元组

表示用户i更偏好商品j，相比于商品k。对于这样的一个三元组，我们定义损失函数如下

其中，

是用户在商品j和k上的真实偏好程度，例如对于一次搜索展现引导的行为，可以设置偏好程度为：成交>加购>收藏>点击>PV。注意这里我们引入了Hinge loss，目的是当我们的模型排序正确时不去做冗余的抑制。此外，我们还使用了已有的一份数据

，描述的是商品之间关于被购买行为的相似度矩阵。如果2个商品在被购买的行为上相似，那么它们在隐空间的向量应该是尽可能靠近的。因此，类似于经典的拉普拉斯特征映射（Laplacian Eigenmap），我们使用了一个正则项体现这项约束

最后，我们需要优化的目标函数可以形式化为

2.3.2实时双线性模型（Realtime Bayesian Personalized Bilinear Model）

定义U为全体用户，I为全部商品，用户反馈S表示implicit feedback，

，每个商品，Item(

)，由2部分组成，分别是静态特征（Static descriptors）和动态特征（Temporal characteristics）； 每个用户，User(

)，同样由2部分组成，分别是特征(U)与用户ID(B)；行为，

（Interactive Feedback），其中

是0/1（实际上也可以是实数，这里只考虑0/1的implicit feedback）,表示用户u对商品i的偏好。

我们排序的目标是对用户设置全部商品上的排序方案，

，其中

表示偏序关系。

另外，我们定义

为用户u点击的全部商品,

为点击过商品i的全部用户。

在bilinear model中，每个用户对商品的偏好表示为：

D和C分别表示用户和商品的特征维度，B表示每个用户ID在商品特征上的偏移。将用户的B看做自身feature的一个稀疏维度，那么考虑商品有静态和动态2类属性，有：

该模型可以看做是将用户feature的每个维度向item的每个维度做投影，然后在商品空间上做点乘，W表示投影矩阵。

有了上面表示后，根据贝叶斯公式，我们求一个最大后验估计(MAP)。假设所有参数表示为

，则后验分布为：

右边第一项

，这里

这里表示判断函数。考虑到数据全局上的反对称性，可以对它进行简化：

在已知

和

的情况下，偏好i与j的差值表示为：

那么点击i而没有点击j的概率为：

我们算法的目标是最大化后验，于是：

2.3.3 实验与结果

实时个性化算法的目标是在淘宝搜索中提升用户的搜索体验，提高流量效率。从指标上表现为搜索的NDCG/MRR等指标，以及线上的CTR等指标。

下面2张图是一天的模型曲线，左图是矩阵分解的NDCG变化情况，右图是双线性模型的MRR变化情况。可以明显的看到随着模型的运行，MRR和NDCG值在不断上升，直接达到收敛。在收敛时候的指标值较最开始的初期，会有20%以上的提升。

3. 宏观实时（实时策略寻优,实时流量平衡）

3.1 系统架构

3.2 实时策略寻优

从广义上讲，策略可以是非常宽泛的概念。但在这里我们讲的策略主要是指排序中的特征融合策略。说起特征融合，ltr（learn to rank）是最传统的特征融合方法，也在我们搜索排序得到了广泛应用。但传统的ltr在特定场景下有一些局限：

a) 特征分无法通过历史数据准确获取。比如双11当天的实时特征分，日常流量下和大促流量下，特征分的分布完全不一样。

b) ltr的优化目标是我们定义的一个目标函数，并不是最终的线上结果，但任何目标函数的假设，都与线上真实的目标有一定的gap。所以离线效果（比如NDCG）提升，并不代表线上测试效果一定提升。

基于上面的局限性，今年我们尝试了另外一个思路，直接基于线上最终bts结果做策略优化。而bandit learning和zero-order优化是正是解决这类问题的方法。

3.2.1 算法流程

在学术领域，与bandit learning和zero-order 优化问题相关的方法非常多。但我们实际线上排序系统特征多，参数空间大，同时我们希望整体收益的最大化，即对不好的策略投入做尝试的流量尽量少，并尽快收敛到比效好的策略；因此，我们接合了bandit learning和zero-order opt设计整体算法流程图如下：

基本的思路就是：先用MAB从有限的离散策略集合里面选出最优策略，然后在最优策略基础上用ZeroOrderOpt做连续参数空间的进一步寻优。在寻优过程中会不断把当前的最优策略全量到接受桶。

3.2.2 Multi-Armed Bandit

根据已知的知识找到最优的策略，同时还能发现是否有新的策略收益更大，这是典型的增强学习里的double E（exploitation and exploration）问题。定义N个策略集，μ1,..,μN是N个策略收益分布的均值，每轮t选择某一个策略It=i，都可以得到其收益g(i,Yt)，因此，在T轮之后，定义损失函数ρ=Tμ∗−∑Tt=1g(i,Yt)，μ∗是每轮最大收益的均值，即μ∗=maxn{μn}。如果每一轮都选择都是最优的，那么损失ρ就等于0。定义g(i,Yt)的无偏估计g˜(i,Yt),

显然，E[g˜(i,Yt)|I1,...,It−1]=g(i,Yt)。

具体算法如下：

其中β，η，γ是参数。

首先需要选择参与融合的特征，然后将这些特征按照权重高、中、低档组合成候选策略集（特征a低中高 * 特征b低中高*..），并剔除一些人工认为不靠谱的策略。最终，我们选择N=18个策略。

开始寻优时，会从所有测试捅中拿出m个桶做bandit，剩余的桶做接受桶。每轮按照概率p选择m个策略做测试，每轮测试半个小时。然后根据这半个小时的实时反馈数据计算收益g(i,Yt)，并更新每个策略的概率pi,t。如此反复执行上述过程。同时每轮将当前概率pi,t最大的策略发送到接受桶。

当MAB收敛后（某一两个策略的概率p明显胜出），因为策略集是有限的，全局最优的策略可能并不在里面，因此，我们会再采用extra gradient算法在连续参数空间内继续寻优，找出更优的策略。

Question

为什么MAB收敛前就发送接收桶了?

Answer

判断MAB(从候选离散策略集合选最优)是否收敛的目的是用来判断是否可以开始run ExtraGradient了(作为ExtraGradient的初值),MAB本身并不是一定要收敛才发送。因为MAB收敛需要时间(双11当天早上大概7点才第一次收敛)，如果收敛之前不发送，那么这段时间(7点之前)接受桶的效果是浪费了的，没有享受到测试桶更好的效果。

那么没有收敛的情况下是否能发送呢？

a) 我们判断收敛的条件比较严格，即使没收敛当前的最优策略也是不错的。

b) 我们在发送之前还有一个和接受桶做PK的最后保障环节(不管是否收敛都会有这个环节)，PK赢了才会发送。

3.3 实时流量调控

3.3.1 关键词红包中的流量控制

今年的双11红包有了很多不同于往年的新鲜玩法，其中个在搜索发放的关键词红包就利用到了实时流量调控技术。关键词红包发放有两个方面的要求：一方面，需要履行与商家签订的合同，完成承诺给商家的到店 uv 数量；另一方面，要求完成的过程是平稳可控的。在 uv 资源充分的情况下，只要设置较大的发放概率，就能完成第一个目标。 然而发放概率过大容易导致很快就会将一天的目标完成了， 达不到平稳发放的目的。 在这里，我们采用 PID 控制器技术来控制发放的速度。

a) PID 控制器介绍

在控制理论和实践中，PID 是一类广泛使用的控制方法。PID 是“比例-积分-微分”的简写， PID 控制器根据控制原理，对偏差进行比例、积分、微分的调节，从而使被控变量的实际值与既定目标保持一致。

上图是PID控制系统的图示，其中 e(t) 是误差信号，u(t) 是控制量，Kp, Ki, Kd 分别是 P、I、D 的系数。

• 比例（P）控制：直接针对误差进行比例调节，误差越大，比例信号输出越强。举个例子，热水器温度调节系统，当前温度离设定温度差异较大时，就会开启较强的加热功率，等到离设定温度很近时，加热就会缓一些了。

• 积分（I）控制：对累积误差进行控制，其功能就是消除累积误差。

• 微分（D）控制：以误差的变化率作为控制因素，例如温度上升较快时，虽然没有达到设定温度，微分控制此时会适当降低加热功率，而单纯的比例控制器则可能导致超调现象。

3.3.2 搜索流量的平衡

搜索作为流量一大入口，除了做好流量的利用效率，还需要从宏观上做一些流量平衡。比如集市和天猫之间流量平衡，大/小/腰部卖家之间的流量平衡。我们目标并不仅仅是短期成交的最大化，而是考虑平台长期利益，在一些流量平衡约束条件下的最大化。实时操作中也利用了PID控制器的技术。

4. 双11实战效果

上述实时计算体系在今年双11发挥了至关重要的作用，是我们搜索成交增长的核动力。下面是各业务线和基准桶（平时全流量生效的最优效果）对比的提升数据，以及带来的增量成交。

• pc搜索/手淘搜索：预热期引导成交提升 11%，当天成交提升 8%

• 天猫搜索/猫客搜索：当天成交提升 7%

• 店铺内搜索：当天成交提升 3.4%

• 总共带来的成交金额提升20亿+

5. 结束语

要感谢的人太多，搜索大部分同学都或多或少参与了实时计算体系的建设，要感谢大家的共同努力。

去年双11，实时计算第一次在大促展露头角，并初露锋芒。今天双11，实时计算在各条业务线全面开花，实时计算体系也更加丰富。我们相信这远远不是终点，期待未来实时给我们带来更多的精彩！