今日头条推荐系统架构设计实践.pptx

今日头条推荐系统架构设计实践.pptx

《今日头条推荐系统架构设计实践.pptx》由会员分享，可在线阅读，更多相关《今日头条推荐系统架构设计实践.pptx（32页珍藏版）》请在冰豆网上搜索。

今日头条推荐系统架构设计实践,金敬亭,互联网时代内容分发的变革,门户,社交媒体&社交网络,推荐引擎,今日头条本质上是一个强大的智能推荐引擎,截至2016年12月底,头条DAU：

7800w；头条MAU：

1.75亿；单用户日平均使用时长：

76分钟；用户行为峰值：

150w+msg/s;每天训练数据：

300T+（压缩后）；机器规模：

万级；,系统架构,模型更新；UserProfile;GroupProfile;统计&实验指标；,用户行为数据,PGC/UGC/Crawl,文章profile,用户profile,文章属性,cache集群,倒排服务,正排服务,预估服务,Feed,召回服务,Kafka,StormHadoopSpark,Video,Channel,App&StreamAPI,Profile服务,模型,用户画像,面临挑战,期望快速反馈：

10min内；feature数量：

200+;存量用户数和每天的用户行为数据量巨大；在线存储：

读写吞吐高，要求延时低且可预期；,流式计算,实现StormPython框架写MR的方式写StreamingJob；Topology用Yaml描述，代码自动生成，降低编写job成本；框架自带KafkaSpout，业务仅关注拼接和计算逻辑；BatchMR相关算法逻辑可以直接复用在流式计算中；,Job数：

300+；Storm集群规模：

1000+；,在线存储-abase,基于Rocksdb的分布式存储系统：

基于文件的全量复制和基于rocksdb自身WAL的增量复制；内建和backstorage强一致的key级别LRUcache；,基于bucket的sharding和migration；基于compactionfilter的延迟过期策略；,在线存储-abase,数据量：

压缩后，单副本85T；QPS：

读360w、写40w；内建Cache命中率：

66%；延时：

avg1ms、pct994ms;机器数：

单副本40台，SSD容量瓶颈；,架构抽象,推荐召回荐召回-典型策略,根据兴趣标签拉取相应文章并ranktop结果,德甲英超,互联网金融,搞笑,电商,。

离线更新tag倒排索引,以兴趣分类召回为例，实际上这里的tag可以是各种显式兴趣标签和隐式兴趣特征,用户兴趣标签,1.Stormpython框架,德甲电商O2O搞笑历史军事,0.30.20.20.10.10.1,推荐召回-抽象,（gid2,score2）,（gidn,scoren）,离线倒排更新fid:

（gid1,score1）在线search,（fid1,score1）（fid2,score2）（fidk,scorek）（gid1,score1）（gid2,score2）（gidn,scoren）,其他组件filter、merge、boost等；,创建时间；过期时间；,Keyword；Topic；,阅读数；展现数；,文章属性,文本信息,动态属性,正排-相关数据,推荐系环节，如：

召回、过滤及预估等需要文章正排；文章包括图文、视频、UGC内容，正排属性主要包括：

正排-痛点,各模块各自维护相应的离线和在线，稳定性和时效性无法保证；格式多样:

json、msgpack、protobuf等；字段重复、含义不一致，存储不统一：

mc、redis等；Trouble-shooting成本比较高；,正排-统一方案,200+字段，由protobufIDL描述，按”,簇”存储；,统一离线刷新框架，保证高时效性和稳定性；统一存储和对外接口；提供完善的debug工具：

查询正排内容、更新时间等；,存储方案-index_service,Updater,update,search,OnlineService,IndexService,实时更新,跨机房同步,Updater,OnlineService,update,search,search,search,OnlineService,OnlineService,IndexService,IndexService,IndexService,基于lmdb存储，MVCC、读写相互不阻塞；内存映射，0拷贝，如：

过滤；,存放在共享内存，实现TTL、compaction、定期持久化；给召回提供算子：

filter、merge、boost等；单机1wQPS，pct991ms，没有明显长尾；,实时更新,成本压力,架构1.0-局部优化,基于Thrift+Python多进程模型：

并行化：

gevent、线程池；C+扩展：

cython、boost.python;解释器：

pypy，需要适配依赖，主要用于离线；基础库so版本：

protobuf、thriftprotocol、json；服务处理时间和用户感知时间gap；,架构1.0-痛点,痛点主要来自Python多进程模型：

性能无法满足策略优化，如：

增加预估条数；单机QPS低，内存瓶颈，CPU用不上去，浪费严重；只能堆机器提高吞吐能力；,架构2.0,完全重构，拥抱C+11：

ThriftNonblockingServer多线程模型；机器数减少60%+；,平均延时下降30%+，PCT99下降50%+；,延时控制,Cache问题,在推荐系统中Cache并非总是万金油：

一个用户刷新两次，不能重复，但搜索同一个query，短期内返回相同结果；实时的用户Profile和模型特征，Cache会影响指标；召回候选集、倒排拉链实时更新；,Cache应,但Cache依然是系统的重要组成部分，降低延时，避免雪崩：

LocalCache、分布式Cache、共享内存；一些招数空值回填；异步刷新；写时更新or写时删除；,Pool化,内存池：

tcmalloc、jemalloc；对象池：

复用对象，减少内存申请释放，实现warmup、shared_ptrdeleter自动归还；线程池：

并发执行，降低延时；连接池：

多RPC副本连接管理、长连接复用；,并化,openmp一行代码串行变并行；滥用，频繁创建和销毁线程；,线程池,方便监控：

空闲线程、pendingtask；配合future/promise更灵活；但不是并行度越高越好，多线程的overhead；,大扇出,获取feature需2000+的RPC调用，串行肯定是无法满足需求。

基于openmp的扇出调度：

问题：

openmp线程数太多，CPUload太高，但利用率低。

大扇出-优化,Thriftclient使用同步模型，需要更多的线程来实现并发；实现基于异步IO的thriftRPCfanout，将IO和序列化反序列化分离：

用更少线程实现扇出调用，CPUload下降20%+；,大扇出,；,长尾概率：

（1-0.999*2000）=86.5%传输大量小包，sys态占比高；增加Proxy，减少扇出和小包；,框架层面,thriftbugs：

10patches，性能不高；grpcorfbthriftor自研？

使用FbthriftServer模块CPU使用率下降20%+：

传输协议&IDL向下兼容；IOBuf应用，减少copy、避免一次性申请大内存；支持全异步调用：

扇出、并发；,可用性,降级机制：

自动降级和降级平台；调度优化：

封禁、探活、解禁；主动overflow：

丢弃长时间pendingtask；熔断：

降低后端压力，防雪崩；优雅退出：

运维0拒绝；多机房调度：

快速流量迁移；,未来挑战,数据、规模继续爆炸；多IDC的挑战；系统复杂性、ToubleShooting；资源利用率、资源调度；,