腾讯看点视频推荐索引构建方案

【腾讯云 Elasticsearch Service】高可用，可伸缩，云端全托管。集成X-Pack高级特性，适用日志分析/企业搜索/BI分析等场景

一、背景

在视频推荐场景中，一方面我们需要让新启用的视频尽可能快的触达用户，这一点对于新闻类的内容尤为关键；另一方面我们需要快速识别新物品的好坏，通过分发的流量，以及对应的后验数据，来判断新物品是否值得继续分发流量。

而这两点对于索引先验数据和后验数据的延迟都有很高的要求。下文将为大家介绍看点视频推荐的索引构建方案，希望和大家一同交流。

文章作者：纪文忠，腾讯QQ端推荐研发工程师。

注：这里我们把视频创建时就带有的数据称为先验数据，如tag，作者账号id等，而把用户行为反馈的数据称为后验数据，如曝光、点击、播放等。

二、看点视频推荐整体架构

从数据链路来看此架构图，从下往上来看，首先视频内容由内容中心通过消息队列给到我们，经过一定的处理入库、建索引、生成正排/倒排数据，这时候在存储层可召回的内容约有1千万条。

然后经过召回层，通过用户画像、点击历史等特征召回出数千条视频，给到粗排层；粗排将这数千条视频打分，取数百条给到精排层；精排再一次打分，给到重排；重排根据一定规则和策略进行打散和干预，最终取10 条给到用户；

视频在用户侧曝光后，从上之下，是另一条数据链路：用户对视频的行为，如曝光、点击、播放、点赞、评论等经过上报至日志服务，然后通过实时/离线处理产生特征回到存储层，由此形成一个循环。

基于此架构，我们需要设计一套召回/倒排索引，能够以实时/近实时的延迟来处理所有数据。

三、方案设计

在旧方案中，索引是每半小时定时构建的，无法满足近实时的要求。在分析这个索引构建的方案时，我们遇到的主要挑战有：

数据虽不要求强一致性，但需要保证最终一致性；
后验数据写入量极大，看点用户行为每日达到百亿；
召回系统要求高并发、低延迟、高可用。

1. 业界主流方案调研

通过对比业界主流方案，我们可以看到，基于Redis的方案灵活性较差，直接使用比较困难，需要进行较多定制化开发，可以首先排除。

因此我们可选择的方案主要在自研或者选择开源成熟方案。经过研究，我们发现如果自研索引开发成本较高，而简单的自研方案可能无法满足业务需求，完善的自研索引方案所需要的开发成本往往较高，往往需要多人的团队来开发维护，最终我们选择了基于ES的索引服务。

至于为什么选择基于ES，而不是选择基于Solr，主要是因为ES有更成熟的社区，以及有腾讯云PaaS服务支持，使用起来更加灵活方便。

2. 数据链路图

（1）方案介绍

如下图所示：

这个方案从数据链路上分为两大块。

第一块，先验数据链路，就是上半部分，我们的数据源主要来自内容中心，通过解析服务写入到CDB中。其中这个链路又分为全量链路和增量链路。

全量链路主要是在重建索引时才需要的，触发次数少但也重要。它从DB这里dump数据，写入kafka，然后通过写入服务写入ES。

增量链路是确保其实时性的链路，通过监听binlog，发送消息至kafka，写入服务消费kafka然后写入ES。

第二块，是后验数据链路。看点的用户行为流水每天有上百亿，这个量级直接打入ES是绝对扛不住的。所以我们需要对此进行聚合计算。

这里使用Flink做了1分钟滚动窗口的聚合，然后把结果输出到写模块，得到1分钟增量的后验数据。在这里，Redis存储近7天的后验数据，写模块消费到增量数据后，需要读出当天的数据，并于增量数据累加后写回Redis，并发送对应的rowkey和后验数据消息给到Kafka，再经由ES写入服务消费、写入ES索引。

（2）一致性问题分析

这个数据链路存在3个一致性问题需要小心处理：

第一，Redis写模块这里，需要先读出数据，累加之后再写入。先读后写，需要保证原子性，而这里可能存在同时有其他线程在同一时间写入，造成数据不一致。

解决方案1是通过redis加锁来完成；解决方案2如下图所示，在kafka队列中，使用rowkey作为分区key，确保同一rowkey分配至同一分区，而同一只能由同一消费者消费，也就是同一rowkey由一个进程处理，再接着以rowkey作为分线程key，使用hash算法分线程，这样同一rowkey就在同一线程内处理，因此解决了此处的一致性问题。另外，通过这种方案，同一流内的一致性问题都可以解决。

第二，还是Redis写模块这里，我们知道Redis写入是需要先消费kafka的消息的，那么这里就要求kafka消息commit和redis写入需要在一个事务内完成，或者说需要保证原子性。

如果这里先commit再进行redis写入，那么如果系统在commit完且写入redis前宕机了，那么这条消息将丢失掉；如果先写入，在commit，那么这里就可能会重复消费。

如何解决这个一致性问题呢？我们通过先写入redis，并且写入的信息里带上时间戳作为版本号，然后再commit消息；写入前会比较消息版本号和redis的版本号，若小于，则直接丢弃；这样这个问题也解决了。

第三，我们观察到写入ES有3个独立的进程写入，不同流写入同一个索引也会引入一致性问题。这里我们可以分析出，主要是先验数据的写入可能会存在一致性问题，因为后验数据写入的是不同字段，而且只有update操作，不会删除或者插入。

