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

1、今日头条推荐系统架构设计实践,金敬亭,互联网时代内容分发的变革,门户,社交媒体&社交网络,推荐引擎,今日头条本质上是一个强大的智能推荐引擎,截至2016年12月底,头条DAU：7800w；头条MAU：1.75 亿；单用户日平均使用时长：76 分钟；用户行为峰值：150w+msg/s;每天训练数据：300T+（压缩后）；机器规模：万级；,系统架构,模型更新；UserProfile;GroupProfile;统计&实验指标；,用户行为数据,PGC/UGC/Crawl,文章profile,用户profile,文章属性,cache 集群,倒排 服务,正排 服务,预估 服务,Feed,召回 服务,Kaf

2、ka,Storm Hadoop Spark,Video,Channel,App&Stream API,Profile服务,模型,用户画像,面临挑战,期望快速反馈：10min 内；feature 数量：200+;存量用户数和每天的用户行为数据量巨大；在线存储：读写吞吐高，要求延时低且可预期；,流式计算,实现Storm Python 框架写MR 的方式写StreamingJob；Topology 用Yaml描述，代码自动生成，降低编写job 成本；框架自带KafkaSpout，业务仅关注拼接和计算逻辑；Batch MR 相关算法逻辑可以直接复用在流式计算中；,Job 数：300+；Storm 集群

3、规模：1000+；,在线存储-abase,基于Rocksdb 的分布式存储系统：基于文件的全量复制和基于rocksdb 自身WAL的增量复制；内建和back storage 强一致的key 级别LRU cache；,基于bucket 的sharding 和migration；基于compactionfilter 的延迟过期策略；,在线存储-abase,数据量：压缩后，单副本85T；QPS：读360w、写40w；内建Cache 命中率：66%；延时：avg 1ms、pct99 4ms;机器数：单副本40台，SSD 容量瓶颈；,架构抽象,推荐召回荐召回-典型策略,根据兴趣标签拉取相应文章并rank

4、 top 结果,德甲 英超,互联网金融,搞笑,电商,。离线更新tag 倒排索引,以兴趣分类召回为例，实际上这里的tag 可以是 各种显式兴趣标签和隐式兴趣特征,用户兴趣标签,1.Storm python 框架,德甲 电商O2O搞笑 历史 军事,0.30.20.20.10.10.1,推荐召回-抽象,(gid 2,score 2),(gid n,score n),离线倒排更新fid:(gid 1,score 1)在线search,(fid 1,score 1)(fid 2,score 2)(fid k,scorek)(gid 1,score 1)(gid 2,score 2)(gid n,scor

5、e n),其他组件filter、merge、boost 等；,创建时间；过期时间；,Keyword；Topic；,阅读数；展现数；,文章属性,文本信息,动态属性,正排-相关数据,推荐系环节，如：召回、过滤及预估等需要文章正排；文章包括图文、视频、UGC 内容，正排属性主要包括：,正排-痛点,各模块各自维护相应的离线和在线，稳定性和时效性无法保证；格式多样:json、msgpack、protobuf 等；字段重复、含义不一致，存储不统一：mc、redis 等；Trouble-shooting 成本比较高；,正排-统一方案,200+字段，由protobufIDL 描述，按”,簇”存储；,统一离线刷

6、新框架，保证高时效性和稳定性；统一存储和对外接口；提供完善的debug 工具：查询正排内容、更新时间等；,存储方案-index_service,Updater,update,search,Online Service,Index Service,实时更新,跨 机 房 同 步,Updater,Online Service,update,search,search,search,Online Service,Online Service,Index Service,Index Service,Index Service,基于lmdb 存储，MVCC、读写相互不阻塞；内存映射，0拷贝，如：过滤；,存

7、放在共享内存，实现TTL、compaction、定期持久化；给召回提供算子：filter、merge、boost 等；单机1w QPS，pct991ms，没有明显长尾；,实时更新,成本压力,架构1.0-局部优化,基于Thrift+Python多进程模型：并行化：gevent、线程池；C+扩展：cython、boost.python;解释器：pypy，需要适配依赖，主要用于离线；基础库so 版本：protobuf、thriftprotocol、json；服务处理时间和用户感知时间gap；,架构1.0-痛点,痛点主要来自Python 多进程模型：性能无法满足策略优化，如：增加预估条数；单机QPS低

8、，内存瓶颈，CPU用不上去，浪费严重；只能堆机器提高吞吐能力；,架构2.0,完全重构，拥抱C+11：,ThriftNonblockingServer 多线程模型；机器数减少60%+；,平均延时下降30%+，PCT99下降50%+；,延时控制,Cache 问题,在推荐系统中Cache并非总是万金油：一个用户刷新两次，不能重复，但搜索同一个query，短期 内返回相同结果；实时的用户Profile 和模型特征，Cache会影响指标；召回候选集、倒排拉链实时更新；,Cache 应,但Cache依然是系统的重要组成部分，降低延时，避免雪崩：LocalCache、分布式Cache、共享内存；一些招数空值

9、回填；异步刷新；写时更新 or 写时删除；,Pool化,内存池：tcmalloc、jemalloc；对象池：复用对象，减少内存申请释放，实现warmup、shared_ptrdeleter 自动归还；线程池：并发执行，降低延时；连接池：多RPC 副本连接管理、长连接复用；,并化,openmp一行代码串行变并行；滥用，频繁创建和销毁线程；,线程池,方便监控：空闲线程、pending task；配合future/promise 更灵活；但不是并行度越高越好，多线程的overhead；,大扇出,获取feature 需2000+的RPC调用，串行肯定是无法满足需求。基于openmp 的扇出调度：,问题

10、：openmp 线程数太多，CPUload 太高，但利用率低。,大扇出-优化,Thrift client 使用同步模型，需要更多的线程来实现并发；实现基于异步IO的thriftRPC fanout，将IO和序列化反序列化分离：,用更少线程实现扇出调用，CPU load 下降20%+；,大扇出,；,长尾概率：(1-0.999*2000)=86.5%传输大量小包，sys 态占比高；增加Proxy，减少扇出和小包；,框架层面,thriftbugs：10patches，性能不高；grpc or fbthriftor 自研？使用FbthriftServer 模块CPU使用率下降20%+：,传输协议&IDL 向下兼容；IOBuf 应用，减少copy、避免一次性申请大内存；支持全异步调用：扇出、并发；,可用性,降级机制：自动降级和降级平台；调度优化：封禁、探活、解禁；主动overflow：丢弃长时间pendingtask；熔断：降低后端压力，防雪崩；优雅退出：运维0拒绝；多机房调度：快速流量迁移；,未来挑战,数据、规模继续爆炸；多IDC 的挑战；系统复杂性、ToubleShooting；资源利用率、资源调度；,