​导语 | 看点信息流每天为亿级用户提供海量实时推荐服务，除了大并发/低延迟/高性能等传统架构挑战以外，还有哪些推荐系统特有的架构挑战难题，又是如何解决的？本文是对腾讯看点独立端推荐研发中心总监——彭默在云＋社区沙龙online的分享整理，希望与大家一同交流。

一、看点信息流

在 QQ 浏览器的主页可以看到腾讯看点的信息流，信息流有三种形态：小视频、短视频、图文，属于业界信息流最主要的形态。目前浏览器用户破亿，点击曝光等相关流水每日有百亿左右，机器数接近万级。

二、看点信息流基本架构和挑战

信息流已经发展很多年了，架构层面都是大同小异。一个信息流系统分为最底部的数据层，包括了倒排/特征/用户模型；数据层上面是召回，召回有隐式召回、显式召回等。

显式召回会根据兴趣点、主题运行，隐式召回是根据相似度召回，也有基于图像的召回，如 UCF、ICF 和 RNN 的召回。召回的品类非常丰富，它们构成了整个召回层。

召回数据非常多，在数量较多的情况下需要粗排。粗筛注重性价比，召回十万的量级需要进行筛选再传递到精排，再进行筛选。精排特征更丰富、算法模型更复杂。

最上面是展控，拿到数据以后要进行多样性处理以及人工干预策略，再返回最后的十几条结果给用户。

另外一条数据流就是，用户的点击和曝光数据流上传到后台，计算出物品特征，刻画用户画像。

从架构层面看，做什么事情对推荐系统效果有提升呢？首先是特征系统的实时性。因为推荐系统在选择时，是基于内容之间进行 PK，PK 非常重要的一点是内容的特征实时生成，就像一个人的代谢越快就越健康。

比如，一条内容的 CTR 一分钟之内就得到反馈，和一个小时之后才反馈有着极大差别，这是对实时性的挑战。

再举一个用户模型例子，在信息流中进行浏览，不点击与亚马逊有关的文章，这一次不点击的行为在下一次刷新就可以反馈出来，这是对用户模型的要求，是大型信息流的标配。

内容服务和索引服务指在网上出现突发事件，新文章进入平台时，把内容入库。这里有一系列的流程，比如人工审核、NLP 打分、排重等等处理后，进入倒排能够被召回，进而线上进行曝光，这就是内容入库的实时性。

关于计算力，看点信息流的内容池是千万级别的，现在召回层能够做到十万级，平台能把召回做到万级、精排做到千级，扩大召回计算量也可以提升系统的效果。

计算力首先是大家都通用的办法，那怎么样去并行计算？十万条的结果可以拆成十个一万条进行运算，但需要想一个问题，是不是并行度越高越好？其实不是的，要注意大扇出的问题。

传统后台的优化要求，是看代码、架构上如何进行优化，也就是性能优化。而另一块容易被忽略的，是如何做用户内容曝光过滤，这个功能看似简单，实行起来却容易碰到不少问题，下文也会详细的介绍。

怎么样提升开发效率？这个概念比较泛，首先有两点，一是算法跟架构如何分离，算法只负责训练模型、设计算法、设计特征，代码由架构来写，现在业界没有团队可以做得到。

推荐系统召回有一百多条线路的召回，有这么多人负责这么多召回吗？这也是不可能完成的事情，一百个召回如何提高开发效率也是重点需要解决的问题。

三、特征系统

对于推荐系统，特征越多算法效果越好，比如 CTR 包括全局 CTR、策略 CTR 等，分有有很多的维度。

其次是特征系统的线上挑战非常大，以我们系统为例，每秒钟的峰值达到千亿个特征，换算成流量每秒能达到 TB 级。特征实时生成，特征 CTR 在用户点击曝光后可以很快反馈到线上物品特征中，做到高并发、高吞吐情况下秒级返回。

这里还牵扯到命中率，特征系统设计的方案较多是用多级缓存、文件行同步的。而我们方案比较特别，各个服务在使用特征时，通过 API、lib 库的方式调用，只需要查就可以了，特征数据已经通过后端的特征计算好，push 到各个机器上面。

另外一个问题就是，这样做对内存的要求特别高。我们有着千万级内容，单机存不下全部内容的特征，所以需要做优化。

因为对物品的计算是分片式，所以特征也是可以做到分片式的，这样单机对内存的消耗就可以控制；第二是这样做可以减少很多的跨网络调用，每秒 TB 级的传输，换成本地查就可以规避掉。

要保证低时延、更新快、命中率高，其实就看各家物品情况取折中方案，怎么样达到一个合理的平衡。

四、用户模型

用户点什么、不点什么，下一刷要反馈出来，怎么做到准和快？

用户画像有三个窗口，一是 T+1 的窗口，今天以前的行为，二是当天的行为，最近点了两百条又是一个窗口，所以需要完整的窗口描述用户的行为。

二是打分运算，用模型进行打分，很多团队是通过人工经验进行拟合的。

