android 今日头条屏幕适配方案原理 ios今日头条适配方案

互联网时代内容分发的变革

今日头条本质上是一个强大的智能推荐引擎

数据截止于：截至2016年12月底

• 头条DAU : 7800w ;
• 头条MAU : 1.75亿;
• 单用户日平均使用时长: 76分钟;
• 用户行为峰值: 150w+ msg/s;
• 每天训练数据: 300T+ (压缩后) ;
• 机器规模:万级;

系统架构

面临挑战

• 期望快速反馈: 10min内;
• feature数量: 200+;
• 存量用户数和每天的用户行为数据量巨大;
• 在线存储:读写吞吐高,要求延时低且可预期;

流式计算

• 实现Storm Python框架
• 写MR的方式写Streaming Job ;
• Topology用Yaml描述,代码自动生成,降低编写job成本;
• 框架自带KafkaSpout ,业务仅关注拼接和计算逻辑;
• Batch MR相关算法逻辑可以直接复用在流式计算中;
• Job数: 300+ ;
• Storm集群规模: 1000+ ;

在线存储-abase

• 基于Rocksdb的分布式存储系统:
• 基于文件的全量复制和基于rocksdb自身WAL的增量复制;
• 内建和back storage强一致的key级别LRU cache ;
• 基于bucket的sharding和migration ;
• 基于compaction filter的延迟过期策略;
• 数据量:压缩后,单副本85T ;
• QPS :读360w、写40w ;
• 内建Cache命中率: 66% ;
• 延时: avg 1ms、pct99 4ms;
• 机器数:单副本40台, SSD容量瓶颈;

架构抽象

推荐召回-典型策略

推荐召回-抽象

离线倒排更新

• fid: (gid1, score1)>(gid2,score2)- .. >(gidnScoren)

在线search

• (fid1,score1)(fid2,score2...fidk,scorek)-
• (gid1,score1)(gidz,score2)..(gidnscoren)

其他组件

• filter、merge、 boost等 ;

正排-相关数据

正排-痛点

• 各模块各自维护相应的离线和在线,稳定性和时效性无法保证;
• 格式多样: json、msgpack. protobuf等 ;
• 字段重复、含义不一致,存储不统一: mc、redis等 ;
• Trouble- shooting成本比较高;

正排-统一方案

• 200+字段,由protobuf IDL描述，按"簇"存储;
• 统一离线刷新框架,保证高时效性和稳定性;
• 统存储和对外接口 ;
• 提供完善的debug工具:查询正排内容、更新时间等;

存储方案- index_ service

成本压力

架构1.0-局部优化

• 基于Thrift+ Python多进程模型:
• 并行化: gevent、线程池;
• C++扩展: cython、 boost.python;
• 解释器: pypy ,
• 需要适配依赖,主要用于离线;
• 基础库so版本: protobuf、 thrift protocol、 json ;
• 服务处理时间和用户感知时间gap ;

架构1.0-痛点

痛点主要来自Python多进程模型:

• 性能无法满足策略优化,如:增加预估条数;
• 单机QPS低,内存瓶颈, CPU用不上去,浪费严重
• 只能堆机器提高吞吐能力;

架构2.0

• 完全重构,拥抱C ++11 :
• Thrift Nonblocking Server多线程模型;
• 机器数减少60%+ ;
• 平均延时下降30%+ , PCT99下降50%+ ;

延时控制

Cache问题

• 在推荐系统中Cache并非总是万金油:
• 一个用户刷新两次,不能重复,但搜索同一个query ,短期
• 内返回相同结果;
• 实时的用户Profile和模型特征, Cache会影响指标;
• 召回候选集、倒排拉链实时更新;

Cache应用

但Cache依然是系统的重要组成部分,降低延时,避免雪崩:

• LocalCache、分布式Cache、共享内存;
• 些招数
• 空值回填 ;
• 异步刷新;
• 一写时更新or写时删除;

Pool化

• 内存池: tcmalloc、jemalloc ;
• 对象池:复用对象,减少内存申请释放,实现warmup.
• shared_ ptr deleter自动归还;
• 线程池:并发执行,降低延时;
• 连接池:多RPC副本连接管理、长连接复用;

作者：金敬亭