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

作者： 刘若然，字节跳动 邹乐启，字节跳动 邹璇，字节跳动 王彩华，字节跳动 张彪，字节跳动 唐达，字节跳动 朱博林∗，复旦大学 朱一杰，字节跳动 吴鹏，字节跳动 王科，字节跳动 程优龙†，字节跳动 (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 设计 Monolith 的整体架构通常遵循 TensorFlow 的分布式 Worker- arameter erver 设置（图 在 Worker-PS 架构中，机器被分配不同的角色；Worker 机器负责执行图中定义的计算，而 PS 机器存储参数并根据 Worker 计算出的梯度更新它们。 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，元素将存储在这两个表中的一个。当尝试将元素 𝐴 插入 𝑇0 时，它首先尝试将 𝐴 放置在 ℎ0 (𝐴)；如果 ℎ0 (𝐴) 被另一个元素 𝐵 占用，它将从 𝑇0 中逐出 𝐵，并尝试用相同的逻辑将 𝐵 插入 𝑇1。这个过程将一直重复，直到所有元素稳定，或者在插入遇到循环时发生重新哈希。 16 3 内存占用减少也是我们设计中的一个重要考虑因素。将每个新 ID 插入哈希表的简单方法会迅速耗尽内存。对实际生产模型进行的观察得出了两个结论： (1) 仅出现几次 ID 对提高模型质量的贡献有限。一个重要的观察结果是 ID 呈长尾分布，其中流行 ID 可能出现数百万次，而不受欢迎的 ID 出现次数不超过十次。由于缺乏训练数据，与这些低频 ID 对应的嵌入会出现欠拟合，模型将无法根据它们做出良好的估计。归根结底，这些 ID 不太可能影响结果，因此模型质量不会因删除这些低出现次数的 ID 而受到影响； (2) 来自遥远历史的陈旧 ID 对当前模型的贡献很小，因为其中许多很少被访问。这可能是由于用户不再活跃，或者短视频已过时。存储这些 ID 的嵌入无助于模型，只会白白消耗我们的 PS 内存。 基于这些观察，我们设计了几种特征 ID 过滤启发式方法，以实现更内存高效的哈希表实现： (1) ID 在被允许进入嵌入表之前会被过滤。我们有两种过滤方法：首先，我们在 ID 被插入为键之前按其出现次数进行过滤，其中出现次数的阈值是一个可调的超参数，每个模型都不同；此外，我们使用概率过滤器，有助于进一步减少内存使用； ![#图 4：流引擎。 来自 [用户 → 模型服务 → 训练工作节点 → 模型服务 → 用户] 的信息反馈循环在采用批处理训练路径时需要很长时间，而在线训练可以更快地关闭循环。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID 被计时，并在一段时间不活动后过期。过期时间对于每个嵌入表也是可调的，以允许区分对历史信息具有不同敏感度的特征。 在我们的实现中，哈希表被实现为 TensorFlow 资源操作。与变量类似，查找和更新也作为原生 TensorFlow 操作实现，以便于集成和更好的兼容性。 2.2 在线训练 在 Monolith 中，训练分为两个阶段（图 1）： (1) 批处理训练阶段。此阶段工作方式与普通 TensorFlow 训练循环相同：在每个训练步骤中，训练工作节点从存储中读取一个训练样本小批量，从 PS 请求参数，计算前向和后向传播，最后将更新后的参数推送到训练 PS。与其他人常见的深度学习任务略有不同，我们只对数据集进行一次遍历。当修改模型架构并重新训练模型时，批处理训练对于训练历史数据很有用； (2) 在线训练阶段。模型部署到在线服务后，训练不会停止，而是进入在线训练阶段。训练工作节点不是从存储中读取样本小批量，而是即时处理实时数据并更新训练 PS。训练 PS 会定期将其参数同步到服务 PS，这将立即对用户端生效。这使我们的模型能够根据用户的实时反馈进行交互式适应。 Monolith 内置了在批处理训练和在线训练之间无缝切换的能力。这是由我们的流引擎设计实现的，如图 所示。 2.2.1 流引擎。 4 在我们的设计中，我们使用一个 Kafka [ ] 队列来记录用户的行为（例如，点击一个项目或喜欢一个项目等），以及另一个 Kafka 队列用于特征。引擎的核心是用于在线特征连接器的 Flink [ ] 流作业。在线连接器将特征与用户行为的标签连接起来，生成训练样本，然后将这些样本写入 Kafka 队列。训练样本队列由在线训练和批处理训练共同消费： 13 4 对于在线训练，训练工作节点直接从 Kafka 队列读取数据； 对于批处理训练，数据转储作业将首先将数据转储到 HDFS [ ]；在 HDFS 中的数据累积到一定量后，训练工作节点将从 HDFS 检索数据并执行批处理训练。 18 训练 PS 中的更新参数将根据参数同步计划推送到服务 PS。 在实际应用中，用户行为日志和特征流式传输到在线连接器（图 ，但不保证时间顺序。因此，我们为每个请求使用一个唯一的键，以便用户行为和特征能够正确配对。 2.2.2 在线连接器。 5） 用户行为的延迟也可能是一个问题。例如，用户可能在几天后才决定购买几天前看到的商品。这对连接器来说是一个挑战，因为如果所有特征都保留在缓存中，它将无法放入内存。在我们的系统中，使用了磁盘上的键值存储来存储等待超过一定时间段的特征。当用户行为日志到达时，它首先查找内存缓存，然后在缓存丢失的情况下查找键值存储。 在实际应用中出现的另一个问题是负样本和正样本的分布高度不均匀，前者数量可能是后者的数倍。为了防止正样本被负样本淹没，常用的策略是进行负采样。这肯定会改变训练模型的底层分布，将其调整为做出积极预测的概率更高。作为补救，我们在提供服务时应用了对数赔率校正 [ ]，确保在线模型是原始分布的无偏估计量。 19 在线训练期间，Monolith 训练集群持续从在线服务模块接收数据，并更新训练 PS 上的参数。使在线服务 PS 受益于这些新训练参数的关键步骤是更新模型参数的同步。在生产环境中，我们遇到了几个挑战： 2.2.3 参数同步。 在线服务 PS 上的模型在更新时不能停止服务。我们生产中的模型通常有几 TB 大小，因此替换所有参数需要一段时间。在替换过程中停止在线 PS 提供模型服务是不可容忍的，并且必须即时进行更新； 将一个多 TB 模型整体从训练 PS 传输到在线服务 PS 将对 PS 的网络带宽和内存造成巨大压力，因为它需要双倍的内存模型大小来接收新到达的模型。 为了使在线训练能够扩展到我们的业务场景规模，我们基于模型的一些显着特征，在 Monolith 中设计了一种增量式、即时、周期性的参数同步机制： (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 进行评估，因为这是衡量实际模型的主要指标。 • 嵌入冲突。此数据集包含大约 160,000 个用户 ID 和 60,000 个电影 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 天的数据按时间顺序分成 𝑁 个分片。在线训练通过算法 进行模拟。 因此，我们模拟了以由数据分片数量决定的间隔将训练好的参数同步到在线服务 PS。我们实验了 𝑁 = 10, 50, 100，大致对应于 5 小时、1 小时和 30 分钟的更新间隔。 (2) 。此外，我们还在生产环境中进行了一项实时实验，使用真实的在线服务流量，以进一步证明在线训练在实际应用中的重要性。这项 A/B 实验比较了我们其中一个广告模型在生产环境中在线训练与批处理训练的性能。 现场实验 3.2 结果与分析 来自 MovieLens 数据集和内部推荐数据集的结果都表明，嵌入冲突会损害模型质量。 3.2.1 嵌入冲突的影响。 (1) 无冲突哈希表的模型持续优于有冲突的模型。这一结论在以下方面均成立： 训练周期数增加。如图 所示，具有无冲突嵌入表的模型从第一个周期开始就具有更高的 AUC，并在更高的值处收敛； 7 由于概念漂移，随着时间的推移，分布的变化。如图 所示，即使随着时间的推移和用户/项目上下文的变化，无冲突嵌入表的模型也具有鲁棒性。 8 (2) 由无冲突嵌入表引起的数据稀疏性不会导致模型过拟合。如图 所示，无冲突嵌入表的模型在收敛后不会过拟合。 7 ![#图 8：嵌入冲突对生产中推荐模型的影响 我们通过在线服务 AUC 来衡量这个推荐模型的性能，由于概念漂移，该 AUC 在不同天之间波动。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-d9i3eb9.jpeg) ![#图 9：Criteo 数据集上的在线训练与批处理训练。 蓝色线条：在线训练模型的 AUC；黄色线条：批处理模型针对流式数据评估的 AUC。](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-o0j3ej8.jpeg) 我们发现更高的参数同步频率总是 P L A Y S 相关的，并且在线服务模型对 PS 分片丢失的容忍度比我们预期的要高。 3.2.2 在线训练：用实时性换取可靠性。 (1) 。在我们使用 Criteo Display Ads Challenge 数据集的在线流式训练实验 中，模型质量随着参数同步频率的增加而持续提高，从两个角度来看都很明显： 参数同步频率的影响 • 在线训练的模型性能优于不在线训练的模型。图 , , 比较了在线训练模型通过以下数据分片评估的 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% 的故障率，每 10 天就会有一个 PS 出现故障，我们会丢失该 PS 1 天的更新。假设日活跃用户 (DAU) 为 1500 万，并且用户 ID 在每个 PS 上均匀分布，我们每 10 天会丢失 15,000 名用户的 1 天反馈。这是可以接受的，因为 (a) 对于用户特定的稀疏特征，这相当于丢失了 0.01% DAU 的一小部分；(b) 对于密集变量，由于我们在 2.2.3 中讨论的更新速度较慢，丢失 1000 个 PS 中的 1 天更新是微不足道的。基于以上观察和计算，我们大幅降低了快照频率，从而节省了相当多的计算开销。 4 相关工作 自从深度学习在工业级推荐系统中取得一些早期成功应用以来 [ , ]，研究人员和工程师们一直在采用各种技术来缓解第 2 节中提到的问题。 1。 6 10 为了解决稀疏特征表示问题，[ , ] 使用固定大小的嵌入表和哈希技巧。也有改进哈希以减少冲突的尝试 [ , ]。其他工作直接利用本地键值哈希表来允许表大小动态增长 [ , , , ]。这些实现构建在 TensorFlow 之上，但依赖于专门设计的软件机制 [ , , ] 或硬件 [ ] 来访问和管理它们的哈希表。与这些解决方案相比，Monolith 的哈希表是另一种 3 6 3 7 12 15 20 21 14 15 20 21