三是要考虑用户换机，换了一个手机后用户画像如何迁移过去，也要考虑外部的画像，比如类似 BAT 公司不止一个产品，其他的产品用户画像也可以拿来用，这是画像系统需要考虑的一个地方。

具有挑战的地方首先是长期画像 T+1 的处理。我们每天需要处理百亿级的流水，处理对时间上什么要求呢？第二天零点开始到第二天的五、六点这个区间，用户访问逐步上来了，留给我们时间是 4 到 5 个小时，假如机器够多就能很快处理完，一般处理分几个步骤：

首先是对数据进行预处理，进行不同特征的计算，最关键是要把画像 Base 导入一个存储中去，然后交给业务流程处理。

二是机器够不够多，机器多的话可以直接并行计算，速度很快。而最重要的是一些压缩的应用、业务逻辑角度而言如何进行剪枝，有些用户兴趣点非常多，是不是所有都要，这里需要考虑性价比。

把时间缩短两倍，基本上就可以满足 12 点到 4 点的要求了。画像处理后进行生成是用 LR 模型，用户上一刷的点击反馈得非常快，还会外部流水进行融入，三是实时进行的打分，这是线上的流程。

五、online learning

线上样本如何拼接，模型如何训练和分发？

第一是腾讯内部有个分布式学习框架叫无量，我们团队做的工作是将样本拼接进行优化，最早是通过 hive 小时级拼接，后来通过实时进行拼接，落样本的时候需要进行时间窗的等待。

为什么要这样做？因为用户不一定实时点，样本上报之后会成为负样本，而用户点击后上传会变成正样本。时间窗取多少要具体分析，控制在半小时以内，有些产品用户点击得比较快可以取快一些，这是自己设置的过程。

第二是模型更新，可以实现增量更新的，最早也定为全量更新，后来改成分钟级的定时增量+小时级全量更新，这里面模型是怎么发布到机器上去的？腾讯内部有个容达系统，专门解决文件发布问题。

索引服务 - 高性能 内容入库实时生效 满足多种推荐业务需求

我们在最早做推荐系统的时候也调研过索引，因为它是整个系统里的最底层组件，原因如下：

第一，一个用户有很多兴趣点，两三百个兴趣点很正常，并发量每天会有千亿次的查询，它的速度要非常快。

第二，突然插入内容时，如何快速的在线上生效。之前也跟 ES 组件做对比 ，首先是基于索引长度 ，索引拉链非常长，主题的拉链也非常长，需要有能力支持长链。

第三，需要能支持曝光过滤。因为用户的曝光过滤每层都不能少，如果在最后一层十几条一起做，会让很多已经曝光的内容占了坑，导致整个系统效果变差。所以从最下面的索引层就要开始做曝光历史过滤，这个跟业务耦合比较紧密，是不可避免要做的。

第四，拉链长，必然要做截断，这就牵扯到排序的问题，是其他组件无法支持的。

内容的时效性很重要，内容改变之后线上必然需要多个索引去做多个 AB Test，比如时效性的需求要上线，如何去做自动化的 Test 是比较难的。

我们从自研索引处理，设计上并不复杂，通过 hash 后面挂链表的形式进行处理。考虑到整个物品数量是千万级，基本单机可以扛下。方法是单机多部署，这样的话，线上性能表现也比较好，非常稳定一直没有线上事故。

六、高并行大扇出 - 召回条数扩大的

如何扩大单位条数，基本上大家都会把召回数目进行分片处理，把它分发到不同的进程或者线程处理。

此时关键的地方在于要考虑扇出的问题，并发化程度是否越高越好？不一定，也要考虑整体耗时和最慢响应包、分片和集群的数，并行数越高损失概率越大。

关于大量服务做的数据对比，如上图所示。

七、性能优化 - 减少50%的耗时

性能优化方面，整体性能优化是线上累积时减少了将近 50% 的耗时，目前推荐后端耗时要在 500 毫秒以下，如果不做优化，会飙升到一秒，这样的系统基本处于不可用的状态。

归纳首先是架构层面尽量用分布式并行，尽量做并行计算；二是很多计算可以统一起来打分；三是很多在线计算是可以改进的，每次上来之后用户特征不一样，计算的话可以用近线计算，相关特征不会有变化是它的优化点。

后台架构的功能是 cache 如何提升系统性能，如何缓存一些打分结果，精排结果是不是可以进行缓存等等。

机房部署方面，我们分四地进行异地部署，每地之间、机房之间的延时较高，如何推动运维把机房尽量部署到一个交换机上，这些都是需要不断优化的。

而系统公用组件后面许多无谓的开销，需要把整个调用链缩短。系统里有很多全量的计算，一些很明显的问题、UCF，后面是用了计算方法从全量计算变成 top K 计算，可以极大的提升系统性能。

关于代码级的优化，GCC 一个新版本的升级，大部分是因为内层的优化、C++ 新的特性应用、数据结构的优化。而如何减少日志的无效 IO，协议里面训练化和反训练化的开销如何减少，推荐链路非常长，协议也存在这样问题。