举一个例子，上游的MySQL这里删除一条数据，全量链路和增量链路同时执行，而刚好全量Dump时刚好取到这条数据，随后binlog写入delete记录，那么ES写入模块分别会消费到插入和写入两条消息，而他自己无法区分先后顺序，最终可能导致先删除后插入，而DB里这条消息是已删除的，这就造成了不一致。

那么这里如何解决该问题呢？其实分析到问题之后就比较好办，常用的办法就是利用Kfaka的回溯能力：在Dump全量数据前记录下当前时间戳t1，Dump完成之后，将增量链路回溯至t1即可。而这段可能不一致的时间窗口，也就是1分钟左右，业务上是完全可以忍受的。

线上0停机高可用的在线索引升级流程如下图所示：

（3）写入平滑

由于Flink聚合后的数据有很大的毛刺，导入写入ES时服务不稳定，cpu和rt都有较大毛刺，写入情况如下图所示:

此处监控间隔是10秒，可以看到，由于聚合窗口是1min，每分钟前10秒写入达到峰值，后面逐渐减少，然后新的一分钟开始时又周期性重复这种情况。

对此我们需要研究出合适的平滑写入方案，这里直接使用固定阈值来平滑写入不合适，因为业务不同时间写入量不同，无法给出固定阈值。

最终我们使用以下方案来平滑写入：

我们使用自适应的限流器来平滑写，通过统计前1分钟接收的消息总量，来计算当前每秒可发送的消息总量。具体实现如下图所示，将该模块拆分为读线程和写线程，读线程统计接收消息数，并把消息存入队列；令牌桶数据每秒更新；写线程获取令牌桶，获取不到则等待，获取到了就写入。最终我们平滑写入后的效果如图所示：

在不同时间段，均能达到平滑的效果。

四、召回性能调优

1. 高并发场景优化

由于存在多路召回，所以召回系统有读放大的问题，我们ES相关的召回，总qps是50W。这么大的请求量如果直接打入ES，一定是扛不住的，那么如何来进行优化呢？

由于大量请求的参数是相同的，并且存在大量的热门key，因此我们引入了多级缓存来提高召回的吞吐量和延迟时间。

我们多级缓存方案如下图所示：

这个方案架构清晰，简单明了，整个链路: 本地缓存(BigCache)<->分布式缓存(Redis)<->ES。

经过计算，整体缓存命中率为95 %，其中本地缓存命中率75 %，分布式缓存命中率20%，打入ES的请求量大约为5%。这就大大提高了召回的吞吐量并降低了RT。

该方案还考虑缓了存穿透和雪崩的问题，在线上上线之后，不久就发生了一次雪崩，ES全部请求失败，并且缓存全部未命中。起初我们还在分析，究竟是缓存失效导致ES失败，还是ES失败导致设置请求失效，实际上这就是经典的缓存雪崩的问题。

我们分析一下，这个方案解决了4点问题：

本地缓存定时dump到磁盘中，服务重启时将磁盘中的缓存文件加载至本地缓存。
巧妙设计缓存Value，包含请求结果和过期时间，由业务自行判断是否过期；当下游请求失败时，直接延长过期时间，并将老结果返回上游。
热点key失效后，请求下游资源前进行加锁，限制单key并发请求量，保护下游不会被瞬间流量打崩。
最后使用限流器兜底，如果系统整体超时或者失败率增加，会触发限流器限制总请求量。

2. ES性能调优

（1）设置合理的primary_shards

primary_shards即主分片数，是ES索引拆分的分片数，对应底层Lucene的索引数。这个值越大，单请求的并发度就越高，但给到上层MergeResult的数量也会增加，因此这个数字不是越大越好。

根据我们的经验结合官方建议，通常单个shard为1~50G比较合理，由于整个索引大小10G，我们计算出合理取值范围为1~10个，接下里我们通过压测来取最合适业务的值。压测结果如下图所示：

根据压测数据，我们选择6作为主分片数，此时es的平均rt13ms，99分位的rt为39ms。

（2）请求结果过滤不需要的字段

ES返回结果都是json，而且默认会带上source和_id,_version等字段，我们把不必要的正排字段过滤掉，再使用filter_path把其他不需要的字段过滤掉，这样总共能减少80%的包大小，过滤结果如下图所示：

包大小由26k减小到5k，带来的收益是提升了30%的吞吐性能和降低3ms左右的rt。

（3）设置合理routing字段

ES支持使用routing字段来对索引进行路由，即在建立索引时，可以将制定字段作为路由依据，通过哈希算法直接算出其对应的分片位置。

这样查询时也可以根据指定字段来路由，到指定的分片查询而不需要到所有分片查询。根据业务特点，我们将作者账号id puin 作为路由字段，路由过程如下图所示：

这样一来，我们对带有作者账号id的召回的查询吞吐量可以提高6倍，整体来看，给ES带来了30%的吞吐性能提升。

（4）关闭不需要索引或排序的字段

通过索引模板，我们将可以将不需要索引的字段指定为"index":false，将不需要排序的字段指定为"doc_values":false。这里经测试，给ES整体带来了10%左右的吞吐性能提升。

五、结语

本文介绍了看点视频推荐索引的构建方案，服务于看点视频的CB类型召回。其特点是，开发成本低，使用灵活方便，功能丰富，性能较高，符合线上要求。

上线以来服务于关注召回、冷启动召回、tag画像召回、账号画像召回等许多路召回，为看点视频带来较大业务增长。未来随着业务进一步增长，我们会进一步优化该方案，目前来看，该技术方案还领先于业务一段时间。最后欢迎各位同学交流，欢迎在评论区留言。