5 年迭代 5 次，抖音推荐系统演进历程_抖音推送历史

百花齐放”。离线特征计算的基本模式是基于Spark和Flink计算引擎，通过消费Kafka、BMQ、Hive、HDFS、Abase、RPC等数据源实现特征计算，然后将特征结果写入在线和离线存储。不同类型的基础特征计算分散在不同的服务中，缺乏业务抽象，导致运维成本大，稳定性问题多。庞大的业务规模:抖音、今日头条、西瓜、火山等产品的数据规模可达日均PB级。例如，在抖音的场景中，晚高峰Feed的播放量达到数百万QPS，客户端上报的用户行为数据达到数千万IOPS。业务期望在任何时候，功能任务都能保持流动，消费无滞后等。，这就要求特征制作具有非常高的稳定性。实时特征要求更高:在以直播、电商、短视频为代表的推荐场景中，为了保证推荐效果，实时特征的离线制作时效需要稳定在分钟。更好的可扩展性和灵活性:随着业务场景的日益复杂，功能需求更加灵活多变。从统计、系列、属性类型的特征生产，到窗口特征、多维特征的灵活支持，业务端需要特征中心支持新的特征类型和逐渐衍生的需求。服务迭代速度快:特征中心站提供的面向服务的DSL需要足够多的场景，特征生产环节让服务编写尽可能少的代码，底层计算引擎和存储引擎对服务完全透明，完全释放服务计算、存储选择和优化的负担，完全实现实时基础特征的规模化生产，不断提升特征生产力；2020年初，是一个重要的节点。我们开始将Flink SQL和Flink State技术系统引入到特征生产中，并逐步在计数特征系统、模型训练的样本拼接、窗口特征等场景中实现。，探索新一代专题节目制作方案的思路。新方案的定位是:解决基础特征计算和在线服务，提供更抽象的基础特征服务层DSL。在计算层，基于Flink SQL灵活的数据处理和表达能力，以及Flink State状态存储和计算能力，支持各种复杂的窗口计算。大大缩短业务基础功能的制作周期，提高功能输出环节的稳定性。在新的体系结构中，我们将特征产生的环节分为数据源提取/拼接、状态存储和计算三个阶段。Flink SQL完成特征数据提取和流式拼接，Flink State完成特征计算的中间状态存储。轻离线，重在线”，即所有的窗口状态存储和特征聚合计算都放在存储层，在线完成。离线数据流负责基础数据的过滤和写入，离线详细数据按照时间划分进行汇总和存储(类似于微批量)。底层存储多为KV存储或专门优化的存储引擎，线上层完成复杂的窗口聚合计算逻辑。每个请求到来后，线上层拉取存储层的详细数据进行聚合计算。轻在线，重离线”，即将所有重时间片细节数据状态存储和窗口聚合计算放在离线层。结果聚合由离线窗口触发机制完成，特征结果推送到在线KV存储。在线模块非常轻量，只负责简单的在线服务，大大简化了在线层的架构复杂度。在离线存储层。我们主要依靠Flink提供的native state存储引擎RocksDB，充分利用离线计算集群的本地SSD磁盘资源，大大减轻了在线KV存储的资源压力。在“状态冷启动”的场景中，我们引入集中存储作为底层状态存储层的存储介质，整体是混合架构。比如7天内的状态存储在本地SSD，7 ~ 30天内的状态存储在集中存储引擎。离线数据回溯可以非常方便地写入集中存储。类型定义功能示例计算功能需要缓存上下文数据。类型数据源架构解析(a联合b)窗口联接(c查找联接d)。类型拼接逻辑备注窗口Join基于关键粒度的区间状态JoinLookup维度表Join多数据源Union策略讲解部分实时功能已在抖音直播、电商、推送、抖音推荐等场景上线。主要有有状态特征，如带窗口的一维统计型、二维倒拉链型、二维TOPK型、实时CTR/CVR率型特征、序列型特征等。预计在不久的将来，单个任务的状态可能会超过100T，这对架构的稳定性是一个很大的挑战。:，大部分场景下在线缓存的CPU利用率大概会高达50%左右；对CPU来说更经济，但是网络带宽不会盈利。预计切割会节省大量CPU资源。PB IDL裁剪上线后，大部分任务的CPU收益在30%左右。作者介绍:

郭文飞，字节跳动推荐系统基础服务方向负责人。Byte是2015年初加入的，主要负责推荐系统的基础服务方向，比如去重、计数、特性等。

字节跳动推荐架构团队的实时计算方向，负责抖音、今日头条、西瓜视频等超过10亿用户的产品推荐系统架构的实时计算系统的设计与开发，保证系统的稳定性和高可用性。抽象出通用的实时计算系统，构建统一的推荐特征中心，实现灵活可扩展的高性能存储系统和计算模型，实现推荐服务的去重、计数、特征服务等先进的实时推荐数据流系统。目前缺人。欢迎追求技术的同学们加入我们，打造世界一流的先进实时推荐数据流系统。联系方式:guowenfei@bytedance.com。