字节跳动的巨石：驱动更智能、更快速内容推荐引擎

作者: 刘卓然, 字节跳动 邹乐奇, 字节跳动 邹轩, 字节跳动 王彩华, 字节跳动 张彪, 字节跳动 唐达, 字节跳动 朱博霖∗, 复旦大学 朱一杰, 字节跳动 吴鹏, 字节跳动 王珂, 字节跳动 程优龙†, 字节跳动 (youlong.cheng@bytedance.com) 摘要 构建一个可扩展的实时推荐系统对于许多依赖于时间敏感的客户反馈的业务至关重要，例如短视频排名或在线广告。尽管生产规模的深度学习框架（如 TensorFlow 或 PyTorch）得到了广泛采用，但这些通用框架由于多种原因无法满足推荐场景下的业务需求：一方面，基于静态参数和密集计算来调整用于处理动态和稀疏特征的推荐系统会损害模型质量；另一方面，这些框架的设计将训练阶段和推理阶段完全分开，导致模型无法与客户反馈进行实时交互。这些问题促使我们重新审视传统方法并探索截然不同的设计选择。在本文中，我们提出了 1，一个专为在线训练而设计的系统。我们的设计受到了对应用工作负载和生产环境的观察驱动，这与其他推荐系统形成了显著的差异。我们的贡献是多方面的：首先，我们设计了一个无冲突的嵌入表，并进行了诸如可过期嵌入和频率过滤等优化，以减小其内存占用；其次，我们提供了一个生产就绪的、容错性高的在线训练架构；最后，我们证明了系统可靠性可以为了实时学习而进行权衡。Monolith 已成功应用于 BytePlus Recommend2 产品。 Monolith 1 引言 过去的十年见证了推荐技术驱动的业务的蓬勃发展。为了提供更好的客户体验，为每个用户提供个性化内容并实时响应是这些业务应用的共同目标。为此，用户最新交互的信息通常被用作训练模型的主要输入，因为它最能描绘用户的画像并预测用户的兴趣和未来行为。 深度学习已在推荐模型中占据主导地位 [ , , , , , ]，因为海量的用户数据非常适合大规模数据驱动的神经网络模型。然而，在行业级推荐系统中利用深度学习的努力，不断遇到由真实用户行为衍生的数据的独特特性所带来的问题。这些数据在两个方面与用于语言建模或计算机视觉等传统深度学习问题的显式数据截然不同： 5 6 10 12 20 21 (1) 特征大多是稀疏的、类别型的且动态变化的； (2) 训练数据的底层分布是非平稳的，即概念漂移 。 这些差异给从事推荐系统研究和工程的人员带来了独特的挑战。 1.1 稀疏性和动态性 推荐数据主要包含稀疏的类别特征，其中一些特征出现的频率很低。将它们映射到高维嵌入空间是常见的做法，但这会引起一系列问题： • 与词汇量有限的语言模型不同，用户和排名项目的数量要大几个数量级。如此巨大的嵌入表很难放入单个主机内存； • 更糟糕的是，随着越来越多的用户和项目被接纳，嵌入表的大小预计会随时间增长，而像 [ , ] 这样的框架使用固定大小的密集变量来表示嵌入表。 1 17 在实践中，许多系统采用低冲突哈希 [ , ] 作为减少内存占用和允许 ID 增长的方法。这依赖于一个过于理想化的假设，即嵌入表中的 ID 频率分布均匀，并且冲突对模型质量无害。不幸的是，在真实的推荐系统中，这种情况很少见，因为一小部分用户或项目出现次数显著更多。随着嵌入表大小的有机增长，哈希键冲突的可能性增加，并导致模型质量下降 3 6 。 因此，生产规模的推荐系统自然需要具备捕获其参数中尽可能多的特征的能力，并具备弹性调整其要跟踪的用户和项目数量的能力。 1.2 非平稳分布 视觉和语言模式在几个世纪的时间尺度上几乎没有发展，而对某个主题感兴趣的同一用户可能在下一分钟就改变了热情。因此，用户数据的底层分布是非平稳的，这种现象通常被称为概念漂移 。 直观地说，来自最近历史的信息可以更有效地帮助预测用户行为的变化。为了减轻概念漂移的影响，服务模型需要尽可能实时地根据新的用户反馈进行更新，以反映用户的最新兴趣。 鉴于这些区别，并基于我们生产环境中的问题观察，我们设计了 ，一个大规模推荐系统来解决这些痛点。我们在生产环境中进行了广泛的实验来验证和迭代我们的设计。Monolith 能够： Monolith (1) 通过设计无冲突哈希表和动态特征淘汰机制，为稀疏特征提供完整的表达能力； (2) 通过在线训练，将服务反馈实时循环回训练。 凭借这些架构能力，Monolith 在采用带冲突的哈希技巧的系统之上表现持续优越，并且内存使用量大致相似，同时实现了最先进的在线服务 AUC，而不会过度负担我们的服务器的计算能力。 本文的其余部分组织如下。我们首先在第 2 节详细阐述 Monolith 如何通过无冲突哈希表和实时训练来解决现有挑战的设计细节。第 3 节将介绍实验和结果，以及经过生产测试的结论和对时间敏感性、可靠性和模型质量之间权衡的一些讨论。第 4 节总结了相关工作并将其与 Monolith 进行比较。第 5 节对这项工作进行了总结。 2 设计 在 Worker-PS 架构中，机器被分配不同的角色；Worker 机器负责执行图定义的计算，而 PS 机器存储参数并根据 Worker 计算出的梯度更新它们。 Monolith 的整体架构通常遵循 TensorFlow 的分布式 Worker- arameter erver 设置（图 P S 2）。 在推荐模型中，参数分为两类：密集参数和稀疏参数。密集参数是深度神经网络中的权重/变量，而稀疏参数是指对应于稀疏特征的嵌入表。在我们的设计中，密集参数和稀疏参数都是 TensorFlow 图的一部分，并存储在参数服务器上。 与 TensorFlow 的密集参数变量类似，我们为稀疏参数设计了一组高效、无冲突且灵活的哈希表操作。 作为对 TensorFlow 在训练和推理分离方面局限性的补充，Monolith 的弹性可伸缩在线训练旨在高效地在短间隔内将参数从训练-PS 同步到在线服务-PS，并由容错机制提供模型鲁棒性保证。 2.1 哈希表 我们设计稀疏参数表示的一个基本原则是避免将不同 ID 的信息塞入同一个固定大小的嵌入中。使用现成的 TensorFlow 变量模拟动态大小的嵌入表不可避免地会导致 ID 冲突，随着新 ID 的到来和表的大小增长，冲突会加剧。因此，我们没有基于变量构建，而是为稀疏参数开发了一个新的键值哈希表。 我们的哈希表底层使用了 Cuckoo Hashmap [ ]，它支持在不与现有键冲突的情况下插入新键。Cuckoo Hashing 在查找和删除操作中实现了最坏情况下的 𝑂 (1) 时间复杂度，以及插入操作的预期摊销 𝑂 (1) 时间复杂度。如图 所示，它维护两个具有不同哈希函数 ℎ0 (𝑥), ℎ1 (𝑥) 的表 𝑇0, 𝑇1，元素将被存储在其中一个表中。当尝试将元素 16 3 𝐴 插入 𝑇0 时，它首先尝试将 𝐴 放置在 ℎ0 (𝐴) 处；如果 ℎ0 (𝐴) 被另一个元素 𝐵 占用，它将从 𝑇0 中驱逐 𝐵，并尝试使用相同的逻辑将 𝐵 插入 𝑇1。这个过程将重复进行，直到所有元素稳定，或者在插入陷入循环时发生重新哈希。 内存占用减少也是我们设计中的一个重要考虑因素。将每个新 ID 插入哈希表的简单方法会很快耗尽内存。对实际生产模型进行观察得出了两个结论： (1) 仅出现几次 ID 对提高模型质量的贡献有限。一个重要的观察是 ID 呈长尾分布，其中热门 ID 可能出现数百万次，而冷门 ID 的出现次数不超过十次。这些频率低的 ID 对应的嵌入由于缺乏训练数据而欠拟合，模型无法基于它们做出好的估计。最终，这些 ID 不太可能影响结果，因此模型质量不会因删除这些出现次数少的 ID 而受到影响； (2) 来自遥远历史的陈旧 ID 对当前模型的贡献很少，因为它们中的许多从未被访问过。这可能是因为用户不再活跃，或者某个短视频已过时。存储这些 ID 的嵌入无助于模型，反而会白白耗尽我们的 PS 内存。 基于这些观察，我们设计了几种特征 ID 过滤策略，以更节省内存地实现哈希表： (1) 在 ID 被允许进入嵌入表之前进行过滤。我们有两种过滤方法：首先，我们在 ID 作为键插入之前按其出现次数进行过滤，其中出现次数的阈值是一个可调的超参数，因模型而异；此外，我们使用概率过滤器，有助于进一步减少内存使用； ![#Figure 4: Streaming Engine. 来自 [用户 → 模型服务器 → 训练 Worker → 模型服务器 → 用户] 的信息反馈循环在采用批量训练路径时耗时很长，而在线训练则能更即时地关闭循环。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID 被计时，并在一段时间不活动后设置过期。过期时间也是为每个嵌入表可调的，以便区分对历史信息敏感度不同的特征。 在我们的实现中，哈希表被实现为 TensorFlow 资源操作。与变量类似，查找和更新也作为本地 TensorFlow 操作实现，以便于集成和提高兼容性。 2.2 在线训练 在 Monolith 中，训练分为两个阶段（图 1）： (1) 批量训练阶段。此阶段像普通的 TensorFlow 训练循环一样工作：在每个训练步骤中，训练 Worker 从存储中读取一个训练样本小批量，从 PS 请求参数，计算前向和后向传播，最后将更新后的参数推送到训练 PS。与大多数常见的深度学习任务略有不同，我们只对数据集进行一次遍历。批量训练对于在模型架构修改和重新训练模型时训练历史数据很有用； (2) 在线训练阶段。模型部署到在线服务后，训练不会停止，而是进入在线训练阶段。训练 Worker 不是从存储中读取小批量样本，而是实时地即时处理数据并更新训练 PS。训练 PS 会定期将其参数同步到服务 PS，这些参数将立即在用户端生效。这使得我们的模型能够实时地根据用户的反馈进行交互式适应。 Monolith 内置了在批量训练和在线训练之间无缝切换的能力。这得益于我们设计的流引擎（如图 所示）。 2.2.1 流引擎。 4 在我们的设计中，我们使用一个 Kafka [ ] 队列来记录用户的行为（例如，点击某个项目或喜欢某个项目等），以及另一个 Kafka 队列用于特征。引擎的核心是一个 Flink [ ] 流作业，用于在线特征连接器。在线连接器将特征与用户行为标签连接起来，生成训练样本，然后写入 Kafka 队列。训练样本队列既被在线训练消费，也被批量训练消费： 13 4 对于在线训练，训练 Worker 直接从 Kafka 队列读取数据； 对于批量训练，数据转储作业将首先将数据转储到 HDFS [ ]；当 HDFS 中的数据累积到一定量后，训练 Worker 将从 HDFS 检索数据并执行批量训练。 18 训练 PS 中的更新参数将根据参数同步计划推送到服务 PS。 在实际应用中，用户行为日志和特征会流式传输到在线连接器（图 ，并不保证时间顺序。因此，我们使用每个请求的唯一键，以便用户行为和特征能够正确配对。 2.2.2 在线连接器。 5） 用户行为的滞后也可能是一个问题。例如，用户在购买几天前看到的商品之前可能会花几天时间。这对连接器来说是一个挑战，因为如果所有特征都保留在缓存中，它将无法放入内存。在我们的系统中，我们使用一个磁盘键值存储来存储等待超过一定时间段的特征。当用户行为日志到达时，它首先查找内存缓存，然后在缓存丢失时查找键值存储。 实际应用中出现的另一个问题是，正负样本的分布极不均匀，前者数量可能是后者的数千倍。为了防止正样本被负样本淹没，一个常见的策略是进行负采样。这无疑会改变训练模型的底层分布，使其倾向于做出正预测的更高概率。作为补救，我们在服务时应用对数几率校正 [ ]，以确保在线模型是原始分布的无偏估计量。 19 在线训练期间，Monolith 训练集群会不断从在线服务模块接收数据，并更新训练 PS 上的参数。使在线服务 PS 受益于这些新训练参数的关键步骤是更新模型参数的同步。在生产环境中，我们遇到了几个挑战： 2.2.3 参数同步。 在线服务 PS 上的模型在更新时不得停止服务。我们生产中的模型通常有数 TB 大小，因此替换所有参数需要一段时间。在替换过程中停止在线 PS 服务模型是不可容忍的，并且更新必须即时完成； 将数 TB 大小的模型整体从训练 PS 传输到在线服务 PS 会给 PS 的网络带宽和内存带来巨大压力，因为它需要双倍的模型大小内存来接收新到达的模型。 为了使在线训练能够扩展到我们的业务场景规模，我们基于我们模型的一些显著特征，设计了一种增量式的、即时的、周期性的参数同步机制： (1) 稀疏参数主导了推荐模型的规模； (2) 在较短的时间窗口内，只有一小部分 ID 得到训练并更新其嵌入； (3) 密集变量的移动速度远慢于稀疏嵌入。这是因为在基于动量的优化器中，密集变量的动量累积被推荐训练数据的巨大规模所放大，而单次数据批次中只有一个稀疏嵌入得到更新。 (1) 和 (2) 使我们能够利用所有特征 ID 的稀疏更新。在 Monolith 中，我们维护一个已触碰键的哈希集，表示自上次参数同步以来其嵌入得到训练的 ID。我们以分钟级的间隔将那些键在已触碰键集合中的稀疏参数子集从训练 PS 推送到在线服务 PS。这种相对较小的增量参数更新包对于网络传输来说是轻量级的，并且不会在同步过程中引起急剧的内存峰值。 我们还利用 (3) 来进一步减少网络 I/O 和内存使用，方法是为稀疏参数设置更积极的同步计划，而较少地更新密集参数。这可能导致我们服务的密集参数版本相对陈旧。然而，如 (3) 所述，这种不一致是可以容忍的，因为没有观察到明显的损失。 2.3 容错 作为一个生产系统，Monolith 在设计时就具备了在 PS 发生故障时恢复模型的能力。容错的一个常见选择是定期快照模型状态，并在检测到 PS 故障时从最近的快照恢复。快照频率的选择有两个主要影响： (1) 模型质量。直观地说，随着快照频率的增加，模型因近期历史丢失而受到的影响会减小。 (2) 计算开销。快照一个数 TB 大小的模型并非免费。它会产生大量的内存复制和磁盘 I/O。 作为模型质量和计算开销之间的权衡，Monolith 每天快照所有训练 PS。虽然 PS 在发生故障时会丢失一天的更新，但我们通过实验发现性能下降是可以容忍的。我们将在下一节分析 PS 可靠性的影响。 3 评估 为了更好地理解我们提出的设计带来的好处和权衡，我们在生产规模下进行了一些实验，并通过 A/B 测试与实时服务流量进行比较，从不同方面评估和验证 Monolith。我们旨在通过实验回答以下问题： (1) 无冲突哈希表能给我们带来多大的好处？ (2) 实时在线训练有多重要？ (3) Monolith 的参数同步设计在大型生产场景中是否足够健壮？ 在本节中，我们首先介绍实验设置，然后详细讨论结果和我们的发现。 3.1 实验设置 如第 所述，Monolith 中的嵌入表作为无冲突哈希表实现。为了证明在嵌入表中避免冲突的必要性，并量化我们无冲突实现的收益，我们在 Movielens 数据集和我们内部的生产数据集上进行了两组实验： 3.1.1 嵌入表。 2.1 节 (1) ml-25m 数据集 [ ]。这是一个标准的电影评分公开数据集，包含 2500 万条评分，涉及约 162,000 名用户和 62,000 部电影。 MovieLens 11 • 。原始标签是从 标签预处理 0.5 到 5.0，而在生产环境中，我们的任务主要是接收用户的二元信号。为了更好地模拟我们的生产模型，我们将尺度标签转换为二元标签，将分数 ≥ 3.5 视为正样本，其余视为负样本。• 模型和指标。我们实现了一个标准的 DeepFM 模型，这是一个常用的推荐问题模型架构。它由一个 FM 组件和一个密集组件组成（图 6）。预测通过 AUC 进行评估，因为这是真实模型的主要衡量标准。• 嵌入冲突。该数据集包含约 160K 用户 ID 和 60K 电影 ID。为了与无冲突的嵌入表实现进行比较，我们进行了另一组实验，其中 ID 使用 MD5 哈希进行预处理，然后映射到一个较小的 ID 空间。结果是，一些 ID 将与其嵌入共享。表 1 显示了哈希前后用户和电影 ID 的详细统计数据。 (2) 。 内部推荐数据集 我们还在生产环境中的推荐模型上进行了实验。该模型通常遵循多塔架构，每个塔负责学习预测特定类型的用户行为。 每个模型大约有 1000 个嵌入表，并且嵌入表的大小分布非常不均匀； 嵌入表的原始 ID 空间为 248。在我们的基线中，我们应用了哈希技巧，通过分解来控制嵌入表的大小。更具体地说，我们使用两个较小的嵌入表而不是一个巨大的嵌入表来通过向量组合为每个 ID 生成唯一的嵌入： 其中 𝐸𝑟 , 𝐸𝑞 是对应于 𝐼𝐷𝑟 , 𝐼𝐷𝑞 的嵌入。这有效地将嵌入表大小从 248 减小到 225； • 该模型正在真实生产中服务，该实验的性能通过在线 AUC 和真实服务流量来衡量。 在线训练期间，我们以分钟级的间隔更新在线服务 PS 的最新参数集。我们设计了两组实验来验证模型质量和系统鲁棒性。 3.1.2 在线训练。 (1) 。为了研究分钟级更新频率的必要性，我们进行了实验，以不同的间隔将参数从训练模型同步到预测模型。 更新频率 我们使用的数据集是 Criteo Display Ads Challenge dataset3，这是一个用于基准测试 CTR 模型的超大规模标准数据集。它包含 7 天按时间顺序排列的数据，记录特征和点击行为。对于此实验，我们使用标准的 DeepFM 模型，如 所述。 6 为了模拟在线训练，我们对数据集进行了以下预处理。我们从数据集中抽取 7 天的数据，并将其分为两部分：5 天数据用于批量训练，2 天用于在线训练。我们将这 2 天的数据按时间顺序进一步分为 𝑁 个分片。在线训练通过算法 进行模拟。 1 因此，我们模拟了以由数据分片数量确定的间隔将训练好的参数同步到在线服务 PS。我们实验了 𝑁 = 10, 50, 100，大致对应于 5 小时、1 小时和 30 分钟的更新间隔。 (2) 。此外，我们还进行了真实的实时流量实验，以进一步证明在线训练在现实世界应用中的重要性。这个 A/B 实验将在线训练与批量训练在我们的一个广告模型上进行了比较。 实时实验 3.2 结果与分析 来自 MovieLens 数据集和内部推荐数据集的结果都表明，嵌入冲突会损害模型质量。 3.2.1 嵌入冲突的影响。 (1) 使用无冲突哈希表的模型始终优于有冲突的模型。这一结论无论如何都成立 增加训练轮数。如图 所示，具有无冲突嵌入表的模型从第一轮开始 AUC 就更高，并且收敛到更高的值； 7 由于概念漂移，随着时间的推移而改变分布。如图 所示，具有无冲突嵌入表的模型在随着时间推移和用户/项目上下文变化时也具有鲁棒性。 8 (2) 由无冲突嵌入表引起的模型过拟合（数据稀疏性）并非总是发生。如图 所示，具有无冲突嵌入表的模型在收敛后并不过拟合。 7 ![#Figure 8: Effect of Embedding Collision On A Recommendation Model In Production 我们通过在线服务 AUC 来衡量该推荐模型的性能，由于概念漂移，该 AUC 在不同日期之间波动。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-d9i3eb9.jpeg) ![#Figure 9: Online training v.s. Batch training on Criteo dataset. 蓝色线条：在线训练模型的 AUC；黄色线条：针对流数据评估的批量训练模型的 AUC。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-o0j3ej8.jpeg) 我们发现，更高的参数同步频率总是有助于提高在线服务 AUC，并且在线服务模型比我们预期的更能容忍 PS 的少量分片丢失。 3.2.2 在线训练：为了实时性而权衡可靠性。 (1) 。在我们使用 Criteo Display Ads Challenge 数据集的在线流训练实验 中，模型质量随着参数同步频率的增加而持续提高，这从两个角度来看是显而易见的： 参数同步频率的影响 (1) • 在线训练的模型优于未使用的模型。图 , , 比较了在线训练模型通过以下数据分片评估的 AUC 与通过每个分片数据评估的批量训练模型； 9a 9b 9c • 参数同步间隔更小的模型优于间隔更大的模型。图 和表 分别比较了同步间隔为 5 小时、1 小时和 30 分钟的模型的在线服务 AUC。 10 2 在生产环境中的广告模型上进行的在线训练与批量训练之间的实时 A/B 实验也表明，在线服务 AUC 有显著提升（表 3）。 受此观察的启发，我们将稀疏参数同步到我们生产模型的服务 PS 尽可能频繁（目前为分钟级），直到计算开销和系统可靠性能够承受。回想一下，如 所述，密集变量需要不那么频繁的更新，我们每天更新一次。通过这样做，我们可以将计算开销降低到非常低的水平。假设每分钟更新 100,000 个 ID，嵌入的维度为 1024，则需要传输的总数据量约为 4KB × 100,000 ≈ 400MB/分钟。对于密集参数，由于它们是每天同步的，我们选择在流量最低的时候（例如午夜）安排同步。 2.2.3 节 (2) PS 可靠性的影响。 通过分钟级的参数同步，我们最初期望更频繁地快照训练 PS 以匹配实时更新。令我们惊讶的是，我们将快照间隔扩大到 1 天，仍然观察到模型质量几乎没有损失。 对于个性化排名系统来说，在模型质量和计算开销之间找到正确的权衡是困难的，因为用户对推荐质量极其敏感。传统上，大型系统倾向于为模型设置频繁的快照计划，这会牺牲计算资源来换取模型质量的最小损失。我们也在这方面进行了大量探索，出乎意料的是，模型质量比预期的更具鲁棒性。在 PS 机器每天 0.01% 的故障率下，我们发现前一天的模型效果非常好。这可以通过以下计算来解释：假设一个模型的参数分片到 1000 个 PS，并且它们每天快照一次。考虑到 0.01% 的故障率，其中一个 PS 每 10 天就会出现故障，我们会丢失该 PS 1 天的更新。假设 DAU 为 1500 万，并且用户 ID 在每个 PS 上均匀分布，我们每 10 天会丢失 15,000 个用户的 1 天反馈。这是可接受的，因为 (a) 对于用户特定的稀疏特征，这相当于丢失了 0.01% DAU 的一小部分；(b) 对于密集变量，由于它们更新缓慢，如我们在 2.2.3 节所讨论的，丢失 1000 个 PS 中的 1 天更新是微不足道的。基于上述观察和计算，我们从根本上降低了快照频率，从而节省了不少计算开销。 4 相关工作 自从深度学习在行业级推荐系统中取得一些早期成功应用以来 [ , ]，研究人员和工程师一直在采用各种技术来改善第 中提到的问题。 6 10 1 节 为了解决稀疏特征表示的问题，[ , ] 使用固定大小的嵌入表和哈希技巧。也有一些改进哈希以减少冲突的尝试 [ , ]。其他工作直接利用本地键值哈希表来允许表大小的动态增长 [ , , , ]。这些实现基于 TensorFlow，但依赖于专门设计的软件机制 [ , , ] 或硬件 [ ] 来访问和管理其哈希表。与这些解决方案相比，Monolith 的 3 6 3 7 12 15 20 21 14 15 20 21