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

作者 | 郭文飞
编辑 | 蔡芳芳
2021 年，字节跳动旗下产品总 MAU 已超过 19 亿。在以抖音、今日头条、西瓜视频等为代表的产品业务背景下，强大的推荐系统显得尤为重要。Flink 提供了非常强大的 SQL 模块和有状态计算模块。目前在字节推荐场景，实时简单计数特征、窗口计数特征、序列特征已经完全迁移到 Flink SQL 方案上。结合 Flink SQL 和 Flink 有状态计算能力，我们正在构建下一代通用的基础特征计算统一架构，期望可以高效支持常用有状态、无状态基础特征的生产。

业务背景

文章插图
对于今日头条、抖音、西瓜视频等字节跳动旗下产品，基于 Feed 流和短时效的推荐是核心业务场景。而推荐系统最基础的燃料是特征，高效生产基础特征对业务推荐系统的迭代至关重要。
主要业务场景

文章插图

抖音、火山短视频等为代表的短视频应用推荐场景，例如 Feed 流推荐、关注、社交、同城等各个场景，整体在国内大概有 6 亿 + 规模 DAU；
头条、西瓜等为代表的 Feed 信息流推荐场景，例如 Feed 流、关注、子频道等各个场景，整体在国内大概有 1.5 亿 + 规模 DAU；业务痛点和挑战

文章插图
目前字节跳动推荐场景基础特征的生产现状是“ 百花齐放” 。离线特征计算的基本模式都是通过消费 Kafka、BMQ、Hive、HDFS、Abase、RPC 等数据源，基于 Spark、Flink 计算引擎实现特征的计算，而后把特征的结果写入在线、离线存储。各种不同类型的基础特征计算散落在不同的服务中，缺乏业务抽象，带来了较大的运维成本和稳定性问题。
而更重要的是，缺乏统一的基础特征生产平台，使业务特征开发迭代速度和维护存在诸多不便。如业务方需自行维护大量离线任务、特征生产链路缺乏监控、无法满足不断发展的业务需求等。

文章插图
在字节的业务规模下，构建统一的实时特征生产系统面临着较大挑战，主要来自四个方面：
巨大的业务规模：抖音、头条、西瓜、火山等产品的数据规模可达到日均 PB 级别。例如在抖音场景下，晚高峰 Feed 播放量达数百万 QPS，客户端上报用户行为数据高达数千万 IOPS 。业务方期望在任何时候，特征任务都可以做到不断流、消费没有 lag 等，这就要求特征生产具备非常高的稳定性。
较高的特征实时化要求：在以直播、电商、短视频为代表的推荐场景下，为保证推荐效果，实时特征离线生产的时效性需实现常态稳定于分钟级别。
更好的扩展性和灵活性：随着业务场景不断复杂，特征需求更为灵活多变。从统计、序列、属性类型的特征生产，到需要灵活支持窗口特征、多维特征等，业务方需要特征中台能够支持逐渐衍生而来的新特征类型和需求。
业务迭代速度快：特征中台提供的面向业务的 DSL 需要足够场景，特征生产链路尽量让业务少写代码，底层的计算引擎、存储引擎对业务完全透明，彻底释放业务计算、存储选型、调优的负担，彻底实现实时基础特征的规模化生产，不断提升特征生产力；
迭代演进过程
在字节业务爆发式增长的过程中，为了满足各式各样的业务特征的需求，推荐场景衍生出了众多特征服务。这些服务在特定的业务场景和历史条件下较好支持了业务快速发展，大体的历程如下：

文章插图
推荐场景特征服务演进历程
在这其中 2020 年初是一个重要节点，我们开始在特征生产中引入 Flink SQL、Flink State 技术体系，逐步在计数特征系统、模型训练的样本拼接、窗口特征等场景进行落地，探索出新一代特征生产方案的思路。
新一代系统架构
结合上述业务背景，我们基于 Flink SQL 和 Flink 有状态计算能力重新设计了新一代实时特征计算方案。新方案的定位是：解决基础特征的计算和在线 Serving，提供更加抽象的基础特征业务层 DSL 。在计算层，我们基于 Flink SQL 灵活的数据处理表达能力，以及 Flink State 状态存储和计算能力等技术，支持各种复杂的窗口计算。极大地缩短业务基础特征的生产周期，提升特征产出链路的稳定性。新的架构里，我们将特征生产的链路分为数据源抽取 / 拼接、状态存储、计算三个阶段，Flink SQL 完成特征数据的抽取和流式拼接，Flink State 完成特征计算的中间状态存储。