大厂的视频推荐索引构建解决方案

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:

  • 中央/分销预订系统性能优化
  • 活动&优惠券等营销中台建设
  • 交易平台及数据中台等架构和开发设计

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考:

1 背景

在视频推荐场景:

  • 让新启用的视频尽可能快的触达用户,对新闻类内容尤为关键
  • 快速识别新物品的好坏,通过分发的流量,以及对应的后验数据,来判断新物品是否值得继续分发流量

这两点对索引先验数据和后验数据的延迟都高要求。下文介绍视频推荐的索引构建方案。

  • 先验数据:视频创建时就带有的数据如tag,作者账号id
  • 后验数据:用户行为反馈的数据如曝光、点击、播放

2 视频推荐整体架构

数据链路角度,从下往上:

  • 视频内容由内容中心通过MQ给到我们,经过一定的处理入库、建索引、生成正排/倒排数据,这时候在存储层可召回的内容约1千万条
  • 经召回层,通过用户画像、点击历史等特征召回出数千条视频,给到粗排层
  • 粗排将这数千条视频打分,取数百条给到精排层
  • 精排再一次打分,给到重排
  • 重排根据一定规则和策略进行打散和干预,最终取10+条给到用户

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

基于此架构,需设计一套召回/倒排索引,以实时/近实时延迟来处理所有数据。

3 方案设计

旧方案的索引每半小时定时构建,无法满足近实时要求。分析索引构建方案,发现挑战:

  • 数据虽不要求强一致性,但需要保证最终一致性
  • 后验数据写入量极大,APP用户行为每日百亿+
  • 召回系统要求高并发、低延迟、高可用

3.1 业界主流方案调研

Redis方案灵活性较差,直接使用较难,需较多定制化开发,先排除。

可选方案主要在自研或开源成熟方案。研究发现:

  • 自研索引开发成本较高
  • 简单自研方案可能无法满足业务需求,完善的自研索引方案所需开发成本较高,需多人团队开发维护

最终选择基于ES的索引服务。不选Solr,主要因为ES有更成熟社区及云厂商PaaS服务支持,使用更灵活方便。

3.2 数据链路图

3.2.1 方案介绍

数据链路角度分两块:

  • 先验数据链路,数据源主要来自内容中心,通过解析服务写入到CDB中。其中这个链路又分为全量链路和增量链路

    • 全量链路主要是在重建索引时才需要的,触发次数少但也重要。它从DB这里dump数据,写入kafka,然后通过写入服务写入ES
    • 增量链路是确保其实时性的链路,通过监听binlog,发送消息至kafka,写入服务消费kafka然后写入ES
  • 后验数据链路。APP用户行为流水每天有上百亿,这个量级直接打入ES绝对扛不住。需对此进行聚合计算

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

3.2.2 一致性问题分析

该数据链路存在的一致性问题:

① Redis写模块,需先读数据,累加后再写入

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个独立进程

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

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

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

线上0停机高可用在线索引升级流程:

3.2.3 写入平滑

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

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

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

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

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




不同时间段,均达到平滑效果。

4 召回性能调优

4.1 高并发场景优化

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

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

多级缓存方案:

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

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

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

该方案解决了:

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

4.2 ES性能调优

4.2.1 设置合理的primary_shards

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

根据我们的经验结合官方建议,通常单个shard为150G比较合理,由于整个索引大小10G,我们计算出合理取值范围为110个,接下里我们通过压测来取最合适业务的值。压测结果:


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

4.2.2 请求结果过滤不需要的字段

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

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

4.2.3 设置合理routing字段

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

这样查询时也可根据指定字段路由,到指定分片查询,无需到所有分片查询。根据业务特点,将作者账号id puin 作为路由字段,路由过程:

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

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

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

本文由博客一文多发平台 OpenWrite 发布!

热门相关:铁血大明   懒散初唐   娇妻如云   楚汉争鼎   神医嫁到