怎样优化代码逻辑？举个例子，在展控层特别多的逻辑情况下，算法同学不一定可以把算法代码写好，最近拿到的一百毫秒优化就是架构同学做的，重构代码后耗时的确下降了。

这里要保证无 diff，如果打分值被改变了，这里引入了一些 Bug，影响了推荐系统的效果，所以我们的代码都要求做无 diff 测试。

八、用户曝光内容过滤

做用户过滤基本都会采用布隆过滤器，一是信息流容忍误杀，概率比较小用户没什么感知；二是基于 hash 可以省内存，速度快，用户历史过滤变成一个库，全链路都可以过滤；三是根据用户的刷新速度动态调整过滤块的大小，不能专门给用户一个块，但块大小等级分布还可以根据动态变化，动态变化更新可以更省内存。

分布式跨地域用户曝光历史线上有什么问题呢？用户历史过滤的场景是：用户上一刷曝光十条，下一刷把十条过滤掉，上一刷和下一刷时间间隔短，我们的用户历史部署在腾讯的 KV 组件中，数据有变化的要先写到主再同步到备。

所以到了晚上流量特别高的时候，机房之间延迟较大，用户两刷间隔短的情况就会出现重复，所以我们会本地就存一俩份解决。

但是推荐系统多地容灾部署，用户有一定概率切换到异地，因为是考虑容灾做的，所以要考虑用户不同机房之间迁移的情况。

通过一致性的 hash+版本号机制保证同步过滤数据一致，通过这样的设计重复率降低了一个数量级，基本上解决了高峰期重复的问题。

推荐系统里有一个特点，上文讲的曝光用户是基于后台曝光，真实的曝光很多内容是后台曝光了，但用户没有看到的。

可能没有看到过的内容反而是质量非常高、打分非常高的内容，如果有办法把这些内容捞回来，重新召回推荐，这肯定对系统提升有帮助，我们也通过真实的曝光修正后台曝光，对点击效果的提升也很大。

提升召回开发率

关于开发效率的提升，算法跟架构的分离目前来看还不是特别理想的状态，线上有特别多的召回，一百多路召回不可能做到每个人都做专门的召回，还要考虑开发效率问题。

于是我们设计了一个默认的召回打分模型，它有几个特点：以前召回的不要自己打分了，全部由 PE 完成，PE 进行召回初筛，物理的离线计算对物品出差结果再做精细化的计算精度更高，对计算结果拆成两个做，把整个计算流程分布式并行计算，能够提升计算量，15 毫秒就可以完成十万量级的文档预测，效果提升也比较明显。

Q&A

Q：用户曝光历史过滤具体是怎么做的？

A：原理是布隆过滤器，一般而言是做信息流的标配的方案。布隆过滤器线上如何用，第一点如何设计过滤器更加省内存，二是分布式场景，考虑过滤器的内容如何同步，三是真实曝光修正后台曝光，这样可以提升业务效果

Q：bloomfilter是redis保存的吗？

A：对。

Q：看点用户访问是规律的吗？

A：是规律的，会有早高峰和晚高峰，早高峰是 9 点，晚上是 8~10 点。

Q：看点用户的并发访问是规律的么，如何处理资源弹性的问题？

A：坦白说这是运维同学要做的，我们底层 RPC 通讯框架本身就要支持自动的伸缩，自动伸缩无外乎留一定的阈值上限，自动触发扩容，调用服务无感知这是属于基础组件同学需要考虑的问题。

Q：如何动态扩容过滤器？

A：刚开始我们对用户部署多少也不知道，对一个用户的摸索情况，一个用户 1M、2M，用户刷的多，就可以多分配，类似 vector 的内容机制。

Q：索引服务用的是 DCache 吗？

A：对。

Q：索引能用es存储吗？效率会不会很低？

A：用什么保存都无关，问题是怎么做同步，跟场景，两刷之间非常快，就有这样的问题。

Q：新用户如何推荐？

A：用户维度就是去拿额外的数据，内容维度就是新热。

Q：信息流推荐里怎么利用用户搜索画像呢？

A：把搜索直接作为一个特征，交给模型去学

Q：索引服务如何做到无锁，并发写怎么解决？

A：采用无锁的数据结构，整个索引只有单个写，没有并发写。

Q：召回推荐什么时候触发？

A：用户请求主 feed 就会触发

Q：推荐系统的架构如何保证时延要求呢？

A：架构层面优化和代码层面的优化。

Q：索引服务使用 golang 写能扛？

A：应该是可以的，语言层面的开销差别不会太大，我们线上就已经 2ms，如果差别能差几毫秒呢，应该是影响不大。

Q：有删索引的场景吗？

A：当然有，但是只删正排(快照) 不删倒排。

Q：统一的打分服务如何处理不同召回的个性化需求？

A：不是所有召回都必须接 PE   召回之间会看 unique 价值来保证个性化需求。